Le serveur SSH ne répond pas aux demandes de connexion
J'essaie de configurer un serveur SSH sur ma machine locale à l'aide d'OpenSSH. Lorsque j'essaie de SSH depuis un hôte distant vers mon serveur SSH local, le serveur SSH ne répond pas et la demande expire. Je suis presque sûr qu'il y a une solution vraiment évidente à cela que je néglige simplement.
Voici ce qui se passe lorsque j'essaie de me connecter à partir d'un hôte distant:
yoshimi@robots:/$ ssh -vv [email protected]
OpenSSH_6.7p1 Debian-5, OpenSSL 1.0.1k 8 Jan 2015
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 99.3.26.94 [99.3.26.94] port 22.
debug2: fd 3 setting O_NONBLOCK
debug1: connect to address 99.3.26.94 port 22: Connection timed out
ssh: connect to Host 99.3.26.94 port 22: Connection timed out
Où robots est mon hôte distant et 99.3.26.94 est mon serveur SSH local.
SSH est en cours d'exécution
volt@arnold:~$ ps -A | grep sshd
5784 ? 00:00:00 sshd
Où arnold est mon serveur SSH local.
La redirection de port est configurée sur le routeur
J'ai mon routeur domestique configuré pour transmettre les ports 80 et 22 à mon serveur SSH. Fait intéressant, le port 80 a fonctionné sans accroc - va directement au répertoire Web Apache. Port 22 - pas tellement.
NMap dit que c'est filtré
yoshimi@robots:/$ nmap -p 22 99.3.26.94
Starting Nmap 6.47 ( http://nmap.org ) at 2015-06-02 14:45 EDT
Nmap scan report for 99-3-26-94.lightspeed.bcvloh.sbcglobal.net (99.3.26.94)
Host is up (0.33s latency).
PORT STATE SERVICE
22/tcp filtered ssh
Nmap done: 1 IP address (1 Host up) scanned in 7.59 seconds
Où robots est mon hôte distant et 99.3.26.94 est mon serveur SSH local.
Ce n'est pas IPTables (je pense)
volt@arnold:~$ Sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
fail2ban-ssh tcp -- anywhere anywhere multiport dports ssh
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere tcp dpt:http
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain fail2ban-ssh (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
... Et je n'ai pas d'autre pare-feu en place - c'est un réseau Debian relativement récent.
Alors, alors: Quoi d'autre pourrait-il être? Il semble certainement être une sorte de pare-feu pour ignorer le trafic, mais si ce n'est pas le routeur, ce n'est pas iptables, et ce n'est pas un autre pare-feu sur le serveur SSH, ... qu'est-ce qu'il y a d'autre?
EDIT: demande de connexion à partir d'une erreur de réseau interne
yoshimi@robots:/$ ssh [email protected]
ssh: connect to Host 192.168.1.90 port 22: No route to Host
ne réponse très décevante
Après avoir mis ce problème de côté pendant une journée et y revenir, j'étais à la fois soulagé et perturbé (plus perturbé que soulagé) de constater que tout fonctionnait, mystérieusement, correctement.
Alors, quel était le problème?
Aucun paramètre n'a été modifié ou ajusté - ni sur le routeur, ni sur le serveur SSH, ni sur la machine du client SSH. Il est assez sûr de dire que le routeur ne gère pas correctement le trafic entrant, malgré les paramètres appropriés. Étant donné que le logiciel de routeur domestique dinky n'est pas vraiment conçu pour gérer la redirection de port, il a fallu du temps au pauvre homme pour mettre en œuvre les changements nécessaires.
Mais ça fait 6 heures !!
Ouais mec, je sais. J'ai passé toute la journée à essayer de comprendre ce qui n'allait pas - et je ne l'ai jamais trouvé parce qu'il n'y avait rien de mal. Évidemment, cela peut prendre 6 heures - peut-être plus - pour que les paramètres du routeur prennent effet.
Alors, comment savoir si c'est mon problème?
Un outil astucieux que j'ai rencontré lors de cette escapade est tcpdump. Ce petit gars maigre renifle le trafic pour vous, offrant un aperçu précieux de ce qui se passe réellement. De plus, il dispose de super fonctionnalités de filtrage qui vous permettent d'affiner exactement ce que vous voulez regarder/rechercher. Par exemple, la commande:
tcpdump -i wlan1 port 22 -n -Q inout
Indique à tcpdump de rechercher du trafic via l'interface wlan1 (-i = 'interface'), uniquement via le port 22, ignore la résolution de nom DNS (-n = 'aucune résolution de nom'), et nous voulons voir le trafic entrant et sortant (-Q accepte in, out ou inout; inout est la valeur par défaut).
En exécutant cette commande sur votre serveur SSH tout en essayant de vous connecter via une machine distante, il devient rapidement clair où se situe précisément le problème. Il existe essentiellement 3 possibilités:
- Si vous voyez du trafic entrant de la machine distante, mais aucun trafic sortant du trafic provenant de votre serveur local, le problème vient du serveur: il y a probablement une règle de pare-feu à changer, etc.
- Si vous voyez à la fois entrant et sortant , mais que votre machine distante ne reçoit pas la réponse, c'est probablement le routeur: il autorise le trafic entrant , mais en supprimant vos paquets sortants.
- S'il n'y a aucun trafic , c'est probablement aussi un problème de routeur: les paquets
SYNde la machine distante sont ignorés et abandonnés par le routeur avant même qu'ils n'atteignent votre serveur.
Et une fois que vous avez découvert où se situe le problème, une solution est (généralement) triviale.
J'utilise Mint (Ubuntu).
J'avais tout fait ... clé publique au format correct dans authorized_keys, chmodding, chowning, redémarrage ssh et sshd etc. Comme cela a été documenté partout.
Pour moi, c'était le pare-feu ufw. L'absence de toute réponse ssh m'a fait penser à cela, mais je n'ai pu cingler aucun problème dans les deux sens sur un réseau local.
J'ai testé par:
Sudo ufw service stop
... et cela a parfaitement fonctionné, c'est-à-dire que j'ai reçu une réponse d'un appel ssh.
Alors, redémarrez ufw:
Sudo ufw service start
... et ajoutez la règle:
Sudo ufw allow openssh
Tout fonctionne bien maintenant.
Si vous, comme moi, avez activé UFW (sous Linux, Ubuntu dans mon cas), essayez ceci:
Sudo ufw enable OpenSSH
Cela permettra à OpenSSH dans le pare-feu.
La plupart du temps, le pare-feu est un coupable. Faireservice iptables stop et service ip6tables stop.
Si l'arrêt du service ne fonctionne pas, effectuez un rinçage iptable.
iptables --flush.
Si c'est un VM alors faites de même dans l'hôte aussi
Juste pour les autres:
J'ai dû utiliser l'option -P dans tcpdump au lieu de -Q
tcpdump -i wlan1 port 22 -n -P inout