ssh key authentication ainda solicita a senha

Question

Eu obtive a autenticação de chave ssh trabalhando no meu servidor de produção com bastante rapidez. No entanto, tenho lutado para que isso funcione no meu servidor de desenvolvimento.

Primeiro, eu gerava as chaves (eu uso o Ubuntu em casa e no servidor):

$ ssh-keygen -t rsa -f ~/.ssh/production-key.id_rsa

.ssh$ ls -l
total 36
-rw-rw-r-- 1 viggy viggy  234 Dec 22 15:21 config
-rw------- 1 viggy viggy 1766 Dec 22 15:03 development-key.id_rsa
-rw-r--r-- 1 viggy viggy  397 Dec 22 15:03 development-key.id_rsa.pub
-rw------- 1 viggy viggy 1766 Dec 22 13:12 production-key.id_rsa
-rw-r--r-- 1 viggy viggy  397 Dec 22 13:12 production-key.id_rsa.pub
-rw------- 1 viggy viggy 1766 Sep  5 20:36 id_rsa
-rw-r--r-- 1 viggy viggy  403 Sep  5 20:36 id_rsa.pub
-rw-r--r-- 1 viggy viggy 4422 Dec 22 11:45 known_hosts

Eu adicionei a chave privada de desenvolvimento ao meu arquivo de configuração:

vim config
Host production
HostName xx.xxx.xx.xxx
User myuser
IdentityFile ~/.ssh/production-key.id_rsa

Host development
HostName xx.xxx.xx.xxx
User myuser
IdentityFile ~/.ssh/development-key.id_rsa

Então eu copiei a chave pública para o servidor:

cd ~/.ssh
vim authorized_keys // deleted contents of this file and copied my development-key.id_rsa.pub into it and saved file
cat authorized_keys // looked at contents to confirm it matched my development-key.id_rsa.pub

Depois tentei ssh no servidor de desenvolvimento, mas ele solicitou minha senha (em vez de solicitar a frase secreta).

Então, em seguida, comecei a solucionar o motivo pelo qual não funcionou. Eu verifiquei as permissões de arquivo / diretório no servidor:

$ ls -l | grep home
drwxr-xr-x   6 root root  4096 Aug  7  2012 home
$ ls -l | grep myuser
drwxr-xr-x 16 myuser myuser  4096 Dec 22 17:47 myuser
$ ls -la | grep .ssh
drwx------  3 myuser myuser       4096 Dec 22 15:32 .ssh
~/.ssh $ ls -l | grep authorized_keys
-rw------- 1 myuser myuser  396 Dec 22 15:32 authorized_keys

Em seguida, examinei o arquivo sshd_config para confirmar suas configurações. Agora eu ainda não tenho a autenticação de senha desabilitada, mas também não a desabilitei no meu outro servidor e as chaves ssh funcionaram:

$ cd /etc/ssh
$ head -n 1000 sshd_config | grep 'PasswordAuthentication'
#PasswordAuthentication yes

Eu verifiquei se alguma conta não tinha permissão para acessar o ssh (mas não havia nada incomum aqui):

$ head -n 1000 sshd_config | grep 'AllowUsers'
$ head -n 1000 sshd_config | grep 'DenyUsers'

Verifiquei se a autenticação de chave pública estava ativada:

head -n 1000 sshd_config | grep 'PubkeyAuthentication'
PubkeyAuthentication yes
$ head -n 1000 sshd_config | grep 'RSAAuthentication'
RSAAuthentication yes
RhostsRSAAuthentication no

Eu reiniciei o servidor ssh:

sudo restart ssh

Em seguida, verifiquei se meu diretório inicial está criptografado, mas não é:

ls -A /home
.directory   lost+found  quota.group  someuser
myuser  passenger   quota.user

Eu verifiquei que talvez houvesse alguma outra configuração no sistema:

/ $ locate sshd_config
/etc/ssh/sshd_config
/usr/share/doc/openssh-client/examples/sshd_config
/usr/share/man/man5/sshd_config.5.gz

Eu tentei as sugestões aqui:

ssh não permite mais a autenticação de chave pública

Então, finalmente eu tentei o ssh no modo de depuração, e é isso que eu consegui (eu mudei o endereço IP e nomes de usuários):

ssh -vv [email protected]
OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /home/viggy/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to xx.xxx.xx.xxx [xx.xxx.xx.xxx] port 22.
debug1: Connection established.
debug1: identity file /home/viggy/.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/viggy/.ssh/id_rsa-cert type -1
debug1: identity file /home/viggy/.ssh/id_dsa type -1
debug1: identity file /home/viggy/.ssh/id_dsa-cert type -1
debug1: identity file /home/viggy/.ssh/id_ecdsa type -1
debug1: identity file /home/viggy/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
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
debug2: kex_parse_kexinit: [email protected],[email protected],ssh-rsa,[email protected],[email protected],[email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss
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]
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]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
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
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
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]
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]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
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: RSA 42:f0:18:ae:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
debug1: Host 'xx.xxx.xx.xxx' is known and matches the RSA host key.
debug1: Found key in /home/viggy/.ssh/known_hosts:3
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/viggy/.ssh/id_rsa (0xb8bab790)
debug2: key: viggy@teamviggy (0xb8bb1e18)
debug2: key: viggy@teamviggy (0xb8bb1cb8)
debug2: key: /home/viggy/.ssh/id_dsa ((nil))
debug2: key: /home/viggy/.ssh/id_ecdsa ((nil))
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/viggy/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: viggy@teamviggy
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: viggy@teamviggy
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/viggy/.ssh/id_dsa
debug1: Trying private key: /home/viggy/.ssh/id_ecdsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
[email protected]'s password:

ATUALIZAÇÃO: Então eu usei minha chave de produção pública no meu servidor de desenvolvimento e isso funcionou. Então, aparentemente algo no meu arquivo ~ / .ssh / config está incorreto, mas não tenho certeza do que.

    

Answer 1

ssh -vv [email protected]
OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /home/viggy/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *

Aplicar opções para * significa que o cliente ssh acha que o host ao qual você está se conectando não está no arquivo de configuração.

Com base nos seus comentários para a outra resposta, você já moveu todas as configurações específicas do host para a parte superior do arquivo de configuração, antes da seção "Host *", portanto, a análise não pode ser um problema agora.

Mas o cliente ssh ainda não consegue encontrar esse host no arquivo de configuração, o que pode significar que o Host que você escreveu no arquivo de configuração é diferente daquele que você escreveu na linha de comando. quando você invocou ssh. Você tem certeza de que o Host que você escreveu no arquivo de configuração é EXATAMENTE igual ao que você escreve na linha de comando? (Tem que ser exatamente o mesmo, os nomes não são convertidos para um nome de host canonicalizado antes da correspondência .)

    

Answer 2

Eu encontrei esse problema recentemente e acabou sendo um problema com o SELinux em modo de imposição e ~/.ssh e ~/.ssh/authorized_keys arquivos com contextos errados.

Isso veio à tona no SElinux com a seguinte saída audit2allow -a após a tentativa ssh do cliente:

#============= sshd_t ==============
allow sshd_t home_root_t:file { read getattr open };

Depois de executar restorecon -Rv ~/.ssh , redefinir o contexto em ~/.ssh e ~/.ssh/authorized_keys , foram atualizados e ssh'ing do cliente não é mais solicitado por uma senha.

Aqui está a página que me levou a olhar para o SELinux

    

Answer 3

Seu arquivo de configuração é ordenado ao contrário. Na verdade, não tenho certeza se seu cliente está olhando para as outras chaves, mas isso:

Host production
HostName xx.xxx.xx.xxx
User myuser
IdentityFile ~/.ssh/production-key.id_rsa

Host development
HostName xx.xxx.xx.xxx
User myuser
IdentityFile ~/.ssh/development-key.id_rsa

Precisa ser:

Host development
HostName xx.xxx.xx.xxx
User myuser
IdentityFile ~/.ssh/development-key.id_rsa

Host production
HostName xx.xxx.xx.xxx
User myuser
IdentityFile ~/.ssh/production-key.id_rsa

Do arquivo de configuração:

  

Qualquer valor de configuração é alterado apenas na primeira vez que é definido.   Assim, as definições específicas do hospedeiro devem estar no início do   arquivo de configuração e padrões no final.

Mas minha segunda sugestão (se isso falhar também, mesmo se você colocar o ALLLLL no caminho de cima) tente mover todas as outras chaves, exceto as chaves pub / priv de desenvolvimento e known_hosts de ~/.ssh .

O SSH parece estar com o padrão id_rsa e id_rsa.pub , mesmo com suas configurações aqui. Então, eu renomeia o developement-key.id_rsa e o pub correspondente para id_rsa e id_rsa.pub .

    

Answer 4

Eu tive o mesmo problema e resolvi apenas hoje. No meu caso, o motivo pelo qual o ssh ainda pede uma senha é que eu criei uma chave pública com uma senha ... Resolvido gerando uma nova chave pública com uma senha vazia. Às vezes eu só preciso parar de correr por um tempo ...