it-swarm-es.tech

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

He estado utilizando la autenticación de clave pública en un servidor remoto durante algún tiempo para el uso remoto de Shell, así como para los 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?

29
Aliud Alius

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.

32
Bruce Ediger

Se necesitan los siguientes permisos:

  • La carpeta .ssh: 700 (drwx------)
  • La clave pública: 644 (-rw-r--r--)
  • La clave privada: 600 (-rw-------)
8
Sagar Naik

Recientemente experimenté este problema también.

Se corrigió modificando los permisos de la $HOME directorio. Sin embargo, simplemente ejecutando chmod g-w ~/ no corrigió el problema. Además de chmod g-w ~/ También necesitaba modificar los permisos de others en el $HOME directorio ejecutando chmod o-wx ~/

Juntos:

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

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

5
izzy.artistic

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

1
Dogukan

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 motivo (no me molesté en averiguar por qué motivo 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 [email protected] 

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 remote_keys 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á

0
Schurik

¿El problema ocurre 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).

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

0
fheub

En mi caso en el servidor remoto el siguiente archivo:

/etc/ssh/sshd_config

tenía la siguiente propiedad establecida en no:

PubkeyAuthentication no

comentando con un hash:

#PubkeyAuthentication no

hizo la mitad del truco, el resto fue reiniciar el servicio ssh:

/etc/init.d/sshd restart

Fuente: después de ssh-copy-id, aún necesita proporcionar contraseña

0
shabby

La razón por la cual 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)

0
dinbo

Publicaría esto como un comentario, pero probablemente sería demasiado largo. Solo quería agregar que ssh-copy-id Intenta enviar la clave pública desde la ubicación /.ssh Dentro de su carpeta $HOME.

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

Puede usar el siguiente one-liner para especificar la clave pública exacta:

pub="$(cat /root/.ssh/id_rsa.pub)"; ssh [email protected] "echo $pub >> .ssh/authorized_keys; chmod 700 .ssh; chmod 600 .ssh/authorized_keys"

Me he encontrado con este escenario en la naturaleza varias veces (incluida 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.

0
rubynorails

Al igual que otros contribuyentes 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
0
gerard lapeche

Otro posible problema es que el servidor no admite su algoritmo clave. En mi caso, encontré los siguientes mensajes en mis registros de sshd (/var/log/auth.log en 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 configuración sshd (que puede requerir una actualización a una versión más reciente sshd) o debe cambiar su clave a un algoritmo compatible con el sshd al que está intentando conectarse.

0
Florian Brucker