A autenticação de chave SSH falha

Question

Estou tentando usar o ssh em um servidor do CentOS sobre o qual não tenho controle .. o administrador adicionou minha chave pública ao servidor e insiste que a culpa é minha, mas não consigo entender o que está errado.

Config em .ssh:

tim@tim-UX31A:~$ cat ~/.ssh/config
User root
PasswordAuthentication no
IdentityFile ~/.ssh/id_rsa

Permissão em meus arquivos-chave:

tim@tim-UX31A:~$ ls -l ~/.ssh/id_rsa*
-rw------- 1 tim tim 3326 Okt 20 17:28 /home/tim/.ssh/id_rsa
-rw-r--r-- 1 tim tim  746 Okt 20 17:28 /home/tim/.ssh/id_rsa.pub

Log de conexão do qual não consigo entender:

tim@tim-UX31A:~$ ssh -vvv [email protected]
OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /home/tim/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "10.0.12.28" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 10.0.12.28 [10.0.12.28] port 22.
debug1: Connection established.
debug1: identity file /home/tim/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/tim/.ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 10.0.12.28:22 as 'root'
debug3: hostkeys_foreach: reading file "/home/tim/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/tim/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from 10.0.12.28
debug3: order_hostkeyalgs: prefer hostkeyalgs: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected],zlib
debug2: compression stoc: none,[email protected],zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: [email protected],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: host key algorithms: ssh-rsa,ecdsa-sha2-nistp256
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: compression ctos: none,[email protected]
debug2: compression stoc: none,[email protected]
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: 
debug3: hostkeys_foreach: reading file "/home/tim/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/tim/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from 10.0.12.28
debug1: Host '10.0.12.28' is known and matches the ECDSA host key.
debug1: Found key in /home/tim/.ssh/known_hosts:3
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /home/tim/.ssh/id_rsa (0x55ee619ab2b0), explicit, agent
debug2: key: /home/tim/.ssh/id_rsa (0x55ee619bcfa0), agent
debug2: key: tim@Tim-UX31A-Debian (0x55ee619b9370), agent
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive
debug3: authmethod_is_enabled gssapi-keyex
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: tim@Tim-UX31A-Debian
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

    

Answer 1

Isso geralmente resolverá a maioria dos problemas de permissão de chave autorizados do SSH no lado do servidor , supondo que alguém não tenha feito alterações adicionais nas permissões.

sudo chown yourusername:yourusername /home/yourusername/ -R
sudo chmod o-rwx /home/yourusername/ -R

Se o seu administrador criou o diretório .ssh / ou o arquivo .ssh / authorized_keys como root (que é mais comumente como isso é feito), então o arquivo de propriedade de outro usuário (mesmo que root!) não é permitido.

Userify (disclaimer: co-fundador) faz isso da mesma maneira. link

    

Answer 2

Eu tive exatamente o mesmo problema em dois servidores: um Linux executando Debian stretch e em um NAS (Synology DS715)

descobriu-se que, em ambos os casos, as permissões do diretório inicial no servidor estavam erradas

o auth.log no servidor foi muito útil

Authentication refused: bad ownership or modes for directory /home/cyril

no Linux, ele tinha o bit write / group em (drwxrwxr - x), então eu tive que remover pelo menos o grupo write (chmod g-w ~ /) e então ele funcionou

na Synology, por qualquer motivo, havia um pedaço grudento

drwx--x--x+ 4 toto users 4096 Jan 6 12:11 /var/services/homes/toto

Eu tive que mudar isso com

chmod -t ~/

e eu poderia então conectar sem uma senha

    

Answer 3

Parece que as permissões na sua pasta .ssh não copiaram e colaram corretamente. Você poderia por favor adicioná-lo novamente?

Se o modo restrito estiver ativado, temos que garantir que .ssh tenha as permissões corretas de:

• .ssh/ deve ter perms 0700/rwx------
• .ssh/*.pub arquivos devem ser 644/rw-r--r--
• .ssh/* (outros arquivos em .ssh) 0600/rw-------

Como as coisas parecem para você com permissão?

    

Answer 4

Apenas no caso de alguém se deparar com essa resposta - nenhuma das recomendações funcionou no meu cenário. No final, o problema foi que eu tinha criado uma conta sem senha definida. Depois que eu definir a senha usando usermod -p "my password" username e, em seguida, forçosamente desbloqueado a conta usermod -U username tudo foi peachy.

    

Answer 5

Ao usar o CentOS 7, e estou confiante, aplica-se a outros sistemas operacionais Linux usando o sshd também. Com o acesso root, você pode determinar mais sobre por que a autenticação pode estar falhando. Para fazer isso:

1. Ativar o registro em log para sshd: vi /etc/ssh/sshd_config
2. Em log de comentário:

SyslogFacility AUTH LogLevel INFO

1. Altere INFO LogLevel para DEBUG LogLevel
2. Salvar e sair
3. Reinicie o sshd systemctl restart sshd
4. Assista ao arquivo de mensagens tail -l /var/log/messages
5. Usando outro terminal, tente se conectar com o ssh
6. Tentativa de se conectar com ssh
7. Revise o log de autenticação para a causa exata

Por exemplo, eu estava passando por alguns dos mesmos problemas mencionados acima.

Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys

Usando essas etapas, consegui confirmar que o problema era permissões no arquivo authorized_keys. Ao definir chmod para 644 no arquivo de chaves autorizadas do meu usuário, o problema foi corrigido.

    

Answer 6

Encontramos este problema. Permissões e propriedade em arquivos .ssh estavam todas corretas. Em / var / log / messages, encontramos:

Mar 29 15:45:36 centos70 setroubleshoot: SELinux is preventing /usr/sbin/sshd from read access on the file authorized_keys. For complete SELinux messages run: sealert -l 05963b94-f318-4615-806c-b6c3a9066c82

SO, solução para desenvolvedor vm onde não nos importamos com segurança é desativar o selinux. Edite / etc / sysconfig / selinux e altere SELINUX = desabilitado e reinicialize.

    

Answer 7

Apenas no caso de isso também salvar alguém. Eu estava tentando copiar uma chave do meu Ubuntu 18.04 Machine para 2 CentOS 7 Servers. Eu usei ssh-copy-id para transferi-los. Um funcionou, outro não. Então eu passei por todas as permissões de depuração e não encontrei nada. Então, finalmente, puxei o arquivo /etc/ssh/sshd_config nos dois servidores e percorri linha por linha. Finalmente eu encontrei, provavelmente algo que alguém modificou muito antes de eu entrar no trabalho.

Uma leitura: AuthorizedKeysFile .ssh/authorized_keys

E outra leitura: AuthorizedKeysFile ~/.ssh/authorized_keys , que estava no servidor que não estava aceitando minhas chaves. Obviamente, olhando entre os dois arquivos e observando o comentário que afirma que os padrões de pesquisa padrão não incluem o principal ~/ eu removi e reiniciei sshd. Problema resolvido.

    

Answer 8

Eu tive um problema semelhante , onde a conexão ssh tenta a chave ~/.ssh/id_rsa antes de parar inesperadamente em:

debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

No meu caso, foi devido a um arquivo de chave pública antigo no diretório .ssh :

[gitlab-runner@validation-k8s-1 ~]$ ll .ssh/id_rsa*
total 16
-rw------- 1 gitlab-runner gitlab-runner 1675 Sep 18 18:02 id_rsa      --> new private key
-rw-r--r--. 1 gitlab-runner gitlab-runner  423 Jun 12 13:51 id_rsa.pub --> old public key

Mover / excluir o id_rsa.pub do diretório .ssh solucionou o problema.

Pelo que entendi: quando há uma chave pública presente no lado do cliente, o SSH 1 valida a chave privada contra ela. Se falhar, não tentará usar a chave privada para se conectar remotamente.

Enviei um e-mail para a lista de discussão openssh: link .

    

Answer 9

Também encontrou este problema. setroubleshoot parece não funcionar em meu ambiente, então não havia tal registro de log em / var / log / messages. Desativar o SELinux não era uma opção para mim, então eu fiz

restorecon -Rv ~/.ssh

Depois disso, o login pela chave rsa funcionou bem.

    

Answer 10

Um log de erro do lado do cliente terminando assim:

Enter passphrase for key '/root/.ssh/id_rsa':
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
[email protected]'s password:

pode ser causado por uma restrição do lado do servidor (remota) no login root quando o arquivo de configuração sshd contém:

PermitRootLogin: no

A sugestão de JonCav de ativar o registro foi útil para depurar esse problema. Embora o spew do lado do cliente tenha sido notavelmente inútil, colocando o seguinte no arquivo sshd do servidor sshd_config :

SyslogFacility AUTH
LogLevel DEBUG

acabou produzindo mensagens de log úteis:

Jul 19 19:16:38 500265-web1 sshd[21188]: Found matching RSA key: ...
Jul 19 19:16:38 500265-web1 sshd[21188]: ROOT LOGIN REFUSED FROM ...
Jul 19 19:16:38 500265-web1 sshd[21188]: Failed publickey for root from ... port ... ssh2
Jul 19 19:16:38 500265-web1 sshd[21189]: ROOT LOGIN REFUSED FROM ...

No caso em que somente o login root falha, e desde que seja permitida a utilização somente da autenticação baseada em chave para login root, sua alteração será feita no sshd_config arquivo pode ajudar:

 PermitRootLogin without-password

Sua milhagem pode variar, embora isso geralmente ajude, outras configurações ainda podem interferir de acordo com um comentário encontrado em alguns arquivos sshd_config :

# Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".

Mesmo que você não possa alterar facilmente a configuração do servidor remoto para depurar dessa maneira, pode-se testar a configuração do lado do cliente até certo ponto, usando os mesmos arquivos de identidade para ssh para um diretório não raiz. conta no mesmo servidor remoto.

    

Answer 11

O motivo no meu caso foi uma opção definida de forma personalizada AuthorizedKeysFile no arquivo /etc/ssh/sshd_config . Ele foi configurado para o diretório inicial de outro usuário ( /home/webmaster/.ssh/authorized_keys ), portanto, o usuário que eu estava tentando efetuar login não tinha acesso a esse arquivo / diretório.

Depois de alterá-lo e reiniciar o ssh-server ( service ssh restart ), tudo voltou ao normal. Eu posso logar pela minha chave privada agora.

    

Answer 12

Eu posso ver porque a segurança pode incomodar as pessoas. Acabei de ter o problema ssh won't use my key novamente. Eu resolvi isso fazendo login no servidor remoto e executando

/usr/sbin/sshd -sDp 23456

e depois da minha área de trabalho, (tentando ssh para o servidor)

ssh -vvvv server -p 23456

No servidor, recebi Authentication refused: bad ownership or modes for directory /

Alguns novos sysadmin tinham atrapalhado a permissão e a propriedade, que eu corrigi:

chmod 0755 / ; chown root:root /

(Estou acostumado a precisar de chmod 0600 ~/.ssh/* ; chmod 0644 ~/.ssh/*.pub , mas o sshd verificando / encontrando as permissões de root é novo para mim.) Agora, vou verificar um rootkit e depois limpar e reinstalar de qualquer maneira.