Permiso SSH denegado (clave pública)

110

Estoy tratando de conectarme a un Linode (ejecutando Ubuntu 12.04 LTS) desde mi máquina local (también ejecutando Ubuntu 12.04 LTS)

Creé una clave pública y privada en mi máquina local y copié mi clave pública en el archivo autorizado de claves de mi Linode. Sin embargo, cada vez que intento ssh a mi Linode recibo el mensaje de error Permission denied (publickey).

No es un problema con cómo se configura ssh en mi Linode porque puedo hacerlo desde mi máquina Windows utilizando la autenticación de clave.

En mi .sshdirectorio en mi máquina local Ubuntu, tengo mis id_rsay id_rsa.pubarchivos. ¿Debo crear un archivo de claves autorizadas en mi máquina local?

EDITAR: Esto es lo que obtengo cuando corro ssh -vvv -i id_rsa [youruser]@[yourLinode]:

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).
Pattle
fuente
44
1) ¿Qué dicen los registros en el servidor SSH sobre el tiempo que tiene este error en el cliente? ( /var/log/auth.log) 2) ¿Cómo transfirió la clave pública al servidor? Siempre use ssh-copy-idpara estar seguro acerca de los permisos. Su directorio de inicio, el .sshdirectorio y el authorized_keysarchivo tienen requisitos de permiso estrictos. (vea la página de manual de sshd(8) en ~/.ssh/authorized_keys). 3) ¿Generaste un nuevo par de claves en Ubuntu? En caso de que haya reutilizado la clave de Windows, primero deberá convertirla al formato OpenSSH.
gertvdijk
1
El comando debería haber sido ssh -vvv -i .ssh/id_rsa ....(¡tenga en cuenta la ruta de acceso a id_rsa!) - reemplace - el registro anterior solo muestra que "nosotros" no teníamos pubKey para enviar.
guntbert
@guntbert Me perdí el .ssh porque ya estaba en el directorio .ssh. También lo intenté con .ssh / id_rsa pero obtuve el mismo resultado
Pattle el
Ya veo, así que leí mal. Responda las preguntas de @gertvdijk.
guntbert
¿Alguien puede comentar en stackoverflow.com/questions/51254328/unable-to-ssh-to-bitbucket Tengo un problema similar.
Mrinmay Kalita

Respuestas:

90

PubKeyAuthentication

Configura tu cliente

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

Su archivo de configuración del paso 2 debe tener algo similar a lo siguiente:

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

Puede agregar IdentitiesOnly yespara asegurarse de que sshutiliza los IdentityFilearchivos de claves y ningún otro durante la autenticación, lo que puede causar problemas y no es una buena práctica.

Solución de problemas

  1. use la opción "-vvv"
  2. Asegúrese de que el servidor tenga su clave PÚBLICA (.pub).
  3. Asegúrese de que su IdentiyFile apunte a su clave PRIVADA.
  4. Asegúrese de que su directorio .ssh tenga 700 y sus archivos tengan 700 permisos (rwx ------).
  5. tail -f /var/log/auth.log (en el servidor) y controle los errores cuando intente iniciar sesión
  6. Si tiene muchos archivos de clave, intente IdentitiesOnly yeslimitar la autenticación para usar la clave única especificada.
earthmeLon
fuente
1
Para su información, creé un pequeño script en github.com/centic9/generate-and-send-ssh-key que ejecuta los pasos necesarios de una vez y, además, garantiza todos los permisos de archivo / directorio que siempre me causaron dolores de cabeza ...
centic
1
Solo para elaborar el paso 2: la IdentityFilelínea en ~ / .ssh / config debe apuntar a la clave PRIVADA.
Danny Schoemann
De hecho .
earthmeLon
3
Me pregunto por qué querrías configurar los archivos para que tengan permiso de ejecución en el paso 4.
Todd Walton
También es muy importante tener permisos correctos por usuario (use chown y chmod), de lo contrario, se le denegará una autenticación incluso si su servidor tiene su clave pública.
joseluisq
61

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

En su directorio de inicio:

chown -R your_user:your_user .ssh

En cuanto a los derechos, vaya con 700 para .sshy 600 paraauthorized_keys

chmod 700 .ssh
chmod 600 .ssh/authorized_keys
Buzut
fuente
1
Esta respuesta me ayudó. Tomé el consejo de esta publicación y moví mi authorized_keysarchivo fuera de mi directorio de inicio encriptado. Al hacerlo, sin querer cambié de dueño a root:root.
Jordan Grant
Ojalá pudiera votar dos veces, una para la carpeta y otra para el archivo. Muy importante que los permisos sean exactos.
Sr. Griever
Sí, fueron los permisos todo el tiempo.
a3y3
Este resolvió mi problema, gracias por eso.
sathiyarajan
14

No necesitas authorized_keysen tu cliente.

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

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

Guntbert
fuente
Gracias por su ayuda, he editado mi respuesta para mostrar lo que sucede cuando escribo lo que sugirió.
Pattle
2
para transferir una clave, en el cliente, use ssh-copy-id
Panther
@ bodhi.zazen Gracias, pero ya he transferido la clave, ese no es el problema
Pattle
44
"Debe decirle al cliente ssh que realmente use la clave que generó". No, por defecto buscará la clave en la ruta predeterminada, por ejemplo ~/.ssh/id_rsa. Además, por lo que puedo ver, el uso de un agente clave es completamente opcional y no está relacionado con el problema.
gertvdijk
@gertvdijk, está haciendo suposiciones aquí que aún no están respaldadas por hechos; no sabemos qué sucedió en el sistema.
guntbert
10

También verifique el valor de PasswordAuthenticationin /etc/ssh/sshd_configy si es, nocámbielo a yes. No olvide reiniciar el servicio ssh después de eso.

iman
fuente
44
El OP no está intentando usar la autenticación de contraseña. Tienen algún sentido y están usando clave pública / privada.
ctrl-alt-delor
9

El problema que tuve fue que estaba usando las claves incorrectas en el cliente. Cambié el nombre de id_rsa e id_rsa.pub a otra cosa. Puede cambiarles el nombre a sus valores predeterminados, o cuando emita el comando ssh, úselo de esta manera

ssh -i ~/.ssh/private_key username@host
Todd
fuente
1
no, usar la clave pública
St3an
@ St3an pones la clave pública en el servidor, pero cuando te conectas como Todd está aquí arriba, usas tu clave privada
Nathan F.
@NathanFiscaletti nunca debes exponer tu clave privada, por eso es privada. La clave privada es utilizada por su agente ssh local para verificar que realmente proporcione una clave pública que corresponda a su clave privada. Los agentes de SSH entre máquinas pueden garantizar que los usuarios son quienes pretenden ser :-)
St3an
1
Exactamente. Es por eso que cuando se conecta, proporciona su clave privada al cliente ssh. El servidor almacena su clave pública. El comando en la publicación anterior es exactamente cómo se supone que se deben usar las claves privadas.
Nathan F.
7

También asegúrese de que el directorio de inicio del usuario (en el servidor) realmente pertenezca al usuario ssh'ing into (estaba configurado en root: root en mi caso).

Debería haber sido:

sudo chown username:username /home/username;
besuquearse
fuente
Puedo ssh con claves públicas / privadas con un usuario en mi cuadro de Linux local (por ejemplo, abc), diferente del usuario en el servidor remoto (por ejemplo, [email protected]). Solo tenía que asegurarme de que el usuario local poseía los archivos .ssh locales (por ejemplo, abc: abc, no root: abc) `
Michael
Esto funcionó en mi caso
Zerquix18
3

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

Normalmente mantengo una lista de claves autorizadas en todos mis servidores ~/.ssh/authorized_keys2. Desde mi experiencia, sshdbuscará ~/.ssh/authorized_keyso ~/.ssh/authorized_keys2por defecto.

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

AuthorizedKeysFile    %h/.ssh/authorized_keys

en lugar de

AuthorizedKeysFile    %h/.ssh/authorized_keys2

Apliqué este último, reinicié mi demonio ssh y resolví mi problema al iniciar sesión con ssh usando mi clave pública.

Justin C
fuente
¡Muchas gracias, esto me ayudó a descubrir que esta línea estaba completamente comentada fuera de la configuración!
Christian.D
2

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

AllowUsers user1 user2 user3
cmbind55
fuente
1

Si todo lo demás falla, verifique que su usuario de inicio de sesión pertenezca al Grupo Permitido de ssh. Es decir, sus usuarios son miembros del grupo que se muestra en la siguiente línea en /etc/ssh/sshd_configel servidor:

AllowGroups ssh #Here only users of 'ssh' group can login
biocyberman
fuente
1

En mi caso, el cliente es ubuntu 14.04lts, el servidor ganó el servidor 2012 con cygwin. Estaba usando 'ssh administrador @ xxxx', cuando el directorio del servidor 2012 en cygwin era / home / Administrator. Por lo tanto, era sensible a mayúsculas y minúsculas, cuando intenté 'ssh Administrator @ xxxx' (tenga en cuenta la A mayúscula en el Administrador), 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 (clave pública, teclado interactivo)'.

Kent
fuente
Alguien debería registrar un problema con el proyecto ssh sugiriendo eso. Me encontré con un problema similar.
Ben Creasy
1

Tuve el mismo problema al copiar la clave pública de un usuario normal (por ejemplo, johndoe) desde un sistema cPanel Centos a un servidor Ubuntu en AWS. Como sugirió gertvdijk arriba, lo verifiqué /var/log/auth.logy , efectivamente , lo dijo Authentication refused: bad ownership or modes for directory /home/johndoe. Resulta que me había equivocado 777 ' /home/johndoecuando intenté establecer /home/johndoe/public_htmlcomo la raíz de documentos virtualhost predeterminada para apache2 (eso tampoco es necesario para esa tarea).

Vea también las respuestas aquí y aquí.

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

sitio80443
fuente
1

Para aquellos usuarios de Putty como yo que vinieron a este hilo, también puede recibir este error si olvidó agregar el usuario usuario @ Ip.

Otros tienen permiso en el archivo de clave chmod a 600)

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

ssh [email protected] -i /path/to/.pem file 
Alex Punnen
fuente
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-deny

sudo nano /etc/ssh/sshd_config

Reemplace esto

UsePAM yes
IgnoreUserKnownHosts no
PasswordAuthentication no

Con este

UsePAM no
IgnoreUserKnownHosts no
PasswordAuthentication yes

Guarde el archivo y reinicie ssh

reload ssh

ssh debería funcionar ahora pidiendo una contraseña

mau
fuente
1

Tuve el mismo problema que se describe en la pregunta. El resultado de la ejecución ssh -vvv -i id_rsa [youruser]@[yourLinode]en la máquina del cliente fue similar al descrito en la pregunta. Verifiqué 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.puben la máquina del servidor, como archivo ~username/.ssh/authorized_keys, había omitido accidentalmente la palabra ssh-rsadesde el principio. Agregarlo resolvió el problema.

Teemu Leisti
fuente
1

Funciona en Ubuntu 16.04 también.

El problema está dentro del sshd_configarchivo

Aquí está la solución ULTIMATE:

Inicie sesión como root en su servidor Ubuntu

vi /etc/ssh/sshd_config

Ahora vaya al final y cambie el valor de "no" a "sí".

Debe tener un aspecto como este:

Cambie a no para deshabilitar las contraseñas de texto sin cifrado

PasswordAuthentication yes
service sshd reload

para tomar efecto.

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

Entonces 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 john con su nombre de usuario).

deberías ir a ir

Galápagos
fuente
1

Algunas personas que se preguntan pueden haber configurado el acceso ssh para que sea clave solo en la cuenta raíz y luego crearon un nuevo usuario y no se dieron cuenta de que necesitan

ssh root@your-ip-address

rsync --archive --chown=[user]:[user] ~/.ssh /home/[user]

logout

Vuelva a intentarlo. Reemplace [usuario] con su nueva cuenta de usuario.

Esto es común al configurar un nuevo servidor en DigitalOcean cuando ha utilizado las teclas ssh en la configuración.

https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-18-04

LpLrich
fuente
0

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

Glutanimato
fuente
0

El siguiente método podría funcionar si puede acceder a la máquina A y la máquina B de forma independiente (por ejemplo, desde la máquina C).

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

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

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

En la máquina A , ejecutecat ~/.ssh/id_rsa.pub

Salida de muestra:

ssh-rsa AAAAB3NzaSGMFZW7yB anask@mahineA

Copie la clave impresa ( ⌘ Command+ Co CRTL+ C) y luego agréguela al archivo ~ / .ssh / Authorized_keys en la máquinaB .

Por ejemplo, ejecute lo siguiente en machineB :

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

anask
fuente