Não é possível estabelecer a conexão ssh: “debug1: read_passphrase: não é possível abrir / dev / tty: nenhum desses arquivos ou diretórios” e “Falha na verificação da chave do host”.

Question

Não consigo estabelecer uma conexão ssh com um dos meus servidores remotos.

Eu tenho o endereço, nome de usuário e senha para ambos.

Para criar as conexões ssh da seguinte forma ssh user@server , o que me dá o seguinte erro Host key verification failed.

A resposta mais comum para este tópico é executar ssh-keygen -R hostname . O problema está no meu servidor remoto eu tenho direitos muito limitados e me dá o erro ssh-keygen: command is not found . Geralmente, comandos como service ou su me dão o mesmo erro command is not found .

Como posso criar uma conexão por SFTP com o Filezilla, posso consertar isso manualmente? Além disso, se for importante, meu diretório .ssh está vazio, então não há known_host ou algo assim.

Aqui está a saída completa de ssh -v user@server

OpenSSH_6.6.1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Connecting to XXX port 22.
debug1: Connection established.
debug1: identity file /.ssh/id_rsa type -1
debug1: identity file /.ssh/id_rsa-cert type -1
debug1: identity file /.ssh/id_dsa type -1
debug1: identity file /.ssh/id_dsa-cert type -1
debug1: identity file /.ssh/id_ecdsa type -1
debug1: identity file /.ssh/id_ecdsa-cert type -1
debug1: identity file /.ssh/id_ed25519 type -1
debug1: identity file /.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1Debian-5+deb8u4
debug1: match: OpenSSH_6.7p1 Debian-5+deb8u4 pat OpenSSH* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr [email protected] none
debug1: kex: client->server aes128-ctr [email protected] none
debug1: kex: [email protected] need=20 dh_need=20
debug1: kex: [email protected] need=20 dh_need=20
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: RSA XXX
debug1: read_passphrase: can't open /dev/tty: No such file or directory
Host key verification failed.

Eu uso meu PC com Windows, que se conecta a um servidor remoto com mais de ssh (vamos chamá-lo de servidor 1) com PuTTy. No servidor 1, eu tenho quase zero direitos para executar qualquer coisa além de scp e ssh e comandos básicos do shell. Neste servidor, eu executo uma loja virtual na qual os backups devem parar em outro servidor (vamos chamá-lo de Servidor 2).

Eu gostaria de poder usar sftp , mas não posso usá-lo e não posso instalá-lo no servidor 1. Então, preciso ir com scp . Eu tentei com curl sftp://xxx.xxx que para minha surpresa funcionou, mas ainda me pega um novo erro curl: (51) SSL peer certificcate or SSH remote key was not ok .

    

Answer 1

A mensagem de erro Host key verification failed significa que seu cliente SSH comparou a chave pública recebida do servidor remoto e notou que ela não corresponde à versão armazenada da chave do host no arquivo ~/.ssh/known_hosts .

O comando ssh-keygen -R hostname não faz nada ao host remoto e não requer permissões especiais: tudo o que ele faz é remover a chave do host antigo para hostname de seu local known_hosts Arquivo. Então, na próxima vez que você se conectar a hostname , seu cliente SSH exibirá a impressão digital da chave de host atual de hostname e solicitará que você a aceite. Assim como quando se conecta a algum host pela primeira vez.

Mas se você não tiver esse comando disponível, tente conectar-se com

ssh -o StrictHostKeyChecking=no user@server

O valor padrão para a opção StrictHostKeyChecking é ask , que solicita que você aceite ou rejeite chaves de host desconhecidas anteriormente ... mas, como sua sessão aparentemente não possui pseudo-TTY, o ssh client está em modo não interativo e não solicitará. O valor no deve aceitar automaticamente a chave do host: se possível, ssh gravará a chave do host no arquivo ~/.ssh/known_hosts . Se isso for bem-sucedido, você precisará usar a opção -o StrictHostKeyChecking=no somente ao se conectar a um servidor específico pela primeira vez.