¿Por qué sigo recibiendo una solicitud de contraseña con ssh con autenticación de clave pública?

470

Estoy trabajando desde la URL que encontré aquí:

http://web.archive.org/web/20160404025901/http://jaybyjayfresh.com/2009/02/04/logging-in-without-a-password-certificates-ssh/

Mi cliente ssh es Ubuntu 64 bit 11.10 de escritorio y mi servidor es Centos 6.2 64 bit. He seguido las instrucciones. Todavía recibo un mensaje de contraseña en ssh.

No estoy seguro de qué hacer a continuación.

Thom
fuente
55
salida del comando que le estás dando a ssh con la bandera -v? debería ser similar a este pastebin.com/xxe57kxg
Rob
14
también asegúrese de que su carpeta .ssh eschmod 700
Rob
8
suponiendo que tenga acceso de root al servidor, /var/log/auth.logle dirá por qué falla el inicio de sesión.
UtahJarhead
55
@UtahJarhead: en el servidor CentOS, es probable que esté en /var/log/secure.
Dennis Williamson
3
Interesante, el chmod 0700fue la respuesta, pero cuando lo hice ssh -ven el lado del cliente no indicó un error relacionado con por qué no se aceptó la clave, solo dijo que estaba intentando la contraseña a continuación a pesar de que mi cliente envió una clave pública. ¿Cómo esperan que diagnostiquemos problemas sin información de error del servidor?
void.pointer

Respuestas:

557

Asegúrese de que los permisos en el ~/.sshdirectorio y su contenido sean correctos. Cuando configuré por primera vez la autenticación de mi clave ssh, no tenía la ~/.sshcarpeta configurada correctamente y me gritó.

  • Su directorio de inicio ~, su ~/.sshdirectorio y el ~/.ssh/authorized_keysarchivo en la máquina remota deben ser editables solo por usted: rwx------y rwxr-xr-xestán bien, pero rwxrwx---no son buenos¹, incluso si usted es el único usuario en su grupo (si prefiere los modos numéricos: 700o 755no 775) .
    Si ~/.ssho authorized_keyses un enlace simbólico, se marca la ruta canónica (con enlaces simbólicos expandidos) .
  • Su ~/.ssh/authorized_keysarchivo (en la máquina remota) debe ser legible (al menos 400), pero necesitará que también se pueda escribir (600) si le agrega más claves.
  • Su archivo de clave privada (en la máquina local) debe ser legible y escribible solo por usted: rw-------es decir 600.
  • Además, si SELinux está configurado para imponerse, es posible que deba ejecutarlo restorecon -R -v ~/.ssh(consulte, por ejemplo, el error de Ubuntu 965663 y el informe de errores de Debian # 658675 ; esto está parcheado en CentOS 6 ).

¹ Excepto en algunas distribuciones (Debian y derivados) que han parcheado el código para permitir la escritura del grupo si usted es el único usuario en su grupo.

Robar
fuente
29
Muchas gracias por señalar restorecon. He estado rascándome la cabeza precisamente por este problema desde hace un tiempo.
Richard Barrell
19
Por extraño que parezca, estaba teniendo problemas con una cuenta que un amigo creó en su VPS para que funcione la autenticación de pubkey. Pensé que todos los permisos eran correctos, pero es importante recordar que /home/USERdebe ser 700o755
Rob
2
También recuerde verificar la configuración del propietario y del grupo, ¡utilicé RSYNC para copiar sobre un archivo autorizado_claves y no noté que el propietario / grupo estaba configurado en 1000 en lugar de root!
nak
11
también, agregue -v a su comando ssh para ver qué sucede con esa tecla. ssh -v user@host.
tedder42
14
chmod -R 700 ~/.sshfuncionó para mí cumplir con las limitaciones de esta respuesta (RHEL 7)
scottyseus
147

Si tiene acceso de root al servidor, la manera fácil de resolver tales problemas es ejecutar sshd en modo de depuración, emitiendo algo como /usr/sbin/sshd -d -p 2222en el servidor (puede ser necesaria la ruta completa al ejecutable de sshd which sshd) y luego conectarse desde el cliente ssh -p 2222 user@host. Esto obligará al demonio SSH a permanecer en primer plano y mostrar información de depuración sobre cada conexión. Busca algo como

debug1: trying public key file /path/to/home/.ssh/authorized_keys
...
Authentication refused: bad ownership or modes for directory /path/to/home/

Si no es posible utilizar un puerto alternativo, puede detener temporalmente el demonio SSH y reemplazarlo por uno en modo de depuración. Al detener el demonio SSH no se eliminan las conexiones existentes, por lo que es posible hacerlo a través de un terminal remoto, pero es algo arriesgado: si la conexión se interrumpe de alguna manera en el momento en que el reemplazo de depuración no se está ejecutando, queda bloqueado fuera de la máquina hasta que puedas reiniciarlo. Los comandos requeridos:

service ssh stop
/usr/sbin/sshd -d
#...debug output...
service ssh start

(Dependiendo de su distribución de Linux, la primera / última línea podría ser systemctl stop sshd.service/ en su systemctl start sshd.servicelugar).

Tgr
fuente
55
Acabo de intentar esto ... y funciona bien cuando estoy corriendo sshd -d, pero falla una vez que realmente corro service sshd start. Estoy seguro de que es simple, pero no soy un gurú de Linux. ¿Alguna idea?
N Rohler
3
Como referencia, esta publicación explica la solución SELinux que resolvió mi problema.
N Rohler
2
También estaba teniendo problemas para que la autenticación de clave pública funcionara y estaba bastante seguro de que los permisos de directorio no eran el problema. Después de ejecutar SSH en modo de depuración, rápidamente descubrí que estaba equivocado y que los permisos eran los problemas.
ub3rst4r
3
Gran consejo, mi carpeta de usuario tenía los permisos incorrectos.
gdfbarbosa
2
Gracias. Por todas las razones, mi usuario no tenía permitido iniciar sesión porque el shell especificado por ansible (/ bin / zsh) en la creación del usuario no existía. Nunca lo habría adivinado.
chishaku
53

¿Está encriptado el directorio de inicio? Si es así, para su primera sesión ssh deberá proporcionar una contraseña. La segunda sesión ssh para el mismo servidor funciona con la clave de autenticación. Si este es el caso, puede moverlo authorized_keysa un directorio sin cifrar y cambiar la ruta ~/.ssh/config.

Lo que terminé haciendo fue crear una /etc/ssh/usernamecarpeta, propiedad de nombre de usuario, con los permisos correctos, y coloqué el authorized_keysarchivo allí. Luego cambió la directiva AuthorizedKeysFile /etc/ssh/configa:

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

Esto permite que múltiples usuarios tengan este acceso ssh sin comprometer los permisos.

cee
fuente
3
Esta respuesta es destacada y me ayudó, para cualquiera que se pregunte si este es el problema, puede ver "pam_ecryptfs: archivo de frase de contraseña envuelto" en su auth.log; de alguna manera eso no fue suficiente para recordarme que el homedir estaba encriptado. También puede encontrar que el primer inicio de sesión solicita una contraseña, las sesiones posteriores no (ya que se descifra mientras se abren las otras sesiones).
pacifista
Santa mierda, he buscado muchísimo para resolver ese problema, ¡te agradezco mucho!
h3.
33

Después de copiar las llaves en la máquina remota y ponerlas dentro de la máquina, authorized_keysdebe hacer algo como esto:

ssh-agent bash
ssh-add ~/.ssh/id_dsa or id_rsa
gusior
fuente
1
En realidad no, no lo haces. ssh usa automáticamente ~ / .ssh / id_rsa (o id_dsa) sin tener que usar un agente clave.
Patrick
77
Esto todavía puede ser un consejo útil si se especificara una clave con un nombre diferente en ~ / .ssh / config (por ejemplo, en el host * .midominio.org ... IdentityFile ~ / .ssh / some_limited_use.pub - ssh-add ~ / .ssh / some_limited_use.pub).
89c3b1b8-b1ae-11e6-b842-48d705
Esto ha resuelto mi problema con la solicitud de contraseña después de agregar una clave. Como señaló 89c3b1b8-b1ae-11e6-b842-48d705, la razón para ejecutar estos comandos manualmente era un nombre no estándar de un archivo de clave.
Михаил Лисаков
Como se señaló anteriormente en los comentarios, si está utilizando una clave además de la clave predeterminada, no se agrega de forma predeterminada al agente ssh. Así que asegúrese de verificar que la clave que desea usar está en el llavero del agente:ssh-add -L
James
30

Solo prueba estos siguientes comandos

  1. ssh-keygen

    Presione la tecla Intro hasta que aparezca el mensaje

  2. ssh-copy-id -i root@ip_address

    (Una vez pedirá la contraseña del sistema host)

  3. ssh root@ip_address

    Ahora debería poder iniciar sesión sin ninguna contraseña

Ravindra
fuente
1
¿En que servidor?
Amalgovinus
@Amalgovinus Obviamente ejecutas esto en el cliente, no en la máquina a la que te estás conectando, ¡no quieres una copia de tu clave privada en el servidor! :)
nevelis
44
Tenga en cuenta que, en general, permitir inicios de sesión raíz remotos no es una práctica de seguridad recomendada.
arielf
27

Enfrenté desafíos cuando el directorio de inicio en el control remoto no tiene los privilegios correctos. En mi caso, el usuario cambió el directorio de inicio a 777 para tener acceso local en el equipo. La máquina ya no podía conectarse con las teclas ssh. Cambié el permiso a 744 y comenzó a funcionar nuevamente.

Sahil
fuente
77
También tuvimos este problema: 755 en los
directorios de
Tenía permisos establecidos en 777 y fue ignorado, ¡gracias!
ka_lin
Igual que aquí. Gracias. Me estaba rascando la cabeza por un tiempo, wtf estaba sucediendo.
Marcin
Sí, vea la respuesta aquí para obtener más detalles unix.stackexchange.com/questions/205842/…
Tim
Esta puede ser la respuesta para las personas que han realizado la generación de claves correctamente y todavía se les solicita una contraseña.
Fergie
14

SELinux en RedHat / CentOS 6 tiene un problema con la autenticación de clave pública , probablemente cuando se crean algunos de los archivos, selinux no está configurando sus ACL correctamente.

Para corregir manualmente las ACL de SElinux para el usuario root:

restorecon -R -v /root/.ssh
David Mackintosh
fuente
usando el cliente openssh en Windows pude ssh root@mymachineingresar a un CentOS6 mymachinesin problemas, pero tengo un usuario de menor privilegio que preferiría usar, pero ssh regularUser@mymachineaún así me pide una contraseña. pensamientos?
Groostav
13

Nos encontramos con el mismo problema y seguimos los pasos de la respuesta. Pero todavía no funcionó para nosotros. Nuestro problema era que el inicio de sesión funcionaba desde un cliente pero no desde otro (el directorio .ssh estaba montado en NFS y ambos clientes usaban las mismas claves).

Así que tuvimos que ir un paso más allá. Al ejecutar el comando ssh en modo detallado obtienes mucha información.

ssh -vv user@host

Lo que descubrimos fue que la clave predeterminada (id_rsa) no fue aceptada y, en su lugar, el cliente ssh ofreció una clave que coincidía con el nombre de host del cliente:

debug1: Offering public key: /home/user/.ssh/id_rsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: /home/user/.ssh/id_dsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: user@myclient                                          
debug2: we sent a publickey packet, wait for reply                                        
debug1: Server accepts key: pkalg ssh-rsa blen 277                  

Obviamente, esto no funcionará desde ningún otro cliente.

Entonces, la solución en nuestro caso fue cambiar la clave rsa predeterminada a la que contenía user @ myclient. Cuando una clave es predeterminada, no se verifica el nombre del cliente.

Luego nos encontramos con otro problema, después del cambio. Aparentemente, las claves se almacenan en caché en el agente ssh local y obtuvimos el siguiente error en el registro de depuración:

'Agent admitted failure to sign using the key'

Esto se resolvió volviendo a cargar las claves en el agente ssh:

ssh-add
Joachim Nilsson
fuente
9

Sería una configuración de fallo SSH al final del servidor. Se debe editar el archivo sshd_config del lado del servidor. Situado en /etc/ssh/sshd_config. En ese archivo, cambie las variables

  • 'sí' a 'no' para ChallengeResponseAuthentication, PasswordAuthentication, UsePAM

  • 'no' a 'sí' para PubkeyAuthentication

Basado en http://kaotickreation.com/2008/05/21/disable-ssh-password-authentication-for-added-security/

nish
fuente
1
Como en los comentarios a las preguntas, verifique / var / log / secure o /var/log/auth.log. En mi caso, veo "Usuario xxx de xxx no permitido porque no aparece en AllowUsers" "input_userauth_request: usuario no válido xxx [preauth]" (y "rexec línea 35: Opción obsoleta ServerKeyBits" en / var / log / messages aunque no sé qué es decir). Para resolver vi /etc/ssh/sshd_config, agregue el usuario xxx a la lista de usuarios permitidos, service sshd restart*** ¡CUIDADO, reiniciar el servicio sshd con sshd_config incorrecto podría bloquearlo de la caja !? ***. Eso funciono.
Gaoithe
6

Asegúrese de que AuthorizedKeysFileapunta a la ubicación correcta, use %ucomo marcador de posición para el nombre de usuario:

# /etc/ssh/sshd_config
AuthorizedKeysFile /home/%u/authorized_keys

Puede ser que solo necesite descomentar la línea:

AuthorizedKeysFile .ssh / certified_keys

Tenga en cuenta que debe volver a cargar el servicio ssh para que se realicen los cambios:

service sshd reload
Dziamid
fuente
4

Dos comentarios: esto sobrescribirá el archivo original. Simplemente copiaría la clave pública generada y haría algo como:

cat your_public_key.pub >> .ssh/authorized_keys

Esto agregará la clave que desea utilizar a la lista de claves preexistente. Además, algunos sistemas usan el archivo authorized_keys2, por lo que es una buena idea hacer un enlace duro que apunte entre authorized_keysy authorized_keys2, por si acaso.

Wojtek Rzepala
fuente
Sí, también noté eso sobre la sobrescritura, pero no tenía ninguna, así que no importó. Creé un enlace simbólico a autorizado_keys2 pero eso no ayudó.
Thom
Además, verifique los permisos de archivo / directorio. Se describen en el sitio web que proporcionó.
Wojtek Rzepala
3
su directorio ~ / .ssh debe ser 700 su archivo de clave privada debe ser 600 su archivo de clave pública debe ser 644 su archivo de autenticación (en el control remoto) debe ser 644
Rob
@Rob ese fue el problema. Si publicaras eso como respuesta, lo aceptaría.
Thom
4

Mi solución fue que la cuenta estaba bloqueada. Mensaje encontrado en / var / log / secure: Usuario no permitido porque la cuenta está bloqueada Solución: proporcione al usuario una nueva contraseña.

user46932
fuente
Lo arreglé cambiando el campo de contraseña /etc/shadowpara este usuario de !a *. Después de eso, la autenticación de contraseña sigue siendo imposible, pero el usuario ya no está bloqueado.
user3132194
4

Me encontré con un problema similar y seguí los pasos con el modo de depuración.

/usr/sbin/sshd -d

Esto mostró el siguiente resultado

debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
Authentication refused: bad ownership or modes for directory /root
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys2
debug1: Could not open authorized keys '/root/.ssh/authorized_keys2': No such file or directory
debug1: restore_uid: 0/0
Failed publickey for root from 135.250.24.32 port 54553 ssh2
debug1: userauth-request for user root service ssh-connection method gssapi-with-mic

Fue realmente confuso

[root@sys-135 ~]# ls -l /
drwxrwxrwx.   2 root root     4096 Dec 14 20:05 bin
drwxrwxrwx.   5 root root     1024 May  6  2014 boot
drwxrwxrwx.   2 root root     4096 Dec  2  2013 cgroup
drwxrwxrwx.  10 root root     1024 Sep 25 23:46 data
drwxrwxrwx. 124 root root    12288 Dec 16 10:26 etc
drwxrwxrwx.  11 root root     4096 Jan 14  2014 lib
drwxrwxrwx.   9 root root    12288 Dec 14 20:05 lib64
drwxrwxrwx.   2 root root    16384 Jan 10  2014 lost+found
drwxrwxrwx.   2 root root     4096 Jun 28  2011 media
drwxr-xr-x.   2 root root        0 Dec 10 14:35 misc
drwxrwxrwx.   2 root root     4096 Jun 28  2011 mnt
drwxrwxrwx.   4 root root     4096 Nov 24 23:13 opt
dr-xr-xr-x. 580 root root        0 Dec 10 14:35 proc
drwxrwxrwx.  45 root root     4096 Dec 16 10:26 root

Mostró que el directorio raíz tenía permisos para cada uno. Lo cambiamos para que otros no tuvieran permisos.

[root@sys-135 ~]# chmod 750 /root

La autenticación de clave comenzó a funcionar.

Jagadish
fuente
Tengo el mismo problema Ayer, emití rsync -av ./root/ root@THE_HOST:/rootpara cargar algunos archivos de mi directorio de trabajo local, luego, este problema ocurre (de hecho, al principio no lo noté. Después de que fallan los trabajos cron en otros hosts a la mañana siguiente, comencé a investigar el motivo) . El rsync -av ./root/ root@THE_HOST:/rootcomando cambió el propietario y el permiso del /rootdirectorio del host remoto. Arreglado el permiso, problema resuelto.
LiuYan 刘 研
Failed publickey for root from 135.250.24.32 port 54553 ssh2Recibo el mismo mensaje y problema cuando olvidé agregar la clave pública a un host authorized_keys. Al agregar este comentario como en mi caso, generalmente me doy cuenta de mi error después de verificar la depuración y todos los permisos más los archivos de configuración #: o <
tuk0z
3

En el archivo / etc / selinux / config, el cambio de SELINUX a desactivado hace que el ssh sin contraseña funcione correctamente.

Anteriormente, puedo hacerlo de una manera. Ahora desde ambos lados puedo hacer ssh sin contraseña.

chinna
fuente
3

Una cosa que me equivoqué fue la propiedad de mi directorio de inicio en el sistema del servidor. El sistema del servidor se configuró como predeterminado: predeterminado, entonces yo:

chown -R root:root /root

Y funcionó. Otra solución económica es deshabilitar StrictModes: StirctModes no. en sshd_config. Esto al menos le dirá si el intercambio de claves y los protocolos de conexión son buenos. Entonces puedes ir a cazar los malos permisos.

Será
fuente
Yo también. Mire los mensajes en / var / log / secure. Vi un mensaje: "Autenticación rechazada: propiedad o modos incorrectos para el directorio" ($ HOME). Asegúrese de que no haya acceso de escritura a $ HOME para Grupo u Otro. Nunca habría encontrado esto si no tuviera acceso raíz no autorizado al servidor ...
SoloPilot
2

Para mí, la solución era opuesta a la de Wojtek Rzepala : no me di cuenta de que todavía estaba usando authorized_keys2, lo que ha quedado en desuso . Mi configuración ssh dejó de funcionar en algún momento, presumiblemente cuando se actualizó el servidor. Renombrar .ssh/authorized_keys2como .ssh/authorized_keyssolucionó el problema.

D'oh!

Michael Scheper
fuente
Esta también es una opción de configuración en / etc / ssh / sshd_config, aunque creo que cambiaría el nombre como lo hiciste.
Rick Smith
2

En el pasado, encontré algunos tutoriales que describen cómo lograr una configuración ssh sin contraseña, pero algunos están tristemente equivocados.
Comencemos de nuevo y verifiquemos cada paso:

  1. DEL CLIENTE - Generar clave: la clave ssh-keygen -t rsa
    pública y privada ( id_rsa.puby id_rsa) se almacenará automáticamente en el ~/.ssh/directorio.
    La configuración será más fácil si usa una frase de contraseña vacía. Si no está dispuesto a hacer eso, siga esta guía, pero también revise el punto siguiente.

  2. DEL CLIENTE - Copiar clave pública al servidor : ssh-copy-id user@server
    la clave pública del cliente se copiará en la ubicación del servidor ~/.ssh/authorized_keys .

  3. DE CLIENTE - Conéctese al servidor:ssh user@server

Ahora, si aún no funciona después de los 3 pasos descritos, intentemos lo siguiente:

  • Verifique los ~/sshpermisos de carpeta en la máquina cliente y servidor .
  • Compruebe /etc/ssh/sshd_configen el servidor para asegurarse de que RSAAuthentication, PubkeyAuthenticationy las UsePAMopciones no están deshabilitadas, se pueden habilitar de forma predeterminada con yes.
  • Si ingresó una frase de contraseña al generar su clave de cliente, puede intentar ssh-agenty ssh-addlograr conexiones sin contraseña en su sesión.
  • Compruebe el contenido de /var/log/auth.logen el servidor para encontrar el problema por el cual se omite la autenticación de clave.
bagazo
fuente
¡Gracias por enumerar los pasos! Llegué a "ssh-copy-id user @ server" y me di cuenta de que originalmente había copiado sobre la clave pública incorrecta.
mattavatar
2

Estaba teniendo exactamente el mismo problema con PuTTY conectándose a una máquina Ubuntu 16.04. Fue desconcertante porque el programa pscp de PuTTY funcionaba bien con la misma clave (y la misma clave funcionaba en PuTTY para conectarse a otro host).

Gracias al valioso comentario de @UtahJarhead, revisé mi archivo /var/log/auth.log y encontré lo siguiente:

sshd[17278]: userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]

Resulta que las versiones más nuevas de OpenSSH no aceptan claves DSA por defecto. Una vez que cambié de una clave DSA a una clave RSA, funcionó bien.

Otro enfoque: esta pregunta analiza cómo configurar el servidor SSH para aceptar claves DSA: https://superuser.com/questions/1016989/ssh-dsa-keys-no-longer-work-for-password-less-authentication?lq = 1

Chad
fuente
1

Estos pasos deberían ayudarte. Lo uso regularmente entre muchas máquinas Ubuntu 10.04 de 64 bits.

[ ! -f ~/.ssh/id_rsa.pub ] && ssh-keygen -t rsa;
ssh <username>@<remote_machine> 'mkdir -p ~/.ssh'
cat ~/.ssh/id_rsa.pub | ssh <username>@<remote_machine> 'cat >> ~/.ssh/authorized_keys'

podría poner esto en un script con algunas indicaciones e invocarlo como

script_name username remote_machine
Sriharsha
fuente
Ya existe lo ssh-copy-idque hace los dos últimos pasos automáticamente.
jofel
2
@jofel tenga en cuenta que en muchos sistemas ssh-copy-id no existe. @Sriharsha después de mkdirque también debería agregar allí chmod 700 .sshy, por cierto, no necesita ser tan detallado ~/.ssh, solo .sshes suficiente ya que los comandos se ejecutan en el directorio de inicio de todos modos
janos
1

Tuve un problema similar con ssh. En mi caso, el problema fue que instalé hadoop cloudera (desde rpm en centos 6) y creó hdfs de usuario con el directorio de inicio

/var/lib/hadoop-hdfs(no estándar /home/hdfs)

Cambié en / etc / passwd /var/lib/hadoop-hdfsa /home/hdfs, moví el directorio de inicio a una nueva ubicación y ahora puedo conectarme con la autenticación de clave pública.

Andrzej Jozwik
fuente
1

Sólo tenía este mismo problema, y para mí la solución era establecer UsePAMa no. Verá, incluso con PasswordAuthenticationset to no, todavía obtendrá keyboard-interactive, y en mi caso, mi programa ssh local siguió por defecto, por alguna razón.

Antecedentes adicionales para ayudar a cualquier persona con la misma situación: me estoy conectando desde un host que ejecuta Dropbear a uno que ejecuta OpenSSH. Con PasswordAuthenticationy UsePAMambos configurados noen la máquina remota, recibiré el siguiente mensaje si ingreso ssh user@server:

ssh: Connection to user@server:22 exited: Disconnect received

Al proporcionar el archivo de identidad -i, todo funciona como se esperaba.

Puede haber un poco más de información aquí.

Marty
fuente
1

Después de verificar los permisos y probar varias otras soluciones enumeradas aquí, finalmente eliminé el directorio ssh del servidor y configuré nuevamente mi clave pública.

Comandos del servidor:

# rm -rf ~/.ssh

Comandos locales:

# ssh-copy-id [email protected]        # where <user> is your username and <192.168.1.1> is the server IP
Steven C. Howell
fuente
1

En el servidor:

$ ls -lh /home
$ sudo chmod 700 /home/$USER

Fue directory permission issue. Era 777 en el servidor, entonces I changed it back to 700. Este es fixedmi problema ssh password less login failureincluso después de copiar $USER/.ssh/id_rsa.pubal servidor $USER/.ssh/authorized_keys.

fastrizwaan
fuente
0

Sin embargo, otra opción es una variante de @Jagadish 's respuesta : para straceel demonio ssh.

Tiene la ventaja significativa de que no necesitamos detener el sshd, lo que puede resultar en un bloqueo completo si algo sale mal.

Primero, encontramos el pid del proceso sshd principal. Aquí podemos verlo ejecutando a pstree -pa|less.

  |-sshd,633 -D  <-- THIS IS WHAT WE WANT!
  |   `-sshd,21973   
  |       `-sshd,21996    
  |           `-bash,22000
  |               `-screen,638 -r

Después de saber que el pid es 633, podemos stracehacerlo, siguiendo a sus hijos:

strace -p 633 -s 4096 -f -o sux

El resultado será que todo lo que este sshd, y sus procesos secundarios han hecho, se dividirá en el archivo nombrado suxen el directorio local.

Luego reproduce el problema.

Tendrá una lista masiva de registro de llamadas del núcleo, que en su mayoría es incomprensible / irrelevante para nosotros, pero no en todas partes. En mi caso, lo importante fue esto:

6834  sendto(4, "<38>Jan 15 18:49:21 sshd[6834]: User cica not allowed because account is locked\0", 84, MSG_NOSIGNAL, NULL, 0) = 84

Fue mentos, que el sshd intentó registrar el mensaje El usuario cica no está permitido porque la cuenta está bloqueada , solo que no pudo, porque el registro no es lo suficientemente detallado para eso. Pero ya sabemos, se rechazó la clave pública porque la cuenta estaba bloqueada.

Todavía no es una solución: ahora necesitamos googlear, lo que significa una "cuenta bloqueada" en el caso del sshd. Lo más probable es que sea algo trivial /etc/passwd, /etc/shadowmágico, pero lo importante está hecho: el problema no es misterioso, sino fácil de depurar / buscar en Google.

Peter
fuente
0

En mi caso, tenía todos los permisos correctos e incluso cuando ejecuté ssh con la bandera -vvv no pude entender cuál era el problema.

Entonces generé un nuevo certificado en un host remoto

ssh-keygen -t rsa -C "[email protected]"

y copié las claves generadas en la máquina local y agregó una nueva clave pública a ~ / .ssh / Authorizedkeys en el host remoto

cat id_rsa.pub >> authorized_keys

El uso de claves generadas desde la conexión remota de máquina host ahora funciona. Entonces, si otras soluciones fallan, esta es otra cosa para probar.

kovinet
fuente
0

Mi escenario fue que tengo un servidor NAS en el que creé un backupbotusuario, después de la creación de mi cuenta principal, que pudo iniciar sesión para crear inicialmente el backupbotusuario. Después de jugar sudo vim /etc/ssh/sshd_configy crear el backupbotusuario, vimpuede crear, al menos en Ubuntu 16.04, y según su ~/.vimrcconfiguración, un archivo de intercambio que queda de la edición de su sesión de vim /etc/ssh/sshd_config.

Comprueba si /etc/ssh/.sshd_config.swpexiste : y si lo elimina, reinicia el sshddemonio:

$ sudo rm /etc/ssh/.sshd_config.swp
$ sudo service sshd restart

Esto resolvió mágicamente mi problema. Anteriormente había verificado todos mis permisos e incluso las huellas digitales RSA de las claves públicas y privadas. Esto es extraño y probablemente un error con sshd, específicamente esta versión:

OpenSSH_7.4p1 Ubuntu-10, OpenSSL 1.0.2g 1 de marzo de 2016

rivanov
fuente