Question ssh: connexion refusée lors d'un accès à distance


J'ai récemment installé le serveur ssh openssh-server dans mon fedora 16. J'ai ajouté le compte d'utilisateur de mon ami à la liste de mes utilisateurs ssh. Lorsque mon ami a essayé de connecter mon ordinateur serveur via ssh en utilisant la commande suivante

ssh sudip@192.168.1.123

alors il montre l'erreur suivante

ssh: connect to host 192.168.1.123 port 22: Connection refused

mais quand j'ai essayé localement à partir de ma machine, le serveur était connecté.

root@localhost /]# ssh sudip@192.168.1.123
sudip@192.168.1.123's password: 
Last login: Tue Feb 26 13:24:42 2013 from localhost.localdomain
[sudip@localhost ~]$ 

De plus, mon pare-feu autorise SSH et SHH s'exécute sur le port 22. Alors, comment puis-je résoudre l'erreur?

Merci d'avance.

MODIFIER: J'ai déjà commencé à utiliser sshd service sshd redémarrer

EDIT2: sortie de: iptables -n -L -v

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
46970   23M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
   11   616 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           
  133  8552 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW tcp dpt:22
 2328  343K REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT 59145 packets, 7665K bytes)
 pkts bytes target     prot opt in     out     source               destination

Edit 3: résultat de traceroute 192.168.1.123

traceroute to 192.168.1.123 (192.168.1.123), 30 hops max, 60 byte packets
 1  192.168.50.1 (192.168.50.1)  0.828 ms  0.805 ms  0.818 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

Le poste de travail utilise également fedora 16


4
2018-02-26 07:51


origine


D'où vient votre ami se connecter? Hors du même bâtiment / réseau? - Sven♦
il est sur le même réseau. La commande ping ping 192.168.1.123 fonctionne correctement. - Bibek Subedi
Pouvons-nous aussi voir le contenu de /etc/hosts.allow et /etc/hosts.deny? - MadHatter
Vous pouvez iptables -Z INPUT laisser tomber les compteurs. Alors essayez de ssh sudip@192.168.1.123 du poste de travail. Alors jetez un oeil à iptables -n -L -v. La ligne "0 0 ACCEPTER tcp - * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt: 22" doit contenir des chiffres (et non zéro) - Gevial
Il y a au moins un routeur (192.168.50.1) entre le poste de travail et le serveur. Donc, en plus de votre serveur iptables règles, il pourrait être d'autres règles sur les routeurs qui pourraient déposer vos paquets. Tu pourrais essayer tcpdump -i ethX port 22 sur votre serveur et essayez de vous y rendre à partir du poste de travail pour vérifier si des paquets entrent (n'oubliez pas de remplacer ethX par le nom réel de l'iface, qui a une apparence mondiale). Cependant, sans une compréhension complète de la topologie de votre réseau, il est difficile de le savoir. - Gevial


Réponses:


Vous pouvez utiliser ssh -vvv utilisateur@192.x.x.x pour obtenir des informations de débogage sur la connexion. Si -vvv contient trop d'informations, vous pouvez utiliser -vv ou -v pour obtenir des informations de débogage moins détaillées.

Sur le serveur distant, vous devriez également pouvoir voir certaines informations dans / var / log / message ou / var / log / syslog.

Une combinaison de ces 2 choses devrait vous orienter dans la bonne direction.


2
2018-02-26 07:57





le Connection Refused message signifie généralement que rien n’écoute sur cette adresse IP: port. Vérifiez que sshd écoute sur votre 192.168.1.123:22

netstat -tnlp | grep :22
tcp        0      0 0.0.0.0:22          0.0.0.0:*           LISTEN      6809/sshd
tcp        0      0 :::22               :::*                LISTEN      6809/sshd

La sortie ci-dessus indique que sshd écoute sur toutes les interfaces ipv4 et ipv6 disponibles. Si le vôtre est différent, vous devriez vérifier la ListenAddress directives dans votre fichier sshd_config.


7
2018-02-26 08:26



Étant donné qu'il est possible de se connecter à partir d'un autre client, le problème est peu probable. - Jenny D
@JennyD: Le PO dit locally from my machine ce qui suggère que la connexion aura été via lo. - Iain
J'ai vérifié qu'il écoute sur 192.168.1.123:22 - Bibek Subedi
Hmm c'est intéressant netstat -tnlp me donne une réponse vide. Le serveur sshd fonctionne selon ps aux | grep sshd. J'ai essayé avec un serveur de socket aussi, il était capable d'accéder à localhost, mais la connexion a été refusée à l'aide de l'adresse IP locale. Le pare-feu n'est pas installé sur la machine, je n'ai donc aucune idée de ce qui ne va pas. Telnet me donne la connexion refusée aussi. - inf3rno


L'exécution de ssh -vv sudip@192.168.1.123 vous montrera les informations détaillées de la connexion SSH. Vous pouvez également essayer "telnet 192.168.1.123 22" (port du nom d’hôte telnet) afin de vérifier si le port 22 est à l’écoute.


1
2018-02-26 10:57