A autenticação da chave SSH falha

Question 1

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

# paste these into an SSH session that server (probably from
# another user account or root)

# change this to YOUR username on the server.
YOURUSER=example

# paste these lines verbatim:
sudo chown $YOURUSER:$YOURUSER /home/$YOURUSER/{.,.ssh/,.ssh/authorized_keys}
sudo chmod u+rwX,go-rwX,-t /home/$YOURUSER/{.ssh/,.ssh/authorized_keys}
sudo chmod go-w /home/$YOURUSER/

(Isso é o queUserificarfaz automaticamente em seu script "shim" para atualizar e corrigir quaisquer problemas de permissão com base em alterações no painel da web da equipe.)

Se o seu administrador criou o diretório .ssh/ ou o arquivo .ssh/authorized_keys como root (que é mais comumente como isso é quebrado), não é permitido ter o arquivo pertencente a outro usuário, MESMO que esse usuário sejaraiz.

Answer

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

# paste these into an SSH session that server (probably from
# another user account or root)

# change this to YOUR username on the server.
YOURUSER=example

# paste these lines verbatim:
sudo chown $YOURUSER:$YOURUSER /home/$YOURUSER/{.,.ssh/,.ssh/authorized_keys}
sudo chmod u+rwX,go-rwX,-t /home/$YOURUSER/{.ssh/,.ssh/authorized_keys}
sudo chmod go-w /home/$YOURUSER/

(Isso é o queUserificarfaz automaticamente em seu script "shim" para atualizar e corrigir quaisquer problemas de permissão com base em alterações no painel da web da equipe.)

Se o seu administrador criou o diretório .ssh/ ou o arquivo .ssh/authorized_keys como root (que é mais comumente como isso é quebrado), não é permitido ter o arquivo pertencente a outro usuário, MESMO que esse usuário sejaraiz.

Question 2

Eu tive exatamente o mesmo problema em dois servidores: um Linux rodando 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 ativado (drwxrwxr--x), então tive que remover pelo menos o write on group (chmod gw ~/) e então funcionou

na Synology, por alguma razão, havia um pouco de pegajoso

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

Answer

Eu tive exatamente o mesmo problema em dois servidores: um Linux rodando 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 ativado (drwxrwxr--x), então tive que remover pelo menos o write on group (chmod gw ~/) e então funcionou

na Synology, por alguma razão, havia um pouco de pegajoso

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

Question 3

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

Habilite o registro para o sshddaemon:sudo vi /etc/ssh/sshd_config
Em registro, remova o comentário:

SyslogFacility AUTH
LogLevel INFO

Mudar LogLevelde INFOparaDEBUG
Salvar e sair
Reinicie o daemon SSH comsudo systemctl restart sshd
Observe o arquivo de mensagenstail -l /var/log/messages
Usando outro terminal, tente conectar-se com ssh
Tente se conectar comssh
Revise o log de autenticação para saber a causa exata

Por exemplo, eu estava enfrentando 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 eram as permissões no authorized_keysarquivo. Ao configurar chmod 644o authorized_keysarquivo do meu usuário, o problema foi resolvido.

Answer

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

Habilite o registro para o sshddaemon:sudo vi /etc/ssh/sshd_config
Em registro, remova o comentário:

SyslogFacility AUTH
LogLevel INFO

Mudar LogLevelde INFOparaDEBUG
Salvar e sair
Reinicie o daemon SSH comsudo systemctl restart sshd
Observe o arquivo de mensagenstail -l /var/log/messages
Usando outro terminal, tente conectar-se com ssh
Tente se conectar comssh
Revise o log de autenticação para saber a causa exata

Por exemplo, eu estava enfrentando 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 eram as permissões no authorized_keysarquivo. Ao configurar chmod 644o authorized_keysarquivo do meu usuário, o problema foi resolvido.

Question 4

eu tenho tidoum problema semelhante, onde 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, foi devido a um antigo arquivo de chave pública 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 id_rsa.pubdo .sshdiretório resolveu o problema.

Pelo que entendi: quando há uma chave pública presente no lado do cliente, o SSH primeiro 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 do openssh:https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-April/035048.html.

Answer

eu tenho tidoum problema semelhante, onde 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, foi devido a um antigo arquivo de chave pública 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 id_rsa.pubdo .sshdiretório resolveu o problema.

Pelo que entendi: quando há uma chave pública presente no lado do cliente, o SSH primeiro 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 do openssh:https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-April/035048.html.

A autenticação da chave SSH falha

Responder1

Responder2

Responder3

Responder4

informação relacionada