Redefinição de conexão por ponto usando sshfs

32

Estou usando um suporte de fusível / sshfs que funcionou bem até agora. Agora eu tive que reinstalar o sistema do servidor e de repente obter o read: Connection reset by peererro clássico . Estou usando a autenticação de chave pública e copiei minha chave para o sistema recém-instalado. O login ssh normal funciona bem. Alterei o log para depuração, mas infelizmente isso não me fornece nenhuma informação útil:

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

Alguém tem uma idéia do que estou perdendo aqui?

ATUALIZAR

O auth.logcom nível de depuração 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,rijndael-cbc@lysator.liu.se [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,rijndael-cbc@lysator.liu.se [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,zlib@openssh.com [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,zlib@openssh.com [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: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,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,rijndael-cbc@lysator.liu.se [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,rijndael-cbc@lysator.liu.se [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,zlib@openssh.com,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

ATUALIZAR

Eu tentei uma sshfsmontagem manual e também recebo read: Connection reset by peer. Eu adicionei as opções de depuração e também obtive Permission denied (publickey).. Isso é estranho, pois a chave pública está no lugar e funciona bem caso contrário. Eu também uso meu usuário para a conexão ssh e especifique manualmente o arquivo de chave privada. Isso poderia ser um problema com a conta raiz não conseguir acessar a chave pública correta no servidor em algum lugar? Estou executando

sudo sshfs myuser@myserver:/mnt/foo /mnt/foo -o IdentityFile=/home/myuser/.ssh/id_rsa

e a parte do log relevante é

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
fonte
11
A saída se parece exatamente com a de uma sessão ssh que se recusa a conectar devido à incompatibilidade de impressão digital da chave do servidor (ou uma chave desconhecida). O sftpservidor funciona corretamente?
— Peterph 12/10
Eu tentei o sftp com o Nautilus ( Connect to Server...opção) e o Filezilla. Funciona bem. Embora o Filezilla tenha me perguntado sobre uma chave de host desconhecida.
— André Stannek 12/10
Tente sftpdiretamente - é isso que o SSHFS usa.
— Peterph #
4
Parece o mesmo para mim. Você tentou obter algumas informações de depuração do cliente? sshfs -odebug,sshfs_debug,loglevel=debug ...poderia fazer o truque (extraído de sourceforge.net/apps/mediawiki/fuse/index.php?title=SshfsFaq ).
— Peterph 12/10
11
@peterph já teve essa ideia ;-) Veja minha segunda atualização. Eu apenas omiti os parâmetros de depuração no comando postado aqui, mas eu o executei com eles.
— André Stannek

Respostas:

21

Eu estava usando a -F /path/to/configopção A resposta estava no meu arquivo de configuração onde eu tinha

IdentityFile ~/.ssh/id_rsa

o que não deu certo. O caminho absoluto é necessário:

IdentityFile /home/user/.ssh/id_rsa
— Sanchke Dellowar
fonte
man ssh-configpermite explicitamente til paraIdentityFile
— CharlesB 04/04
4
@CharlesB Eu testei nos dois sentidos e garanto que minha resposta é válida. E vejo o que você está referenciando nas páginas de manual. Talvez seja um bug ao executar com o sudo? (porque eu sou)
— Sanchke Dellowar
7
claro, se você estiver executando o sshfs com o sudo, o tilde é a casa do usuário root. então você precisa especificar o caminho absoluto.
— precisa
11
Mesmo se você usar caminhos absolutos no seu ~/.ssh/configarquivo, a execução sudo sshfs, por padrão, lerá o /root/.ssh/configarquivo raiz (se houver). Você precisa passar o caminho explícito para o seu arquivo de configuração via -F.
— Dan Dascalescu 02/07
14

Depois de muito mais tentativas, meu usuário cliente não estava no fusegrupo. Depois que eu adicionei com sudo usermod -a -G fuse myusera montagem funciona bem novamente. Não me pergunte como poderia ter funcionado antes de reinstalar o servidor. Obrigado por toda a sua ajuda!

— André Stannek
fonte
2
esse é o usuário no sistema de arquivos local ou remoto?
— precisa saber é o seguinte
11
@WoodrowBarlow, para ser sincero, não sei mais: D Meu melhor palpite seria local, já que é aqui que você usa o fusível.
— André Stannek 4/17/17
ougpasswd --add USER fuse
— deceleratedcaviar
No meu caso, eu simplesmente precisava do número da porta. Isso foi adicionado com a -popção
— Paradox
11

Como essa mensagem de erro é a padrão quando a conexão ssh falha, a resposta mais genérica (por comentário do @peterph) é investigar usando pelo menos -odebug:

sshfs -odebug,sshfs_debug,loglevel=debug ...

por exemplo

sshfs -odebug,sshfs_debug,loglevel=debug -o Ciphers=arcfour -o Compression=no -o allow_root -o transform_symlinks localhost:/ /mnt/your_mount_point

Como disse em outro lugar, causas comuns incluem falta allow_otherem fuse.confou faltando fuseassociação de grupo (apesar de que pode não ser mais necessário no Ubuntu 18.04?)

No meu caso, este impresso:

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

... apontando para uma opção de cifra não suportada (trabalhando no fedora, mas não no ubuntu)

— eddygeek
fonte
Usando -o debug, obtive a linha de comando 0: Especificação de cifra SSH2 incorreta 'arcfour'.
— Salathiel Genèse
8

Eu tive o mesmo problema hoje. sshconexão está OK, sshfsnão está. Meu servidor SSH é o Qnap NAS (TS-228).

O problema foi corrigido ativando o SFTP no dispositivo NAS.

Configuração adicional apareceu em sshd_config:

Subsystem sftp /usr/libexec/sftp-server
— Geom
fonte
11
Essa solução não funciona para mim. Então, eu aprecio ter outra coisa para tentar.
— ouriço demente
A ativação do SFTP no meu Synology NAS também resolveu o erro para mim. MAS o conteúdo exibido na pasta montada não é o mesmo que ao conectar diretamente via ssh. Faltam pastas e a raiz não pode ser acessada. Vadio.
— Heinrich Ulbricht
5

Eu encontrei o meu problema, que era semelhante, relacionado ao arquivo de configuração do fusível em:

/etc/fuse.conf

Eu tive que cancelar o comentário:

user_allow_other
— cennings
fonte
5

Apenas no caso de alguém tropeçar nesse segmento: Eu tive esse read: Connection reset by peererro porque o nome do host não era resolvível (eu não estava usando um host totalmente qualificado). O uso do nome do host correto resolveu o problema - a mensagem de erro é completamente enganosa.

Um bom teste é fazer o ssh na máquina antes de executar o comando sshfs, se isso nem funcionar, o sshfs também não funcionará.

— Bob Lauer
fonte
sshfs server-ssh-alias: / some / dir / mnt não funcionou para mim, mas sshfs real.servername.org:/some/dir / mnt funcionou para mim. (combinado com user_allow_other)
— Brian C.
2

Eu recebi esse erro e tentei os métodos acima e falhei ao fazê-lo funcionar.

O problema era que o servidor não estava aceitando ssh na porta 22. Eu usei:

$sshfs -p 2222 user@server:/path/to/folder ~/local/path

e resolveu o problema.

— Arashr
fonte
11
Por favor, não diminua o voto sem dizer o porquê. Isso é uma coisa razoável para verificar.
— ouriço demente
2

Meu erro foi no servidor. O subsistema sftp para sshd aparentemente parece não estar disponível nos centos 7.6.xx mais recentes. corrigido removendo "#" da frente do seguinte em / etc / ssh / sshd_config

Subsystem sftp /usr/libexec/openssh/sftp-server

obrigado a eddygeek pela receita -odebug para ajudar a encontrar esse problema. O mesmo que o GEOM acima, mas não específico para o Qnap.

— J.Bravo
fonte
2

Obtive o mesmo erro durante a execução sudo sshfs [...] myhost: /mnt/myhost, onde myhosté definido nos meus ~/.ssh/configarquivos.

O problema é que a execução sudo sshfsnão procurou no meu diretório pessoal ~/.ssh/config, mas em roots. A solução foi passar explicitamente o arquivo de configuração via -F:

sudo sshfs -F /home/dandv/.ssh/config [...] myhost: /mnt/myhost
— Dan Dascalescu
fonte
1

Eu apaguei a impressão digital do host de /home/user/.ssh/known_hosts (na verdade, excluiu o arquivo inteiro) e o corrigi ... porque a impressão digital havia mudado. O uso do ssh para conectar-se ao host deu uma razão clara do motivo pelo qual não estava se conectando.

— mdxe
fonte
1

Para aqueles que procuram uma solução muito simples: Depois de executar o sshfs no modo de depuração, descobri que minha conexão estava interrompida.

Ative o modo detalhado com o interruptor:

-o debug
— sandoval31
fonte
1

Eu tive um problema semelhante e, quando verifiquei a configuração da rede, sistema de alguma forma perdeu o endereço do gateway. Então eu executei o comando abaixo

rota adicione o padrão gw 192.169.0.254

e depois reinicie o sistema.

O problema foi resolvido após a reinicialização.

— Entalhe
fonte
2
Você obteve "redefinição de conexão por pares" com um gateway incorreto?!?
— Jeff Schaller
1

No meu caso, era a interface do servidor que não estava funcionando após um longo período de inicialização. O servidor está conectado a uma porta de switch Cisco com modo de tronco. Como qualquer porta de tronco fará várias verificações antes de se tornar UP (geralmente mais de 30 segundos), isso resultou na mensagem de erro de redefinição de conexão acima.

Minha solução foi alterar a porta do switch para acessar o modo spanning-tree portfast, pois no meu ambiente o modo de tronco é desnecessário para este servidor.

Eu também descobri esse problema usando o parâmetro debugging no sshfs.

— afardana
fonte
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.