Réinitialisation de la connexion par un pair à l'aide de sshfs

32

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' read: Connection reset by peererreur classique . 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.logniveau 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 sshfsmontage manuel et j'obtiens aussi 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 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
ssh sshfs André Stannek
la source
1
La sortie ressemble exactement à celle d'une session ssh qui refuse de se connecter en raison d'une incompatibilité d'empreinte digitale de la clé du serveur (ou d'une clé inconnue). Le sftpserveur fonctionne-t-il correctement?
peterph
J'ai essayé sftp avec Nautilus ( Connect to Server...option) et Filezilla. Ça fonctionne bien. Bien que Filezilla m'ait demandé une clé d'hôte inconnue.
André Stannek
Essayez sftpdirectement - c'est ce que SSHFS utilise.
peterph
4
Ça me semble pareil. Avez-vous essayé d'obtenir des informations de débogage du client? sshfs -odebug,sshfs_debug,loglevel=debug ...pourrait faire l'affaire (extrait de sourceforge.net/apps/mediawiki/fuse/index.php?title=SshfsFaq ).
peterph
1
@peterph a déjà eu cette idée ;-) Voir ma deuxième mise à jour. J'ai juste omis les paramètres de débogage dans la commande publiée ici mais je l'ai exécuté avec eux.
André Stannek

Réponses:

21

J'utilisais l' -F /path/to/configoption. 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
Sanchke Dellowar
la source
man ssh-configautorise explicitement tilde pourIdentityFile
CharlesB
4
@CharlesB Je l'ai testé dans les deux sens et je vous assure que ma réponse est valide. Et je vois de quoi vous parlez dans les pages de manuel. C'est peut-être un bug lors de l'exécution avec sudo? (parce que je suis)
Sanchke Dellowar
7
bien sûr, si vous exécutez sshfs avec sudo, tilde est le domicile de l'utilisateur root. alors vous devez spécifier le chemin absolu.
CharlesB
1
Même si vous utilisez des chemins absolus dans votre ~/.ssh/configfichier, l'exécution sudo sshfslira par défaut le /root/.ssh/configfichier racine (le cas échéant). Vous devez passer le chemin explicite vers votre fichier de configuration via -F.
Dan Dascalescu
14

Après beaucoup plus d'essais, il s'avère que mon utilisateur client n'était pas dans le fusegroupe. Après l'avoir ajouté avec sudo usermod -a -G fuse myuserle support, il fonctionne à nouveau correctement. Ne me demandez pas comment cela aurait pu fonctionner avant de réinstaller le serveur. Merci pour toute votre aide!

André Stannek
la source
2
est-ce l'utilisateur sur le système de fichiers local ou distant?
Woodrow Barlow le
1
@WoodrowBarlow pour être honnête, je ne sais plus: D Ma meilleure supposition serait locale, car c'est là que vous utilisez le fusible.
André Stannek
ougpasswd --add USER fuse
deceleratedcaviar
Dans mon cas, j'avais simplement besoin du numéro de port. Cela a été ajouté avec l' -poption.
Paradox
11

É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 dit ailleurs, les causes courantes comprennent manquantes allow_otherdans fuse.confou manquants fuseappartenance à un groupe (bien que ne peut pas être 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)

eddygeek
la source
En utilisant -o debug, j'ai obtenu la ligne de commande 0: spécification de chiffrement SSH2 incorrecte «arcfour».
Salathiel Genèse
8

J'ai eu le même problème aujourd'hui. sshla connexion est OK, sshfsne l'est pas. Mon serveur SSH est un NAS Qnap (TS-228).

Le problème a été résolu en activant SFTP sur le périphérique NAS.

Un paramètre supplémentaire est apparu dans sshd_config:

Subsystem sftp /usr/libexec/sftp-server
Geom
la source
1
Cette solution ne fonctionne pas pour moi. J'apprécie donc d'avoir autre chose à essayer.
Hérisson dément
L'activation de SFTP sur mon Synology NAS a également résolu l'erreur pour moi. MAIS le contenu affiché dans le dossier monté n'est pas le même que lors de la connexion directe via ssh. Les dossiers sont manquants et la racine n'est pas accessible. Bummer.
Heinrich Ulbricht
5

J'ai trouvé que mon problème, qui était similaire, était lié au fichier de configuration des fusibles dans:

/etc/fuse.conf

J'ai dû commenter:

user_allow_other
cennings
la source
5

Juste au cas où quelqu'un trébuche sur ce fil: j'ai eu cette read: Connection reset by peererreur car le nom d'hôte n'était pas résoluble (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.

Bob Lauer
la source
sshfs server-ssh-alias: / some / dir / mnt ne fonctionnait pas pour moi, mais sshfs real.servername.org:/some/dir / mnt fonctionnait pour moi. (combiné avec user_allow_other)
Brian C.
2

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.

Arashr
la source
1
S'il vous plaît, ne votez pas sans dire pourquoi. C'est une chose raisonnable à vérifier.
Hérisson dément
2

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.

J.Bravo
la source
2

Vous avez la même erreur lors de l'exécution sudo sshfs [...] myhost: /mnt/myhost, où myhostest défini dans mes ~/.ssh/configfichiers.

Le problème est que l'exécution sudo sshfsn'a pas cherché 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
Dan Dascalescu
la source
1

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.

mdxe
la source
1

Pour ceux qui recherchent une solution très simple: 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
sandoval31
la source
1

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

route add gw 192.169.0.254 par défaut

, puis redémarré le système.

Le problème est résolu après le redémarrage.

Pointe
la source
2
Vous avez obtenu une "connexion réinitialisée par un pair" avec une mauvaise passerelle?!?
Jeff Schaller
1

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.

afardana
la source