La autenticación de clave SSH falla

30

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 [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).
ssh sshd ssh-keys Tim
fuente
Desde las tapas, parece que se envía la clave, pero nunca se recibe respuesta. -¿Se supone que debes iniciar sesión como root o iniciar sesión como tim y luego usar sudo? A veces, el inicio de sesión ssh como root está deshabilitado. -¿Cuáles son los permisos del directorio .ssh en sí? -¿Tiene el servidor correcto? ¿Se está resolviendo dns correctamente? -Podrías crear las claves nuevamente y luego usar ssh-copy-id para copiar manualmente la nueva clave pública en el archivo autorizado_claves. Por si acaso la clave se corrompe de alguna manera.
Kyle H
¡Gracias por intentar ayudar! los permisos en mi carpeta .ssh son: drwx ------ 2 tim tim 4096 Okt 20 22:13 .ssh. Iniciar sesión como root es correcto: en realidad funcionó hace un par de semanas antes de reformatear mi computadora. El administrador dice que ha agregado las nuevas claves correctamente, pero realmente no sé cómo podría ser mi culpa en este momento
Tim
Como mencionó @KyleH, ¿ha intentado con ssh [email protected]el registro menciona Kerberos que el servidor CentOS podría ser Dominio integrado (AD, IPA, ...). Tienes que averiguar qué usuario debes usar. Pregúntale al administrador. Por ejemplo, estamos utilizando IPA, por lo que permitimos a los usuarios conectarse a ciertos servidores con su cuenta de dominio IPA y su par de claves y, si es necesario, pueden sudo. Sin acceso root :)
Zina

Respuestas:

18

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

Jamieson Becker
fuente
Si este fuera el problema, el cliente no habría intentado enviar la clave al servidor en primer lugar; El registro que figura en la pregunta es explícito.
Charles Duffy
Esto corrige el problema del lado del servidor. Tienes razón en que el lado del cliente está bien.
Jamieson Becker
1
Esto finalmente resolvió mi problema. Pasé horas tratando de averiguar por qué no se aceptaban mis claves públicas / privadas.
Daniel Harris
Otro usuario sugirió sudo chown $USER:$USER ~/ -R; sudo chmod o-rwx ~/ -Rlo que ahorrará tiempo de escritura, pero podría ser más difícil de entender para un novato
Jamieson Becker, el
11

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

Cyril Chaboisseau
fuente
Gracias por eso chmod -t... Terminé con:admin@SYN:~$ ls -ald . .ssh .ssh/* drwxr-xr-x 6 admin users 4096 Jan 10 15:54 . drwx------ 2 admin users 4096 Jan 10 15:54 .ssh -rwx------ 1 admin users 401 Jan 10 15:54 .ssh/authorized_keys -rw------- 1 admin users 1679 Jan 10 15:49 .ssh/id_rsa -rwxr--r-- 1 admin users 396 Jan 10 15:49 .ssh/id_rsa.pub -rwx------ 1 admin users 396 Jan 10 10:04 .ssh/known_hosts
Stéphane
6

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.

JonCav
fuente
4

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?

Kyle H
fuente
Los permisos en mi carpeta de inicio (tim) son 755 (drwxr-xr-x) y los permisos en la carpeta .ssh en sí son 700 (drwx). id_rsa es 600 y el archivo .pub es 644 ..: / gracias de nuevo, espero que la información ayude
Tim
Tengo ssh trabajando para muchos servidores. Mi directorio de inicio es drwxr-xr-x (0755), .ssh es rwx ------ (0700), dentro de .ssh mi clave de pub es -rw-r - r-- (0644), y el resto en esa carpeta están -rw ------- (0600). Por lo tanto, sus permisos son buenos y debe pasar la comprobación estricta del host. ¿Qué hay en su archivo / etc / ssh_config? ¿Algo en ~ / .ssh / config? He tenido la creación de claves ssh por una razón u otra que no funciona a pesar de que no hubo errores. ¿Puede intentar usar ssh-keygen para regenerar sus claves, ssh-copy-id para copiar su clave de publicación en el servidor remoto que tiene activada la autenticación de contraseña?
Kyle H
Desafortunadamente, no tengo acceso al servidor, pero intentaré que el administrador copie mi clave de pub al servidor nuevamente el lunes. Copié el contenido de los archivos de configuración en pastebin: pastebin.com/eEaVMcvt , gracias de nuevo por su ¡ayuda!
Tim
De nada. Estoy feliz de ayudar! También disfruto resolviendo problemas y especialmente ayudando a otros con Linux. Hay una línea extraña en su ssh-config que podría causar problemas donde está. ¿Qué es la ip 10.0.12.28?
Kyle H
@KyleH tiene razón ... eso es casi seguro el problema. Agregué otra respuesta que muestra cómo solucionarlo con acceso root. Si controlas tu homedir, posiblemente puedas arreglarlo tú mismo, pero, por supuesto, deberías poder iniciar sesión :)
Jamieson Becker
4

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.

Nathan Crause
fuente
Su respuesta me marcó a mi caso diferente, pero también relacionado con el usuario, de mi intento de iniciar sesión cuando el directorio de inicio que había dado estaba más anidado que el que estaba iniciando sesión ... ¡Genial para arreglarlo, gracias!
Brett Zamir
2

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 .

Elouan Keryell-Even
fuente
Siaahhhh ¡SERIAMENTE! Nunca habría visto eso. openssh-8.0p1-5.fc30.x86_64por cierto. Tenía la clave pública del servidor anterior con el mismo nombre que el nuevo fedora@(baloo).sshkey.pub, que se fedora@(baloo).sshkeypasa en la línea de comando con la -iopción. La autenticación falló con la nueva clave del servidor encontrada en la nueva fedora@(baloo).sshkey: una clave RSA.
David Tonhofer
2

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.

gaoithe
fuente
2

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.

Aaron Chamberlain
fuente
1

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.

lapin_
fuente
1

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.

ihoru
fuente
1

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.

nelaaro
fuente
0

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
[email protected]'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.

kbulgrien
fuente
0

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.

Alexx Roche
fuente
0

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
....
nelaaro
fuente
0

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/

hanzo2001
fuente