La conexión SSH solicita contraseña aunque se acepta la clave

Se me solicita una contraseña a pesar de que parece que se acepta mi clave SSH. Por lo que puedo decir, la línea "El servidor acepta la clave: pkalg ssh-rsa blen 277" en los registros a continuación significa que mi clave es aceptada.

Aquí hay registros de depuración:

debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/sam/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug2: input_userauth_pk_ok: fp <<HASH REDACTED>>
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /home/sam/.ssh/id_dsa
debug1: Trying private key: /home/sam/.ssh/id_ecdsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1

Ayuda muy apreciada, todos los que he encontrado que tienen problemas de SSH fallan en un punto anterior que estoy viendo.

Su clave privada ciertamente no fue aceptada, solo se intentó. Hay varias formas en que la autenticación basada en claves SSH puede fallar, y el registro no es realmente tan bueno, por lo que depurar este problema en particular es una de mis manías personales. Descubrí que el error suele ser el resultado de una de las siguientes situaciones.

• Tu ~/.ssh/authorized_keysarchivo está demasiado abierto. Por tu propia protección, sshdintenta protegerte de ti mismo. Si los permisos en su archivo de claves autorizado fallará la autenticación. Ejecutar chmod -R go-rwx ~/.ssh.
• Su clave pública ~/.ssh/authorized_keysestá mal formada. Esto podría ser el resultado de cualquier número de problemas, pero el más común es un problema de copiar y pegar. Algunas terminales, al copiar / pegar en pantallas, interpretarán un ajuste de línea como una nueva línea. Cada entrada en el authorized_keysarchivo debe ser una sola línea. Puede verificar esto cambiando el tamaño de su emulador de terminal y ver si hay una interrupción, comparando la salida de wc -l ~/.ssh/authorized_keysla cantidad de teclas que deberían estar allí, o lo que sea mejor para usted. Solo asegúrese de que cada clave sea una línea y que esté bien.

La salida ssh -v que pegó sugirió que intentó usar la tecla pero no funcionó, por lo que pasó a teclado interactivo.

¿Ha verificado el registro de autenticación en el servidor al que se está conectando? (por ejemplo, /var/log/auth.log). Si su configuración en el extremo remoto es incorrecta, por ejemplo, permisos incorrectos, entonces ssh -v (o -vv o -vvv) no le dirá esto, pero sshd lo registrará.

En mi caso, el archivo /var/log/authlogmostró:

[ID 800047 auth.info] Authentication refused: bad ownership or modes for directory 

Había verificado la propiedad / permisos correctos .sshpero $HOMEtenía 777 permisos. Establecer 755 permisos en $HOMEsftp permitido para trabajar. Gracias de nuevo.

Si tiene acceso al servidor (directamente o mediante otro inicio de sesión), verifique los registros del servidor (digamos) /var/log/sshdo /var/log/securedependiendo de su sistema

Generalmente es causado por un error de permisos en su ~/.ssh/authorized_keysarchivo. Asegúrese de que no sea legible en todo el mundo, pero es crucial que sea legible por el usuario (a veces un usuario del servicio) que ejecuta sshd

Los permisos ~/.ssh/authorized_keysen remoto son importantes ( 600para mis sistemas RHEL y Solaris)

Los permisos de su directorio de inicio en remoto son importantes ( 700en mis sistemas)

Al final, ejecutar sshden una máquina remota en modo de depuración en otro puerto puede ser útil:

sudo /usr/sbin/sshd -p 5555 -dd

5555es un puerto de ejemplo, puedes cambiarlo. Para obtener más información al respecto, puede ver: http://ubuntuforums.org/archive/index.php/t-2219973.html

Descubrí que hay un problema si uso el sshdservicio. Para evitar este problema, detenga el sshdservicio con service sshd stopy luego inicie el sshddemonio desde el símbolo del sistema con sudo /usr/sbin/sshd.

Tratar

/sbin/restorecon -r /root/.ssh

Un posible problema con la configuración de permisos.