Réinitialisation de la connexion par un pair à l'aide de sshfs
J'utilise un support Fuse/sshfs qui a bien fonctionné jusqu'à présent. Maintenant, je devais réinstaller le système serveur et obtenir soudainement l'erreur classique read: Connection reset by peer. J'utilise l'authentification par clé publique et j'ai copié ma clé sur le système nouvellement installé. La connexion ssh normale fonctionne correctement. J'ai changé le journal pour déboguer mais malheureusement cela ne me donne aucune information utile:
sshd[2077]: debug1: Forked child 2198.
sshd[2198]: Set /proc/self/oom_score_adj to 0
sshd[2198]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
sshd[2198]: debug1: inetd sockets after dupping: 3, 3
sshd[2198]: Connection from 192.168.1.6 port 47991
sshd[2198]: debug1: Client protocol version 2.0; client software version OpenSSH_6.1p1 Debian-4
sshd[2198]: debug1: match: OpenSSH_6.1p1 Debian-4 pat OpenSSH*
sshd[2198]: debug1: Enabling compatibility mode for protocol 2.0
sshd[2198]: debug1: Local version string SSH-2.0-OpenSSH_6.1p1 Debian-4
sshd[2198]: debug1: permanently_set_uid: 103/65534 [preauth]
sshd[2198]: debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
sshd[2198]: debug1: SSH2_MSG_KEXINIT sent [preauth]
sshd[2198]: debug1: SSH2_MSG_KEXINIT received [preauth]
sshd[2198]: debug1: kex: client->server aes128-ctr hmac-md5 none [preauth]
sshd[2198]: debug1: kex: server->client aes128-ctr hmac-md5 none [preauth]
sshd[2198]: debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
sshd[2198]: debug1: SSH2_MSG_NEWKEYS sent [preauth]
sshd[2198]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]
sshd[2198]: Connection closed by 192.168.1.6 [preauth]
sshd[2198]: debug1: do_cleanup [preauth]
sshd[2198]: debug1: monitor_read_log: child log fd closed
sshd[2198]: debug1: do_cleanup
sshd[2198]: debug1: Killing privsep child 2199
Quelqu'un at-il une idée de ce qui me manque ici?
MISE À JOUR
Le auth.log Avec le niveau de débogage 3:
sshd[2455]: debug3: fd 5 is not O_NONBLOCK
sshd[2455]: debug1: Forked child 2456.
sshd[2455]: debug3: send_rexec_state: entering fd = 8 config len 751
sshd[2455]: debug3: ssh_msg_send: type 0
sshd[2455]: debug3: send_rexec_state: done
sshd[2456]: debug3: oom_adjust_restore
sshd[2456]: Set /proc/self/oom_score_adj to 0
sshd[2456]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
sshd[2456]: debug1: inetd sockets after dupping: 3, 3
sshd[2456]: Connection from 192.168.1.6 port 50037
sshd[2456]: debug1: Client protocol version 2.0; client software version OpenSSH_6.1p1 Debian-4
sshd[2456]: debug1: match: OpenSSH_6.1p1 Debian-4 pat OpenSSH*
sshd[2456]: debug1: Enabling compatibility mode for protocol 2.0
sshd[2456]: debug1: Local version string SSH-2.0-OpenSSH_6.1p1 Debian-4
sshd[2456]: debug2: fd 3 setting O_NONBLOCK
sshd[2456]: debug2: Network child is on pid 2457
sshd[2456]: debug3: preauth child monitor started
sshd[2456]: debug3: privsep user:group 103:65534 [preauth]
sshd[2456]: debug1: permanently_set_uid: 103/65534 [preauth]
sshd[2456]: debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
sshd[2456]: debug1: SSH2_MSG_KEXINIT sent [preauth]
sshd[2456]: debug1: SSH2_MSG_KEXINIT received [preauth]
sshd[2456]: debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected] [preauth]
sshd[2456]: debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected] [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,[email protected] [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,[email protected] [preauth]
sshd[2456]: debug2: kex_parse_kexinit: [preauth]
sshd[2456]: debug2: kex_parse_kexinit: [preauth]
sshd[2456]: debug2: kex_parse_kexinit: first_kex_follows 0 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: reserved 0 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],[email protected],[email protected],ssh-rsa,ssh-dss [preauth]
sshd[2456]: debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected] [preauth]
sshd[2456]: debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected] [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,[email protected],zlib [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,[email protected],zlib [preauth]
sshd[2456]: debug2: kex_parse_kexinit: [preauth]
sshd[2456]: debug2: kex_parse_kexinit: [preauth]
sshd[2456]: debug2: kex_parse_kexinit: first_kex_follows 0 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: reserved 0 [preauth]
sshd[2456]: debug2: mac_setup: found hmac-md5 [preauth]
sshd[2456]: debug1: kex: client->server aes128-ctr hmac-md5 none [preauth]
sshd[2456]: debug2: mac_setup: found hmac-md5 [preauth]
sshd[2456]: debug1: kex: server->client aes128-ctr hmac-md5 none [preauth]
sshd[2456]: debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
sshd[2456]: debug3: mm_key_sign entering [preauth]
sshd[2456]: debug3: mm_request_send entering: type 5 [preauth]
sshd[2456]: debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN [preauth]
sshd[2456]: debug3: mm_request_receive_expect entering: type 6 [preauth]
sshd[2456]: debug3: mm_request_receive entering [preauth]
sshd[2456]: debug3: mm_request_receive entering
sshd[2456]: debug3: monitor_read: checking request 5
sshd[2456]: debug3: mm_answer_sign
sshd[2456]: debug3: mm_answer_sign: signature 0x7f9b687c7680(100)
sshd[2456]: debug3: mm_request_send entering: type 6
sshd[2456]: debug2: monitor_read: 5 used once, disabling now
sshd[2456]: debug2: kex_derive_keys [preauth]
sshd[2456]: debug2: set_newkeys: mode 1 [preauth]
sshd[2456]: debug1: SSH2_MSG_NEWKEYS sent [preauth]
sshd[2456]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]
sshd[2456]: Connection closed by 192.168.1.6 [preauth]
sshd[2456]: debug1: do_cleanup [preauth]
sshd[2456]: debug3: PAM: sshpam_thread_cleanup entering [preauth]
sshd[2456]: debug1: monitor_read_log: child log fd closed
sshd[2456]: debug3: mm_request_receive entering
sshd[2456]: debug1: do_cleanup
sshd[2456]: debug3: PAM: sshpam_thread_cleanup entering
sshd[2456]: debug1: Killing privsep child 2457
MISE À JOUR
J'ai essayé un montage manuel sshfs et j'obtiens également read: Connection reset by peer. J'ai ensuite ajouté les options de débogage et j'ai également obtenu Permission denied (publickey).. C'est étrange car la clé publique est en place et fonctionne bien sinon. J'utilise également mon utilisateur pour la connexion ssh et spécifie manuellement le fichier de clé privée. Serait-ce un problème avec le compte root ne pouvant pas accéder à la bonne clé publique sur le serveur quelque part? J'exécute
Sudo sshfs myuser@myserver:/mnt/foo /mnt/foo -o IdentityFile=/home/myuser/.ssh/id_rsa
et la partie de journal pertinente est
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/myuser/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).
read: Connection reset by peer
Après beaucoup plus d'essais, il s'avère que mon utilisateur client n'était pas dans le groupe Fuse. Après l'avoir ajouté avec Sudo usermod -a -G Fuse myuser la monture fonctionne à nouveau correctement. Ne me demandez pas comment cela aurait pu fonctionner avant de réinstaller le serveur. Merci pour toute votre aide!
J'utilisais le -F /path/to/config option. La réponse était dans mon fichier de configuration où j'avais
IdentityFile ~/.ssh/id_rsa
qui n'a pas fonctionné. Le chemin absolu est obligatoire:
IdentityFile /home/user/.ssh/id_rsa
Étant donné que ce message d'erreur est celui par défaut lorsque la connexion ssh échoue, la réponse la plus générique (par commentaire @peterph) consiste à rechercher en utilisant au moins -odebug:
sshfs -odebug,sshfs_debug,loglevel=debug ...
par exemple
sshfs -odebug,sshfs_debug,loglevel=debug -o Ciphers=arcfour -o Compression=no -o allow_root -o transform_symlinks localhost:/ /mnt/your_mount_point
Comme indiqué ailleurs, les causes courantes incluent le manque de allow_other dans Fuse.conf ou manquant Fuse appartenance à un groupe (bien que cela ne soit plus nécessaire sur Ubuntu 18.04?)
Dans mon cas, cela a imprimé:
SSHFS version 2.8 Fuse library version: 2.9.7 nullpath_ok: 0 nopath: 0 utime_omit_ok: 0 executing <ssh> <-x> <-a> <-oClearAllForwardings=yes> <-ologlevel=debug> <-oIdentityFile=~/.ssh/id_rsa> <-oCiphers=arcfour> <-oCompression=no> <-2> <localhost> <-s> <sftp> command-line line 0: Bad SSH2 cipher spec 'arcfour'. read: Connection reset by peer
... pointant vers une option de chiffrement non prise en charge (fonctionnant sur Fedora mais pas ubuntu)
J'ai eu le même problème aujourd'hui. ssh la connexion est OK, sshfs ne l'est pas. Mon serveur SSH est Qnap NAS (TS-228).
Le problème a été résolu par activation de SFTP sur NAS.
Un paramètre supplémentaire est apparu dans sshd_config:
Subsystem sftp /usr/libexec/sftp-server
J'ai trouvé que mon problème, qui était similaire, était lié au fichier de configuration Fuse dans:
/etc/Fuse.conf
J'ai dû commenter:
user_allow_other
Juste au cas où quelqu'un trébuche sur ce fil: j'ai eu ce read: Connection reset by peer erreur car le nom d'hôte n'était pas résol (je n'utilisais pas d'hôte qualifié complet). L'utilisation du bon nom d'hôte a résolu le problème - le message d'erreur est alors complètement trompeur.
Un bon test consiste à ssh sur la machine avant d'exécuter la commande sshfs, si cela ne fonctionne même pas, sshfs ne fonctionnera pas non plus.
J'ai eu cette erreur et j'ai essayé les méthodes ci-dessus et je n'ai pas réussi à le faire fonctionner.
Le problème était que le serveur n'acceptait pas ssh au port 22. J'ai utilisé:
$sshfs -p 2222 user@server:/path/to/folder ~/local/path
et cela a résolu le problème.
Vous avez la même erreur lors de l'exécution de Sudo sshfs [...] myhost: /mnt/myhost, où myhost est défini dans mon ~/.ssh/config des dossiers.
Le problème est que l'exécution de Sudo sshfs n'a pas recherché dans mon répertoire personnel ~/.ssh/config, mais dans roots. La solution était de passer explicitement le fichier de configuration via -F:
Sudo sshfs -F /home/dandv/.ssh/config [...] myhost: /mnt/myhost
Mon erreur était côté serveur. Le sous-système sftp pour sshd est apparemment par défaut non disponible sur les nouveaux centos 7.6.xx. corrigé en supprimant "#" devant ce qui suit dans/etc/ssh/sshd_config
Subsystem sftp /usr/libexec/openssh/sftp-server
merci à eddygeek pour la recette -odebug pour aider à trouver ce problème. Identique à GEOM ci-dessus mais non spécifique à Qnap.
Pour ceux qui recherchent une solution simple très: après avoir exécuté sshfs en mode débogage, j'ai trouvé que ma connexion était rompue.
Activez le mode verbeux avec le commutateur:
-o debug
Dans mon cas, c'était l'interface du serveur qui ne fonctionnait pas après un long démarrage. Le serveur est connecté à un port de commutateur Cisco avec mode trunk. Étant donné que n'importe quel port de ligne réseau effectuera diverses vérifications avant de devenir réellement UP (généralement plus de 30 secondes), cela a entraîné le message d'erreur de réinitialisation de connexion ci-dessus.
Ma solution a été de changer le port du commutateur en mode d'accès avec spanning-tree portfast, car dans mon environnement le mode trunk n'est pas nécessaire pour ce serveur.
J'ai également découvert ce problème en utilisant le paramètre de débogage pour sshfs.
J'ai eu un problème similaire, et lorsque j'ai vérifié la configuration du réseau, le système a perdu l'adresse de la passerelle. J'ai donc exécuté la commande ci-dessous
ajouter par défaut gw 192.169.0.254
puis redémarré le système.
Le problème est résolu après le redémarrage.
J'ai effacé l'empreinte digitale de l'hôte de /home/user/.ssh/known_hosts (en fait supprimé le fichier entier) et il l'a corrigé ... parce que l'empreinte digitale avait changé. l'utilisation de ssh pour se connecter à l'hôte a clairement expliqué pourquoi il ne se connectait pas.
Si quelqu'un a toujours des problèmes et est un idiot comme moi, assurez-vous que vous n'avez pas créé le nouveau répertoire (sur votre système local) en utilisant Sudo.
Parce qu'alors vous (l'utilisateur local) n'y aurez pas accès en écriture.
Ce qui le rend impossible à utiliser comme point de montage.
La solution rapide pour cela est Sudo chown -R localuser:localuser ~/directory_you_created
(Échangez localuser avec votre nom d'utilisateur réel).
À votre santé.