Ssh: raccordement réinitialisé par pair
J'ai un serveur Solaris 10 sur un autre réseau. Je peux ping et telnet à cela, mais SSH ne se connecte pas. Journal de mastic ne contient rien d'intérêt (ils négocient tous les deux à SSH V2), puis je reçois
"Event Log: Network error: Software caused connection abort".
ssh est en cours d'exécution:
svcs -a | grep ssh
online 12:12:04 svc:/network/ssh:default
Voici un extrait de The Server's/Var/AdM/SMS (anonymed)
Jun 8 19:51:05 ******* sshd[26391]: [ID 800047 auth.crit] fatal: Read from socket failed: Connection reset by peer
Cependant, si j'étais Telnet sur la boîte, je peux me connecter à SSH localement. Je peux aussi SSH à d'autres machines (non-Solaris) sur ce réseau, donc je ne crois pas que c'est une question de réseau (cependant, depuis que je suis à quelques centaines de kilomètres, je ne peux pas être sûr).
Le pare-feu du serveur est désactivé, de sorte que cela ne devrait pas être un problème
root@******** # svcs -a | grep -i ipf
disabled Apr_27 svc:/network/ipfilter:default
Des idées ce que je devrais commencer à vérifier?
Mise à jour : Basée sur les commentaires ci-dessous, j'ai exécuté sshd en mode de débogage. Voici la sortie du client:
$ ssh -vvv root@machine -p 32222
OpenSSH_5.0p1, OpenSSL 0.9.8h 28 May 2008
debug2: ssh_connect: needpriv 0
debug1: Connecting to machine [X.X.X.X] port 32222.
debug1: Connection established.
debug1: identity file /home/lawrencj/.ssh/identity type -1
debug1: identity file /home/lawrencj/.ssh/id_rsa type -1
debug1: identity file /home/lawrencj/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.1
debug1: no match: Sun_SSH_1.1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.0
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
Read from socket failed: Connection reset by peer
Et voici la sortie du serveur:
root@machine # /usr/lib/ssh/sshd -d -p 32222
debug1: sshd version Sun_SSH_1.1
debug1: read PEM private key done: type RSA
debug1: private Host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private Host key: #1 type 2 DSA
debug1: Bind to port 32222 on ::.
Server listening on :: port 32222.
debug1: Bind to port 32222 on 0.0.0.0.
Server listening on 0.0.0.0 port 32222.
debug1: Server will not fork when running in debugging mode.
Connection from 1.2.3.4 port 2652
debug1: Client protocol version 2.0; client software version OpenSSH_5.0
debug1: match: OpenSSH_5.0 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-Sun_SSH_1.1
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible
Unknown code 0
)
debug1: SSH2_MSG_KEXINIT sent
Read from socket failed: Connection reset by peer
debug1: Calling cleanup 0x4584c(0x0)
Cette ligne semble un candidat probable:
debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible
Vérifiez votre fichier .SSH/Authorize_Keys sur le serveur si vous utilisez une authentification basée sur la clé. J'avais le même problème et la personne qui avait mis en place l'accès avait collé la clé avec des pauses de ligne. Supprimer les pauses de la ligne fixe le problème, bien que vous puissiez tester en déplaçant le fichier autorisé_keys hors du chemin, ou en choisissant l'authentification par mot de passe. Premièrement, voir si vous obtenez le même problème:
ssh -o PreferredAuthentications=password username@hostname
Essayez de désactiver complètement Gssapi:
GSSAPIAuthentication no
Êtes-vous dans la liste des utilisateurs autorisés dans sshd_config?
C'est intéressant, j'ai le même problème. Seulement je peux ssh du réseau local mais pas lors de l'utilisation de VPN.
11 mai 18:03:10 ServerName Sshd [14733]: [ID 800047 Auth.Crit] Fatal: Lire de la prise Échec de la prise: Réinitialisation de la connexion par pair
Je ne suis jamais invité à pw. Les sessions meurent rapidement.
Vous pourriez être en mesure d'obtenir des informations de débogage plus utiles en exécutant sshd avec le -d drapeau (et éventuellement le -p Drapeau Pour spécifier un autre port si vous souhaitez quitter l'original sshd exécutant), puis en vous connectant avec votre ssh -v client.
Mise à jour : On dirait que votre problème est associé au réseau plutôt que l'authentification. Vous pouvez voir que les deux côtés de la conversation avaient leur réinitialisation de connexion. Vous pouvez vérifier auprès de l'équipe réseau concernée pour voir s'il existe un nœud de réseau intermédiaire (par exemple un pare-feu) qui cause le problème.
Ceci est 99% du temps causé par TCP wrappers (host.deny). Vous devez probablement autoriser votre adresse IP à là:
/etc/hosts.deny
La raison pour laquelle il fonctionne à partir de Localhost est parce que 127.0.0.1 est probablement autorisée là-bas (ou via /etc/hosts.allow).
Vos fourches Sshd pour gérer la connexion (même sur le débogage). Il me semble que l'enfant meurt silencieusement dès qu'il est sur le point d'interagir avec les mécanismes d'authentification du système. Ceci est à peu près au moment où il vérifie normalement l'UID, GID et gère PAM. Votre serveur utilise-t-il LDAP ou NIS +?
Il est préférable de lancer le débogage sur un serveur fonctionnel et de voir ce qui devrait venir ensuite (utiliser Vimdio ou Diff).
J'ai récemment un problème très similaire lorsqu'un groupe avait trop de membres (la longueur de tous les membres était d'environ 500 à 600 caractères). Bien que cela soit sur Linux.
Notha Bene, lors de la course à pied pour débogage, spécifiez -ddd (triple débogage) pour obtenir plus d'informations.
J'ai soupçonné quelque chose à voir avec des problèmes d'échange de clés puisque vous dites que SSHV2 est négocié.
Ne pouvait trouver aucune bonne description à ce sujet; Il y a cette référence de mastic cependant.
vous devriez essayer une capture de paquets sur le serveur pour voir où la communication SSH s'arrête.
Vous pouvez aussi essayer "ssh -v "Pour voir quelles erreurs le client voit.
Vous dites que l'hôte de destination est dans un autre réseau. Et que le "pare-feu des serveurs est désactivé".
Y a-t-il un pare-feu ou un type de périphérique de filtrage de paquets entre votre réseau et votre réseau de destination.
Cela vaut la peine de faire une traceroute pour voir ce qui se situe entre les deux réseaux.
Assurez-vous également que vous ne perdez pas de paquets pendant la transmission. Un test simple avec Ping pourrait vous aider à déterminer si vous avez des problèmes de réseau.
Je viens de résoudre un problème similaire avec le même symptôme: déconnecté après:
debug1: SSH2_MSG_KEXINIT sent.
Exécuter SSH Server sur deux ports, 22 et "Un autre port non divulgué". Je pourrais vous connecter à l'aide du port 22 mais n'utilisez pas l'autre port avec la déconnexion soudaine ci-dessus avant l'échange de clé d'hôte.
Il s'est avéré que SSHD pour le port 22 fonctionnait comme root tandis que SSHD pour l'autre port, il fonctionnait comme utilisateur bunt. Évidemment, l'utilisateur Ubuntu ne peut pas lire la touche hôte privée comme indiqué dans / var/log/auth.log:
error: Could not load Host key: /etc/ssh/ssh_Host_rsa_key
error: Could not load Host key: /etc/ssh/ssh_Host_dsa_key
fatal: No supported key exchange algorithms
La commande 'sudo netstat -nap | grep ssh' renvoyé 2 processus différents pour le port 22 et l'autre port (édité):
$ Sudo netstat -nap | grep ssh
tcp 0 0 0.0.0.0:other port 0.0.0.0:* LISTEN 17620/sshd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 31160/sshd
tcp6 0 0 :::other port :::* LISTEN 17620/sshd
tcp6 0 0 :::22 :::* LISTEN 31160/sshd
Affiche que SSH Server sur le port 22 utilise le processus # 116 tandis que l'autre port utilise le port de port 1762.
Et 'ps -af | Grep SSH 'a montré qu'un processus fonctionnait comme une racine tandis que l'autre utilisait comme Ubuntu (édité):
$ ps -eaf | grep ssh
ubuntu 17620 1 0 Apr25 ? 00:00:00 /usr/sbin/sshd
root 31160 1 0 08:35 ? 00:00:00 /usr/sbin/sshd
Pour résoudre le problème, je devais tuer le processus fonctionnant comme Ubuntu (tuer 1762) et redémarrez le serveur SSH à l'aide de la commande 'sudo /etc/init.d/ssh redémarrage'.
Je ne sais pas avec certitude comment cela s'est passé, mais après avoir essayé de reproduire la question, j'ai constaté que j'avais essayé de redémarrer Sshd sans racine. Cela fonctionne, mais le nouveau port est hébergé par l'utilisateur Ubuntu:
$ /etc/init.d/ssh restart
Could not load Host key: /etc/ssh/ssh_Host_rsa_key
Could not load Host key: /etc/ssh/ssh_Host_dsa_key
* Restarting OpenBSD Secure Shell server sshd
start-stop-daemon: warning: failed to kill 31884: Operation not permitted
Could not load Host key: /etc/ssh/ssh_Host_rsa_key
Could not load Host key: /etc/ssh/ssh_Host_dsa_key
Si c'est ce que j'ai fait, j'ai été mordu pour ignorer ces messages d'erreur. Néanmoins, cela peut être considéré comme un bogue puisque le serveur ne peut plus être redémarré correctement sans tuer le SSHD UBUNTU-RUNING.
Pour ceux qui se demandent, j'utilise un autre port au lieu du port 22 pour empêcher la plupart des tentatives de connexion du port 22 sur tous mes serveurs, puis bloquez le port 22 à l'aide d'un pare-feu. C'est simple mais fonctionne et me permet de vous connecter de n'importe quelle adresse IP.