☰

ssh nunca pede uma senha

tag-icon • tag-icon ssh password
ssh nunca pede uma senha

De alguma forma, meu SSH nunca quer me pedir uma senha.

Então eu configurei um VPS em algum servidor aleatório em algum lugar do mundo e quero me conectar a ele com ssh.

Posso configurar uma chave, mas quando faço isso:

ssh -l some-user IP

Eu recebo o erro:

Received disconnect from ##.##.##.##: 2: Too many authentication failures for some-user

Quando olho os detalhes, vejo que a senha é uma das opções:

debug1: Offering RSA public key: some-user@computer
debug1: Authentications that can continue: publickey,password

Mesmo assim, o SSH nunca me pede a senha. Ele tenta 5 vezes com o que suspeito ser o método publickey e depois falha. Por que o ssh não tentaria com a senha?!

Por precaução, meu arquivo ssh_config tem:

PasswordAuthentication yes

Registro completo

ssh -v -l root ##.##.##.##
OpenSSH_6.1p1 Debian-4, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /home/someuser/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to ##.##.##.## [##.##.##.##] port 22.
debug1: Connection established.
debug1: identity file /home/someuser/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/someuser/.ssh/id_rsa-cert type -1
debug1: identity file /home/someuser/.ssh/id_dsa type -1
debug1: identity file /home/someuser/.ssh/id_dsa-cert type -1
debug1: identity file /home/someuser/.ssh/id_ecdsa type -1
debug1: identity file /home/someuser/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.2p2 Ubuntu-6
debug1: match: OpenSSH_6.2p2 Ubuntu-6 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.1p1 Debian-4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA XX:XX:...:XX:XX
debug1: Host '##.##.##.##' is known and matches the ECDSA host key.
debug1: Found key in /home/someuser/.ssh/known_hosts:38
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/someuser/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: someuser@computer
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: someuser@computer
debug1: Authentications that can continue: publickey,password
debug1: Offering DSA public key: someuser@computer
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: someuser@computer
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: someuser@computer
Received disconnect from ##.##.##.##: 2: Too many authentication failures for root

Responder1

Tente fazer login com a autenticação de chave pública desativada, usando

ssh -o PubkeyAuthentication=no root@newserver

Responder2

Muito provavelmente você tem mais de uma identityfilelinha em seu .ssh/configarquivo.

Mesmo se você tiver uma configuração identityfileinsuficiente host, ela será aplicada globalmente. O que isso significa é que ele sshtenta todos os arquivos de identidade (ou seja, chave pública) em todos os hosts, antes de solicitar a solicitação de senha do servidor.

Você pode consertar isso

  1. Removendo todas as linhas, exceto uma identityfile, ou
  2. Adicionando PubkeyAuthentication noa .ssh/config, ou
  3. Executando ssh com -o PubkeyAuthentication=noparâmetro.

De man 5 ssh_config:

PubkeyAuthentication
    Specifies whether to try public key authentication.  The argument to this
    keyword must be “yes” or “no”.  The default is “yes”.  This option applies 
    to protocol version 2 only.

IdentityFile
    ...
    It is possible to have multiple identity files specified in configuration
    files; all these identities will be tried in sequence.  Multiple 
    IdentityFile directives will add to the list of identities tried (this 
    behaviour differs from that of other configuration directives).

Algumas instruções gerais com chaves públicas:

  1. Em geral, você deve ter apenas uma única chave privada por cliente (estação de trabalho) e colocar a chave pública correspondente em todos os servidores aos quais o cliente deve ter acesso. Em outras palavras, compartilhe a chave pública entre servidores e nunca use a mesma chave privada em vários dispositivos.
  2. Sempre gere um par de chaves no seu dispositivo e transmita apenas a chave pública. Dessa forma, mesmo que o servidor esteja comprometido, sua chave privada ainda estará segura e protegida. Isso pode acontecer de maneiras surpreendentes – por exemplo, por meio de backups.
  3. Se outra pessoa administrar o servidor,vocêdeve fornecer uma chave pública para eles; eles deviamnãogerar par de chaves e enviar chave privada para você. Dessa forma, eles não poderão se passar por você com sua chave (é claro, geralmente eles podem fazer o que quiserem). Além disso, com a chave pública, apenas a integridade (isto é, alguém não alterou a chave pública) deve ser protegida; com a chave privada, a confidencialidade (ou seja, ninguém mais obteve a chave) deve ser conservada e não é possível ter certeza absoluta de que ela não foi comprometida.
  4. Comprometer um servidor não compromete outros servidores, mesmo se você usar a mesma chave privada para conectar-se a vários servidores (exceto se você transmitiu essa chave privada ao servidor. Nunca faça isso).
  5. Comprometer sua estação de trabalho exporá suas chaves privadas de qualquer maneira. Ter várias chaves privadas não ajuda nisso (exceto se você tiver senhas fortes e diferentes e nem todas estiverem disponíveis para o invasor).

Existem algumas exceções a isso, mas não muitas.

Responder3

Seu ssh local não deveria estar pedindo uma senha, o servidor ssh do outro lado deveria. É provável que o servidor esteja configurado para não aceitar autenticação por senha. O meu também não pediria uma senha.

Responder4

Outra causa que encontrei. Eu tive:

Host *
   PreferredAuthentications publickey

in ~/.ssh/config(copiado de outro usuário, pensando que era "preferência"). Na verdade, PreferredAuthenticationsespecifica métodos e ordem "permitidos".

Exclua a PreferredAuthenticationslinha ou adicionepassword

Host *
   PreferredAuthentications publickey,password

Nota: Sem espaço após a vírgula!

informação relacionada