A autenticação da chave SSH falha

Estou tentando fazer o ssh em um servidor CentOS sobre o qual não tenho controle .. o administrador adicionou minha chave pública ao servidor e insiste que a falha está comigo, mas não consigo descobrir o que está errado.

Configure em .ssh:

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

Permissão nos 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 que não consigo entender:

tim@tim-UX31A:~$ ssh -vvv root@10.0.12.28
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: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,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: curve25519-sha256@libssh.org,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: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256@libssh.org,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,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: MACs ctos: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: MACs stoc: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com 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).

Isso geralmente resolve a maioria dos problemas de permissão de chave autorizada por 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 arquivo .ssh / directory ou .ssh / allowed_keys como root (o que é mais comum como isso é realizado), não é permitido ter o arquivo de propriedade de outro usuário (mesmo que o root!).

O Userify (aviso de isenção de responsabilidade: co-fundador) faz isso exatamente da mesma maneira automaticamente. Https://github.com/userify/shim/blob/master/shim.py#L285

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

descobriu-se que, nos dois 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 de gravação / grupo ativado (drwxrwxr - x), então eu tive que remover pelo menos a gravação no grupo (chmod gw ~ /) e funcionou

na Synology, por qualquer motivo, houve um pouco de dificuldade

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 conectar sem uma senha

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

1. Habilite o log para sshd: vi /etc/ssh/sshd_config
2. Sob o registro, descomente:

SyslogFacility AUTH LogLevel INFO

1. Altere o LogLevel INFO para LogLevel DEBUG
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 conectar-se ao ssh
6. Tentativa de se conectar com ssh
7. Revise o log de autenticação para obter a causa exata

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

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

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

Parece que as permissões na sua .sshpasta não foram copiadas e coladas corretamente. Você poderia adicioná-lo novamente?

Se o modo estrito estiver ativado, precisamos garantir que .sshas permissões corretas sejam:

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

Como as coisas o procuram em termos de permissão?

Apenas no caso de alguém tropeçar nessa resposta - nenhuma das recomendações funcionou no meu cenário. No final, o problema foi que eu criei uma conta sem senha definida. Depois de definir a senha usermod -p "my password" usernamee desbloquear à força a conta, usermod -U usernametudo ficava meio pêssego.

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

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

No meu caso, isso ocorreu devido a um antigo arquivo de chave pública localizado no .sshdiretório:

[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 a id_rsa.pubpartir do .sshdiretório resolveu o problema.

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

Enviei um email para a lista de discussão openssh: https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-April/035048.html .

Encontramos este problema. Permissões e propriedade dos arquivos .ssh estavam 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

Portanto, a solução para o desenvolvedor vm em que não nos preocupamos com segurança é desativar o selinux. Edite / etc / sysconfig / selinux e altere SELINUX = desativado e reinicie.

Também encontrou esse problema. O setroubleshoot não parecia funcionar no meu ambiente, portanto não havia esse registro de log em / var / log / messages. Desabilitar o SELinux não era uma opção para mim, então eu fiz

restorecon -Rv ~/.ssh

Após esse login pela rsa key funcionou bem.

Caso isso também salve alguém. Eu estava tentando copiar uma chave da minha máquina Ubuntu 18.04 para 2 servidores CentOS 7. Eu costumava ssh-copy-idtransferi-los. Um funcionou, um 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_confignos dois servidores e passei linha por linha através deles. 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_keysque estava no servidor que não estava aceitando minhas chaves. Obviamente, olhando entre os dois arquivos e observando o comentário que declara os padrões de pesquisa padrão não incluem o principal, ~/eu o removi e reiniciei o sshd. Problema resolvido.

Um log de erros do lado do cliente que termina 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
root@x.x.x.x's password:

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

PermitRootLogin: no

A sugestão de JonCav para habilitar o log foi útil na depuração desse problema. Embora o spew de depuração do lado do cliente tenha sido extraordinariamente inútil, coloque o seguinte no arquivo sshd_config do servidor sshd :

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 apenas o login root falha, e desde que a autenticação de chave seja permitida pela política de segurança, uma alteração no arquivo sshd_config pode ajudar:

 PermitRootLogin without-password

Sua milhagem pode variar, embora isso geralmente ajude, alguma outra configuração ainda pode 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 consiga alterar facilmente a configuração do servidor remoto para depuração dessa maneira, pode-se comprovar a configuração do lado do cliente até certo ponto, usando os mesmos arquivos de identidade para ssh em uma conta não raiz no mesmo servidor remoto.

O motivo, no meu caso, foi uma opção configurada de maneira personalizada AuthorizedKeysFileno arquivo /etc/ssh/sshd_config. Como foi definido como dir (home /home/webmaster/.ssh/authorized_keys) de outro usuário , o usuário que eu estava tentando acessar 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. Agora posso fazer login com minha chave privada.

Percebo por que a segurança pode incomodar as pessoas. Eu só tive o ssh won't use my keyproblema novamente. Eu o resolvi entrando no servidor remoto e executando

/usr/sbin/sshd -sDp 23456

e depois da minha área de trabalho (tentando ssh no servidor)

ssh -vvvv server -p 23456

No servidor eu consegui Authentication refused: bad ownership or modes for directory /

Alguns novos administradores de sistemas haviam atrapalhado a permissão e a propriedade, com as quais eu consertei:

chmod 0755 / ; chown root:root /

(Estou acostumado a precisar chmod 0600 ~/.ssh/* ; chmod 0644 ~/.ssh/*.pub mas a verificação / localização de permissões de root pelo sshd é nova para mim.) Agora vou procurar um rootkit e, em seguida, limpe e reinstale de qualquer maneira.

No meu caso, os problemas estavam com o shell exec incorreto.

journalctl -f
....
Feb 25 11:45:54 59a02b89e0f6 sshd[]: User user not allowed because shell /usr/bin/env /bin/bash does not exist
....

Arquivo / etc / passwd alterado para esse usuário

vi /etc/passwd 
....
user:x:1000:1000::/home/user:/bin/bash
....

Eu tive esse problema no CentOS 7. Eu sou um usuário comum do Linux baseado no Debian, então eu era um peixe fora d'água. Percebi que em alguns servidores funcionou e em apenas um não. O audit.log não disse nada de útil e o secure.log também não deu nada. Eu descobri que a única diferença real eram algumas diferenças de contexto de segurança em arquivos e diretórios entre aqueles que funcionavam e os que não funcionavam. Obtenha segurança com

sudo ls -laZ <user-home>/.ssh

do diretório (estou assumindo muitos padrões no sshd_config).

Você deve ver alguns ssh_home_te user_home_tatributos. Caso contrário, use o chconcomando para adicionar os atributos ausentes.

Por exemplo

home="$(getent passwd <user> | cut -d: -f6)"
sudo chcon -R unconfined_u:object_r:ssh_home_t:s0 "$home".ssh
sudo chcon unconfined_u:object_r:user_home_t:s0 "$home"

No meu caso, minha suspeita é que o usuário tenha sido criado de maneira não padrão. Sua casa era um diretório em /var/lib.

Mais informações em: https://www.linuxquestions.org/questions/linux-security-4/selinux-preventing-ssh-login-with-~-ssh-authorized_keys-4175469538/

No nosso caso, os problemas estavam relacionados ao fato de que nossas regras de firewall e NATing não foram configuradas corretamente.

porta 22, estava sendo direcionada para o servidor incorreto onde nossas chaves e usuário não estavam sendo reconhecidos.

Se alguém chegar a esse ponto. tcpdump e telnet podem ser seus amigos

[aaron@aaron-pc ~]$ telnet someserver 22
Trying 1.1.1.1...
Connected to someserver.
Escape character is '^]'.
SSH-2.0-OpenSSH_6.7p1
^]
telnet> 

[aaron@aaron-pc ~]$ telnet someotherserver 22
Trying 1.1.1.2...
Connected to someotherserver.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
^]

Você notará que esses dois servidores possuem versões openssh diferentes. Isso me ajudou a identificar o problema rapidamente. Se seus hosts estiverem usando as mesmas versões ssh, você deverá tentar fazer um rastreamento compactado no destino para verificar se o tráfego está chegando ao destino.

O ssh pode gerar muito tráfego, o que dificulta o tcpdump out para encontrar o que você está procurando.

Isso me ajudou

 tcpdump -i any  "not host [mylocalip] and not localhost and not ip and not arp"

Tente telnetar a partir de um servidor 3 diferente do seu computador atual @ [mylocalip]. Você deseja ver qual tráfego realmente chega ao seu servidor.