ssh solicita contraseña a pesar de ssh-copy-id

He estado utilizando la autenticación de clave pública en un servidor remoto desde hace algún tiempo para uso de shell remoto, así como para montajes sshfs. Después de forzar un desmontaje de mi directorio sshfs, noté que ssh comenzó a solicitarme una contraseña. Traté de purgar el .ssh remoto / autorizado_claves de cualquier mención de la máquina local, y limpié la máquina local de referencias a la máquina remota. Luego repetí mi ssh-copy-id, me solicitó una contraseña y regresó normalmente. Pero he aquí, cuando ssh al servidor remoto todavía se me solicita una contraseña. Estoy un poco confundido sobre cuál podría ser el problema, ¿alguna sugerencia?

sshd se vuelve raro acerca de los permisos en $ HOME, $ HOME / .ssh (ambos directorios) y en $ HOME / .ssh / optional_keys.

Una de mis cajas de Linux terminó con permisos drwxrwxrwx en mi directorio $ HOME. Un cuadro de Arch Linux no iniciaría sesión con las claves públicas hasta que elimine el permiso 'w' para el grupo, otro en mi directorio $ HOME.

Intente hacer que $ HOME y $ HOME / .ssh / tengan permisos más restrictivos para grupos y otros. Vea si eso no deja que sshd haga sus cosas.

Se necesitan los siguientes permisos:

• La .sshcarpeta:700 (drwx------)
• La clave pública: 644 (-rw-r--r--)
• La clave privada: 600 (-rw-------)

Recientemente experimenté este problema también.

Se corrigió modificando los permisos del $HOMEdirectorio. Sin embargo, simplemente correr chmod g-w ~/no corrigió el problema. Además de chmod g-w ~/, también necesitaba modificar los permisos de othersen el $HOMEdirectorio ejecutandochmod o-wx ~/

Juntos:

chmod g-w ~/
chmod o-wx ~/

Tenga en cuenta que no estoy seguro de si o-xera necesario, simplemente lo ejecuté como medida de precaución.

Cambiar los permisos para la carpeta ~ / .ssh resolvió mi problema de acuerdo con esta publicación en Super User SE .

¿El problema se produce también en inicios de sesión paralelos, es decir, si intenta montar sshfs mientras tiene una sesión ssh abierta? Si no es así, ¿supongo que tiene su directorio de inicio cifrado? En este caso $HOME/.ssh/authorized_keys, solo sería utilizable en la máquina remota después de su primer inicio de sesión (utilizando su contraseña).

Consulte https://help.ubuntu.com/community/SSH/OpenSSH/Keys#Troubleshooting para obtener una explicación y la solución necesaria.

Publicaría esto como un comentario, pero probablemente sería demasiado largo. Solo quería agregar que ssh-copy-idintenta enviar la clave pública desde la /.sshubicación dentro de su $HOMEcarpeta.

Si está intentando sshrootear con una clave pública (guarde los comentarios relacionados con la seguridad), ssh-copy-idpodría estar intentando iniciar sesión con la clave pública incorrecta si su $HOMEvariable está configurada en otra cosa que no sea /root(como configurarse en el directorio de inicio de su usuario normal) ), por lo tanto, se le solicitará al usuario root porque la clave pública de root no está instalada en el sistema remoto.

Puede usar la siguiente línea para especificar la clave pública exacta:

pub="$(cat /root/.ssh/id_rsa.pub)"; ssh user@remotehost "echo $pub >> .ssh/authorized_keys; chmod 700 .ssh; chmod 600 .ssh/authorized_keys"

Encontré este escenario en la naturaleza varias veces (incluso esta mañana) y pensé que trataría de poner mis 2 centavos, en caso de que alguien se encontrara en la misma situación.

Al igual que otros colaboradores mencionados, este es probablemente un problema de permiso.

La mejor manera de diagnosticar esto es reiniciar el demonio SSH en el servidor remoto con la opción de depuración activada, generalmente la opción "-d". El mensaje del demonio OpenSSH es muy explícito. Por ejemplo, verá mensajes como:

Authentication refused: bad ownership or modes for directory /some/path

La razón por la que la clave pública no sobrevivió después del reinicio fue porque el directorio de inicio de mi servidor estaba encriptado. (hace esto mientras instala el servidor)

Otro posible problema es que el servidor no admite su algoritmo clave. En mi caso, encontré los siguientes mensajes en mis sshdregistros ( /var/log/auth.logen mi caso):

userauth_pubkey: unsupported public key algorithm: ssh-ed25519 [preauth]

Si ese es el caso, debe habilitar el soporte para ese algoritmo en su sshdconfiguración (que puede requerir una actualización a una sshdversión más reciente ) o debe cambiar su clave a un algoritmo compatible con el sshdque está intentando conectarse .

Como esta pregunta aparece entre los primeros resultados de búsqueda al buscar en Google este comportamiento, también agregaré mi solución:

En mi caso no fue nada relacionado con los permisos. Por cualquier razón (no me molesté en averiguar por qué razón en realidad, ya que encontré una solución rápida) al ejecutar el comando ssh, el programa no buscó el archivo de identidad correcto. Una solución fue agregar manualmente en el servidor remoto una clave SSH que el programa SSH intentó usar. Puede observar lo que hace el programa SSH cuando ejecuta el comando agregando -v al comando:

ssh -v username@your-host-ip-or-domain 

Luego simplemente toma en su máquina local cualquier clave pública para la cual el programa SSH intenta encontrar un archivo de identidad / clave privada para, en una Mac, por ejemplo:

cat ~/.ssh/id_rsa.pub

... y agréguelo al archivo autorizado de claves del control remoto en:

~/.ssh/authorized_keys

Otra, en mi caso, la mejor solución era agregar un host personalizado en mi archivo de configuración ssh local. En mi Mac es:

/Users/my-user-name/.ssh/config

Aquí puede agregar, por ejemplo, algo como esto:

Host mynewserver
        HostName some.IP.number.or.domain
        Port 20000 #if custom port is used and not the default 22
        User the_root
        PreferredAuthentications publickey
        IdentityFile ~/.ssh/id_rsa_for_my_new_server

Entonces solo necesitas ejecutar:

ssh mynewserver

...y voilá