O SSH continua pulando meu pubkey e pedindo uma senha

52

Toda vez que ssh no meu servidor remoto, preciso fornecer a senha. Copiei minha chave pública (id_dsa.pub) no servidor remoto usando:

ssh-copy-id -i id_dsa.pub user@server

Eu verifiquei se ele foi adicionado corretamente às allowed_keys. Todas as permissões de arquivo / diretório estão corretas:

~user 755
~user/.ssh 700
~user/.ssh/authorized_keys 640
~user/.ssh/id_dsa.pub 644

O campo PasswordAuthentication em / etc / ssh / sshd_config está definido como yes. Coloquei o sshd no modo de depuração e adicionei a opção detalhada ao comando ssh. Tenho a impressão de que o servidor não tentou usar id_pub.dsa por causa da linha

Skipping ssh-dss key: ........... not in PubkeyAcceptedKeyTypes

Não há disco criptografado no lado do servidor. Alguma idéia de como progredir? Aqui estão as informações de depuração do daemon ssh:

sudo /usr/sbin/sshd -d
====
debug1: sshd version OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type ECDSA
debug1: private host key: #2 type 3 ECDSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
Set /proc/self/oom_score_adj from 0 to -1000
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from xxx port 63521 on yyy port 22
debug1: Client protocol version 2.0; client software version OpenSSH_7.1
debug1: match: OpenSSH_7.1 pat OpenSSH* compat 0x04000000
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3
debug1: permanently_set_uid: 115/65534 [preauth]
debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: client->server [email protected] <implicit> none [preauth]
debug1: kex: server->client [email protected] <implicit> none [preauth]
debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user damian service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: PAM: initializing for "damian"
debug1: PAM: setting PAM_RHOST to "freebox-server.local"
debug1: PAM: setting PAM_TTY to "ssh"
Connection closed by xxxx [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed
debug1: do_cleanup

Aqui está a saída detalhada do ssh:

$ ssh -v user@server
OpenSSH_7.1p1, OpenSSL 1.0.2d 9 Jul 2015
debug1: Connecting to server [xxxx] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: identity file /home/user/.ssh/id_dsa type 2
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3 pat OpenSSH_6.6.1* compat 0x04000000
debug1: Authenticating to server:22 as 'user'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client [email protected] <implicit> none
debug1: kex: client->server [email protected] <implicit> none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:v4BNHM0Q33Uh6U4VHenA9iJ0wEyi8h0rFVetbcXBKqA
debug1: Host 'server' is known and matches the ECDSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:2
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: Trying private key: /home/user/.ssh/id_rsa
debug1: Skipping ssh-dss key /home/user/.ssh/id_dsa for not in PubkeyAcceptedKeyTypes
debug1: Trying private key: /home/user/.ssh/id_ecdsa
debug1: Trying private key: /home/user/.ssh/id_ed25519
debug1: Next authentication method: password
user@server's password:
Damo
fonte
11
Consulte também superuser.com/q/1016989/93541 para o mesmo problema (e essencialmente a mesma solução).
DW
Observe que se o sshd_config no destino tiver PubkeyAuthentication no , você sempre será solicitado a fornecer uma senha. Defina como yes e reinicie o sshd (no host de destino) para ativar a autenticação pubkey.
C. Kelly

Respostas:

84

A nova versão do openssh (7.0+) descontinuou as chaves DSA e não está usando as chaves DSA por padrão (não no servidor ou no cliente). As chaves não são mais preferíveis para serem usadas, portanto, se você puder, recomendo usar as chaves RSA sempre que possível.

Se você realmente precisar usar chaves DSA, precisará explicitamente permiti-las na configuração do cliente usando

PubkeyAcceptedKeyTypes +ssh-dss

Deve ser o suficiente para inserir essa linha ~/.ssh/config, como a mensagem detalhada está tentando lhe dizer.

Jakuje
fonte
5
+1, mas melhor conselho seria para usar outro, tipo de chave não-obsoleto ...
jasonwryan
@jasonwryan Obrigado por comentar. Certamente. Eu atualizarei a resposta.
Jakuje 5/12/2015
Obrigado Jakuje! Isso faz sentido, eu não sabia que o dsa era velho. Eu gerei um novo par de chaves ssh-keygenrsa agora é o padrão. Vou tentar fazer o login com isso na outra máquina amanhã.
Damo
Se você ~/.ssh/confignão existe, basta criá-lo. E lembre-se de definir as permissões corect: chmod 600 ~/.ssh/config.
Florian Brucker
@knb não faça isso. Isso evitará o uso de outros algoritmos no futuro, pois você removeu todos os algoritmos da curva elíptica.
Jakuje 3/17/17
2

No meu caso, eu estava tendo esse problema porque outro usuário havia alterado o AuthorizedKeysFilelocal. Como não havia authorized_keysoutros usuários nesse local, o login teria como padrão a senha, mesmo que authorized_keysexistisse com as permissões corretas no diretório inicial padrão.

AuthorizedKeysFile   /etc/ssh/%u/authorized_keys

Comentou esta linha modificada e reiniciou o serviço sshd para voltar à configuração padrão, que permitiu que outros usuários se autentiquem usando suas chaves.

GotGame
fonte
Acabei de resolver um problema semelhante em um sistema RHEL7, em que o contexto do SELinux não foi inicializado corretamente no homedir do usuário; portanto, o ssh não conseguiu ler o arquivo de chaves autorizadas, apesar das permissões padrão. Acabei rodando restorecon -Rv /homepara corrigi-lo para os outros usuários que também foram configurados incorretamente no mesmo sistema.
precisa saber é o seguinte
1

Tentei a resposta de Jakuje Sem sorte. Mas eu entendo o problema a partir daí. Tentei adicionar um comentário, mas preciso de reputação por que adicionar uma resposta.

Mas o arquivo de configuração para mim / etc / ssh / ssh_config

  1. sudo nano /etc/ssh/ssh_config
  2. PubkeyAcceptedKeyTypes +ssh-dss Adicionado esta linha na parte inferior.
  3. Salve e tente novamente.

Trabalhou!

SWAPNIL DEWALKAR
fonte
1

Apenas para resumir o que fiz para fazer o SSH no Raspberry Pi .

Na máquina do servidor (raspberry Pi):

$ ip addr show 

ou simplesmente ip a, isso exibirá o endereço IP da máquina Pi - host_ip

$ mkdir .ssh

Na máquina cliente (ubuntu):

$ ssh-keygen -t rsa  

Crédito para @Jakuje acima. Inicialmente, eu estava usando o ssh-keygen -t dsa para a geração de chaves, e o ssh ficava me pedindo senha. O endereço IP ssh -v não me fornece muitas informações úteis, até que eu vi a resposta de @ Jakuje

$ cat .ssh/id_rsa.pub | ssh user_id@host_ip 'cat >> ~/.ssh/authorized_keys'  

substitua user_id e host_ip, quando solicitado, forneça a senha para a máquina Pi

$ ssh user@ip_address

logado com êxito no PI, não há mais senha

VictorL
fonte
0

dsa não funcionou para mim. rsa fez.

ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa
cat /Users/user_name/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys

E eu posso ssh sem senha.

rodya
fonte