La autenticación de clave SSH falla

Estoy tratando de ingresar a un servidor CentOS sobre el cual no tengo control ... el administrador ha agregado mi clave pública al servidor e insiste en que la falla es mía, pero no puedo entender qué está mal.

Configuración en .ssh:

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

Permiso en mis archivos clave:

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

Registro de conexión que no puedo 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).

Esto generalmente resolverá la mayoría de los problemas de permisos de clave autorizados por SSH en el lado del servidor , suponiendo que alguien no haya realizado cambios adicionales en los permisos.

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

Si su administrador creó el directorio .ssh / o el archivo .ssh / Authorized_keys como root (que es la forma más común de lograrlo), entonces no está permitido que el archivo sea propiedad de otro usuario (¡incluso si es root!).

Userify (descargo de responsabilidad: cofundador) hace esto exactamente de la misma manera .. https://github.com/userify/shim/blob/master/shim.py#L285

Tuve exactamente el mismo problema en dos servidores: un Linux con Debian Stretch y un NAS (Synology DS715)

Resultó que en ambos casos, los permisos del directorio de inicio en el servidor eran incorrectos

el auth.log en el servidor fue muy útil

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

en Linux, tenía el bit de escritura / grupo activado (drwxrwxr - x), así que tuve que eliminar al menos el grupo de escritura (chmod gw ~ /) y luego funcionó

en Synology, por alguna razón, había un poco pegajoso

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

Tuve que cambiarlo con

chmod -t ~/

y luego podría conectarme sin contraseña

Cuando uso CentOS 7, y estoy seguro, también se aplica a otros sistemas operativos Linux que usan sshd. Con el acceso raíz, puede determinar más acerca de por qué la autenticación puede estar fallando. Para hacer esto:

1. Habilite el registro para sshd: vi /etc/ssh/sshd_config
2. Bajo el registro de comentario:

SyslogFacility AUTH LogLevel INFO

1. Cambiar LogLevel INFO a LogLevel DEBUG
2. Guardar y Salir
3. Reiniciar sshd systemctl restart sshd
4. Mira el archivo de mensajes tail -l /var/log/messages
5. Usando otro terminal, intente conectarse con ssh
6. Intenta conectarte con ssh
7. Revise el registro de autenticación para conocer la causa exacta

Por ejemplo, estaba experimentando algunos de los mismos problemas mencionados anteriormente.

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

Utilizando estos pasos pude confirmar que el problema eran los permisos en el archivo autorizado_claves. Al configurar chmod en 644 en el archivo de claves autorizado de mi usuario, se solucionó el problema.

Parece que los permisos en su .sshcarpeta no copiaron + pegaron correctamente. ¿Podría agregarlo nuevamente?

Si el modo estricto está habilitado, entonces debemos asegurarnos de que .sshtenga los permisos correctos de:

• .ssh/ debería tener permisos 0700/rwx------
• .ssh/*.pub los archivos deben ser 644/rw-r--r--
• .ssh/* (otros archivos en .ssh) 0600/rw-------

¿Cómo te parecen las cosas con permiso?

En caso de que alguien tropiece con esta respuesta, ninguna de las recomendaciones funcionó en mi escenario. Al final, el problema fue que había creado una cuenta sin contraseña establecida. Una vez que configuré la contraseña usando usermod -p "my password" usernamey luego desbloqueé a la fuerza la cuenta, usermod -U usernametodo era color de rosa.

He tenido un problema similar , donde la conexión ssh prueba la clave ~/.ssh/id_rsaantes de detenerse inesperadamente:

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

En mi caso, se debió a un viejo archivo de clave pública en el .sshdirectorio:

[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 / eliminar id_rsa.pubdel .sshdirectorio resolvió el problema.

Por lo que entiendo: cuando hay una clave pública presente en el lado del cliente, SSH 1st valida la clave privada en su contra. Si falla, no intentará usar la clave privada para conectarse de forma remota.

Envié un correo electrónico a la lista de correo de openssh: https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-April/035048.html .

Nos encontramos con este problema. Los permisos y la propiedad de los archivos .ssh fueron correctos. En / 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

Entonces, la solución para el desarrollador vm donde no nos importa la seguridad es deshabilitar selinux. Edite / etc / sysconfig / selinux y cambie SELINUX = disabled y reinicie.

Por si acaso esto también salva a alguien. Intenté copiar una clave de mi máquina Ubuntu 18.04 a 2 servidores CentOS 7. Solía ssh-copy-idtransferirlos. Uno funcionó, el otro no. Así que revisé todos los permisos de depuración y no encontré nada. Así que finalmente levanté el archivo /etc/ssh/sshd_configen ambos servidores y pasé línea por línea a través de ellos. Finalmente lo encontré, probablemente algo que alguien modificó mucho antes de que me pusiera a trabajar.

Uno lee: AuthorizedKeysFile .ssh/authorized_keys

Y otra lectura: AuthorizedKeysFile ~/.ssh/authorized_keysque estaba en el servidor que no aceptaba mis claves. Obviamente, mirando entre los dos archivos y observando el comentario que indica que los patrones de búsqueda predeterminados no incluyen el inicio, ~/lo eliminé y reinicié sshd. Problema resuelto.

También encontré este problema. setroubleshoot no parecía funcionar en mi entorno, por lo que no había tal registro en / var / log / messages. Deshabilitar SELinux no era una opción para mí, así que lo hice

restorecon -Rv ~/.ssh

Después de ese inicio de sesión con la clave rsa funcionó bien.

La razón en mi caso fue una opción personalizada AuthorizedKeysFileen el archivo /etc/ssh/sshd_config. Se configuró en el directorio de inicio de otro usuario ( /home/webmaster/.ssh/authorized_keys), por lo que el usuario que estaba intentando iniciar sesión no tenía acceso a ese archivo / directorio.

Después de cambiarlo y reiniciar ssh-server ( service ssh restart) todo volvió a la normalidad. Puedo iniciar sesión con mi clave privada ahora.

En nuestro caso, los problemas estaban relacionados con el hecho de que nuestro firewall y las reglas de NAT no estaban configuradas correctamente.

el puerto 22 se dirigía al servidor incorrecto donde no se reconocían nuestras claves y nuestro usuario.

Si alguien llega a este punto. tcpdump y telnet pueden ser tus 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
^]

Notará que estos dos servidores tienen diferentes versiones de openssh. Esto me ayudó a detectar el problema bastante rápido. Si sus hosts están utilizando las mismas versiones ssh, tendrá que intentar hacer un seguimiento empaquetado en el destino para ver si el tráfico está llegando al destino.

Ssh puede generar mucho tráfico, lo que hace que sea difícil encontrar lo que está buscando.

Esto me ayudo

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

Intente hacer telnet desde un servidor diferente 3 no su computadora actual @ [mylocalip]. Desea ver qué tráfico llega realmente a su servidor.

Un registro de errores del lado del cliente que termina así:

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:

puede deberse a una restricción del lado del servidor (remota) en el inicio de sesión raíz cuando el archivo de configuración sshd contiene:

PermitRootLogin: no

La sugerencia de JonCav de habilitar el registro fue útil para depurar este problema. Si bien la depuración del lado del cliente fue notablemente inútil, colocar lo siguiente en sshd_config del servidor sshd archivo :

SyslogFacility AUTH
LogLevel DEBUG

terminó produciendo mensajes de registro útiles:

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 ...

En el caso de que solo falle el inicio de sesión raíz , y siempre que su política de seguridad permita el uso de solo autenticación basada en claves para el inicio de sesión raíz, un cambio en el archivo sshd_config puede ayudar:

 PermitRootLogin without-password

Su kilometraje puede variar, aunque esto a menudo ayuda, alguna otra configuración aún puede interferir de acuerdo con un comentario encontrado en algunos archivos sshd_config :

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

Incluso si no puede cambiar fácilmente la configuración del servidor remoto para depurar de esta manera, se puede probar la configuración del lado del cliente hasta cierto punto utilizando los mismos archivos de identidad para ssh a una cuenta no root en el mismo servidor remoto.

Puedo ver por qué la seguridad puede molestar a las personas. Acabo de tener el ssh won't use my keyproblema nuevamente. Lo resolví iniciando sesión en el servidor remoto y ejecutando

/usr/sbin/sshd -sDp 23456

y luego desde mi escritorio, (intentando ssh al servidor)

ssh -vvvv server -p 23456

En el servidor tengo Authentication refused: bad ownership or modes for directory /

Algunos nuevos administradores de sistemas habían estropeado el permiso y la propiedad, que solucioné con:

chmod 0755 / ; chown root:root /

(Estoy acostumbrado a necesitar, chmod 0600 ~/.ssh/* ; chmod 0644 ~/.ssh/*.pubpero la comprobación / búsqueda de sshd para encontrar los permisos de root es nueva para mí). Ahora voy a buscar un rootkit y luego lo borraré y volveré a instalar de todos modos.

En mi caso, el problema era con el ejecutable de shell incorrecto.

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

Se cambió el archivo / etc / passwd para ese usuario

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

Tuve este problema en CentOS 7. Soy un usuario habitual de Linux basado en Debian, así que era un pez fuera del agua. Noté que en algunos de los servidores funcionaba y en uno solo no. Audit.log no dijo nada útil y secure.log tampoco dio nada. Descubrí que la única diferencia real era algunas diferencias de contexto de seguridad en los archivos y directorios entre los que funcionaban y los que no. Obtenga la seguridad con

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

del directorio (supongo que hay muchos valores predeterminados en sshd_config).

Deberías ver algunos ssh_home_tyuser_home_t atributos. Si no lo hace, use el chconcomando para agregar los atributos que faltan.

Por ejemplo

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"

En mi caso, mi sospecha es que el usuario fue creado de una manera no estándar. Su casa era un directorio en/var/lib .

Más información en: https://www.linuxquestions.org/questions/linux-security-4/selinux-preventing-ssh-login-with-~-ssh-authorized_keys-4175469538/