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).

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.

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

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)

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.

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

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;

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.

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

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

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)'.

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)

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 user@1.1.1.1 -i /path/to/.pem file 

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

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.

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

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

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í.

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