SSH Permiso denegado (publickey)

74

He intentado buscar preguntas anteriores para obtener respuestas a mi pregunta, pero todas las respuestas que se sugirieron anteriormente no me han funcionado.

Estoy intentando conectarme a un linode (ejecutando Ubuntu 12.04 LTS) desde mi máquina local (también ejecutando ubnutu 12.04 LTS)

Creé una clave privada y pública en mi equipo local y copié mi clave pública en el archivo authorized_keys de mi linode. Sin embargo, cada vez que intento enviar un ssh a mi linode aparece el mensaje de error "Permiso denegado (publickey).

No es un problema con la configuración de ssh en mi linode porque puedo enviarlo desde mi máquina con Windows mediante autenticación de clave.

En mi directorio .ssh en mi máquina ubuntu local tengo mis archivos id_rsa e id_rsa.pub. ¿Debo crear un archivo authorized_keys en mi máquina local?

EDITAR: Esto es lo que obtengo cuando ejecuto ssh -vvv -i id_rsa [usuario] @ [suLinode]

debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).
    
pregunta Pattle 22.06.2013 - 23:20

17 respuestas

66

PubKeyAuthentication

Configure su cliente

  1. Genera tu clave
    • ssh-keygen
  2. Configure ssh para usar la clave
    • vim ~/.ssh/config
  3. Copie su clave en su servidor
    • ssh-copy-id -i /path/to/key.pub SERVERNAME

Su archivo de configuración de paso 2 debería tener algo similar a lo siguiente:

Host SERVERNAME
Hostname ip-or-domain-of-server
User USERNAME
PubKeyAuthentication yes
IdentityFile ./path/to/key

Solución de problemas

  1. use la opción "-vvv"
  2. Asegúrese de que el servidor tenga su clave PUBLIC (.pub).
  3. Asegúrese de que su IdentiyFile apunte a su clave PRIVADA.
  4. Asegúrese de que su directorio .ssh tenga 700 y que sus archivos tengan 700 permisos (rwx ------).
  5. tail -f /var/log/auth.log (en el servidor) y supervisa los errores cuando intentas iniciar sesión
respondido por el earthmeLon 23.06.2013 - 23:04
39

A veces, el problema proviene de los permisos y la propiedad. Por ejemplo, si desea iniciar sesión como root, /root , .ssh y authorized_keys deben pertenecer a la raíz. De lo contrario, sshd no podrá leerlos y, por lo tanto, no podrá decir si el usuario está autorizado para iniciar sesión.

En su directorio de inicio:

chown -R your_user:your_user .ssh

En cuanto a derechos, vaya con 700 para .ssh y 600 para authorized_keys

chmod 700 .ssh
chmod 600 .ssh/authorized_keys
    
respondido por el Buzut 15.03.2016 - 12:50
12

No necesita authorized_keys en su cliente.

Debe decirle al ssh-client que realmente use la clave que generó. Hay varias maneras de hacer eso. Solo para probar tipo ssh -vvv -i .ssh/id_rsa [youruser]@[yourLinode] . Tendrá que proporcionar su frase de contraseña cada vez que quiera conectarse al servidor.

Si eso funcionó, puede agregar la clave al ssh-agent con ssh-add .ssh/id_rsa (deberá proporcionar la frase de contraseña solo una vez para esto y deberá funcionar siempre que no cierre la sesión / reinicie)

    
respondido por el guntbert 22.06.2013 - 23:42
7

También asegúrese de que el directorio de inicio del usuario (en el servidor) en realidad pertenece al usuario ssh'ing into (se estableció en root: root en mi caso).

Debería haber sido:

sudo chown username:username /home/username;
    
respondido por el canoodle 20.04.2015 - 21:07
6

También verifica el valor de PasswordAuthentication en /etc/ssh/sshd_config y si es no cámbialo a yes . No olvide reiniciar el servicio ssh después de eso.

    
respondido por el iman 09.02.2017 - 11:11
5

El problema que tuve fue que estaba usando las teclas incorrectas en el cliente. Había cambiado el nombre de id_rsa y id_rsa.pub a otra cosa. Puede cambiarles el nombre a sus valores predeterminados, o cuando emita el comando ssh, utilícelo de esta manera

ssh -i ~/.ssh/private_key username@host
    
respondido por el Todd 04.02.2017 - 23:28
2

Me encontré con este problema recientemente con mi servidor web.

Normalmente guardo una lista de claves autorizadas en todos mis servidores en ~/.ssh/authorized_keys2 . Según mi experiencia, sshd buscará ~/.ssh/authorized_keys o ~/.ssh/authorized_keys2 de forma predeterminada.

En el caso de mi servidor web, el /etc/ssh/sshd_config tenía esta línea

AuthorizedKeysFile    %h/.ssh/authorized_keys

en lugar de

AuthorizedKeysFile    %h/.ssh/authorized_keys2

Apliqué el último, reinicié mi ssh daemon y resolví el problema al iniciar sesión con ssh usando my pubkey.

    
respondido por el Justin C 24.11.2013 - 06:55
1

En mi caso, el cliente es ubuntu 14.04lts, el servidor fue win 2012 servidor ejecutando cygwin. Estaba usando 'ssh administrator@x.x.x.x', cuando el directorio de servidores de 2012 en cygwin era / home / Administrator. Por lo tanto, era sensible a las mayúsculas y minúsculas cuando probé 'ssh Administrator@x.x.x.x' (observe el capital A en Administrator) y funcionó bien.

Un mensaje de error como "usuario no encontrado" me habría llevado a la solución mucho más rápido que "Permiso denegado (publickey, keyboard-interactive)".

    
respondido por el Kent 12.07.2016 - 04:41
1

Tuve el mismo problema al copiar la clave pública de un usuario común (por ejemplo, johndoe) de un sistema cPanel Centos a un servidor Ubuntu en AWS. Tal como lo sugirió gertvdijk anterior, verifiqué /var/log/auth.log y, por supuesto, dijo Authentication refused: bad ownership or modes for directory /home/johndoe Resulta que había equivocado 777'ed /home/johndoe cuando intentaba establecer /home/johndoe/public_html como la raíz de documentos virtualhost predeterminada para apache2 (eso tampoco es necesario para esa tarea).

Ver también las respuestas aquí y here

El servidor solo necesita tener la clave pública en .ssh/authorized_keys y el cliente (la computadora en la que está trabajando) debe tener la clave privada (.pem, o si usa SFTP con Filezilla, .ppk)

    
respondido por el site80443 07.01.2017 - 22:54
1

Para aquellos usuarios de Putty como yo que vinieron a este hilo, también pueden obtener este error si olvidaron agregar el usuario @ Ip!

Otros son permisos en archivo de clave chmod a 600)

ssh 1.1.1.1 -i /path/to/.pem file 
Permission denied (publickey).'

ssh user@1.1.1.1 -i /path/to/.pem file 
    
respondido por el Alex Punnen 28.03.2017 - 13:06
1

Esto es lo que funcionó para mí, la solución no es mía, pero preferiría escribirla aquí en caso de que alguien más tenga el mismo problema.

El autor original lo publicó aquí: digital-ocean -public-access-key-denied

sudo nano /etc/ssh/sshd_config

Reemplazar esto

UsePAM yes
IgnoreUserKnownHosts no
PasswordAuthentication no

Con esto

UsePAM no
IgnoreUserKnownHosts no
PasswordAuthentication yes

Guarde el archivo y reinicie ssh

reload ssh

ssh debería funcionar ahora pidiendo una contraseña

    
respondido por el mau 08.04.2017 - 03:25
1

Tuve el mismo problema que el descrito en la pregunta. El resultado de ejecutar ssh -vvv -i id_rsa [youruser]@[yourLinode] en la máquina cliente fue similar al descrito en la pregunta. Comprobé todos los permisos de archivos y directorios como se aconseja en las otras respuestas, y fueron correctos.

Resultó que al copiar el archivo generado id_rsa.pub en la máquina servidor, como archivo ~username/.ssh/authorized_keys , había omitido accidentalmente la palabra ssh-rsa desde el inicio. Agregándolo resuelto el problema.

    
respondido por el Teemu Leisti 16.05.2017 - 11:41
0

Si todo lo demás falla, compruebe que su usuario de inicio de sesión pertenece al AllowedGroup de ssh. Es decir, sus usuarios son miembros del grupo que se muestra en la siguiente línea en /etc/ssh/sshd_config en el servidor:

AllowGroups ssh #Here only users of 'ssh' group can login
    
respondido por el biocyberman 17.10.2014 - 08:21
0

Otra posible causa podría ser la configuración AllowedUsers en /etc/ssh/sshd_conf . NOTA: la lista está espacio delimitada (no delimitada por comas) como aprendí por las malas.

AllowUsers user1 user2 user3
    
respondido por el cmbind55 03.09.2015 - 19:07
0

En mi caso, el problema fue causado por copiar sobre un directorio .ssh de una máquina más antigua. Resulta que mi configuración anterior de SSH estaba usando claves DSA que desde entonces han estado en desuso . El cambio a un nuevo par de claves, esta vez basado en RSA, resolvió el problema para mí.

    
respondido por el Glutanimate 01.10.2017 - 22:16
0

El siguiente método podría funcionar si puede acceder a machineA y machineB de forma independiente (por ejemplo, desde machineC).

Si ssh-copy-id no funciona, la autenticación de contraseña podría estar deshabilitada. La siguiente es una solución temporal .

Tener la clave pública de machineA en las teclas autorizadas de machineB (es decir, ~ / .ssh / authorized_keys) le permitirá enviar ssh desde machineA. Esto también se aplica a scp.

Después de generar los pares de claves usando: ssh-keygen

En machineA , ejecute cat ~/.ssh/id_rsa.pub

Salida de muestra:

  

ssh-rsa AAAAB3NzaSGMFZW7yB anask@mahineA

Copie la clave impresa ( ⌘ Comando + C , o CRTL + C y luego agréguelo a el archivo ~ / .ssh / authorized_keys en machineB .

Por ejemplo, ejecute lo siguiente en machineB :

  

echo 'ssh-rsa AAAAB3NzaSGMFZW7yB anask@mahineA' >> ~/.ssh/authorized_keys

    
respondido por el anask 25.03.2018 - 07:11
0

Funciona en Ubuntu 16.04 también.

El problema está dentro del archivo sshd_config

Aquí está la solución ULTIMATE:

Inicie sesión como root en su servidor de Ubuntu

vi /etc/ssh/sshd_config

Ahora vaya a la parte inferior y cambie el valor de "no" a "sí".

Debería verse así:

Cambie a no para deshabilitar las contraseñas de texto claro tunelizadas

PasswordAuthentication yes
service sshd reload

para que tenga efecto.

Ahora puede simplemente usar una tecla usando el comando siguiente de su máquina LOCAL (también conocida como computadora portátil, etc.)

Así que abra una nueva ventana de terminal y NO inicie sesión en el servidor, simplemente ponga este comando:

ssh-copy-id john @ serverIPAddress

(reemplace a Juan con su nombre de usuario).

deberías ir para ir

    
respondido por el Galapagos 18.07.2018 - 22:22

Lea otras preguntas en las etiquetas