Agregar una clave pública a ~ / .ssh / Authorized_keys no inicia sesión automáticamente


446

Agregué la clave SSH pública al archivo autorizado_claves . ssh localhostdebería iniciar sesión sin pedir la contraseña.

Lo hice e intenté escribir ssh localhost, pero aún así me pide que escriba la contraseña. ¿Hay otra configuración por la que tengo que pasar para que funcione?

He seguido las instrucciones para cambiar los permisos:

A continuación se muestra el resultado si lo hago ssh -v localhost.

debug1: Reading configuration data /home/john/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/john/.ssh/identity type 1
debug1: identity file /home/john/.ssh/id_rsa type -1
debug1: identity file /home/john/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7p1 Debian-8ubuntu3
debug1: match: OpenSSH_4.7p1 Debian-8ubuntu3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'localhost' is known and matches the RSA host key.
debug1: Found key in /home/john/.ssh/known_hosts:12
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/john/.ssh/identity
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>

Luego pide una fase de paso después del registro anterior. ¿Por qué no me inicia sesión sin contraseña?


55
Si bien no es el caso aquí, si vienes de Google y estás usando un directorio de inicio encriptado, sshd no podrá acceder a él y, por lo tanto, no podrás leer tu archivo de claves autorizadas. Aquí hay una solución: bugs.launchpad.net/ubuntu/+source/openssh/+bug/362427/comments/…
Daniel Schaffer

Respuestas:


1097

Debe verificar los permisos del authorized_keysarchivo y la carpeta / carpetas principales en las que se encuentra.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Para más información ver esta página .

También es posible que deba cambiar / verificar los permisos de su directorio de inicio para eliminar el acceso de escritura para el grupo y otros.

chmod go-w ~

66
Bueno, algo en lo anterior funcionó, aunque ¿no es "chmod -R go-wrx foobar" más bien dramático? ¿Por qué la necesidad de recursivo?
joachim

99
Para la segunda parte, no es necesario hacerlo recursivo, solo hacer lo chmod go-wrx foobarsuficiente es suficiente. Hacerlo de forma recursiva podría dañar seriamente algunas aplicaciones si tiene algún grupo u otro acceso a los archivos, especialmente si se trata de un directorio web.
StingeyB

24
Como se menciona en las preguntas frecuentes de OpenSSH, el directorio de inicio y .ssh del usuario solo necesita escribir el permiso eliminado para el grupo / otro (también lo chmod go-w $HOME $HOME/.sshhará). Por lo tanto, los permisos pueden ser tan 'abiertos' como 755 para ambos directorios, si así lo desea. Los comandos más simples / menos invasivos se encuentran en las preguntas frecuentes: openssh.org/faq.html#3.14
davidjb

3
¿Por qué no funcionaría para mí hasta que lo hice chmod 700 ~/.ssh && chmod 644 ~/.ssh/authorized_keys? 600 no funcionó donde 644 sí ...
ficuscr

3
También lo necesitaba sudo chown -R {$USER}:{$USER} ~/.ssh/porque había escrito el authorized_keysarchivo como root.
Zane Hooper el

155

SELinux también puede hacer que autor_keys no funcionen. Especialmente para root en CentOS 6 y 7. Sin embargo, no es necesario deshabilitarlo. Una vez que haya verificado que sus permisos son correctos, puede arreglar esto de la siguiente manera:

chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys
restorecon -R -v /root/.ssh

77
Esto restorecones lo que necesita después de haber copiado los archivos a mano, por ejemplo, a un nuevo disco duro. (Probablemente debería ejecutarlo en todos los archivos en este caso. Podría solucionar otros problemas extraños.)
ospalh

Otra campista feliz aquí. Este fue mi problema en RHEL 6.5
Antonio Ortells

2
9/10 veces, un problema de "por qué esto no funciona, siempre funciona" es un problema de selinux.
Andrew White

me arregló el problema en el servidor 1and1 (1und1)
musicman

104

configurar ssh certified_keys parece ser simple, pero esconde algunas trampas que estoy tratando de imaginar

- SERVIDOR -

en / etc / ssh / sshd_config configurado passwordAuthentication yespara permitir que el servidor acepte temporalmente la autenticación de contraseña

- CLIENTE -

considere Cygwin como emulación de Linux e instale y ejecute openssh

1. generar claves privadas y públicas (lado del cliente) # ssh-keygen

aquí presionando solo ENTER obtiene los archivos DEFAULT 2 " id_rsa " e " id_rsa.pub " en ~ / .ssh / pero si le da un nombre_para_la_clave, los archivos generados se guardan en su pwd

2. coloque your_key.pub en la máquina de destinossh-copy-id user_name@host_name

si no creó la clave predeterminada, este es el primer paso para salir mal ... debe usar

ssh-copy-id -i path/to/key_name.pub user_name@host_name

3. el registro ssh user_name@host_namesolo funcionará para id_rsa predeterminado, así que aquí hay una segunda trampa para la que necesitassh -i path/to/key_name user@host

(use la opción ssh -v ... para ver qué está pasando)

Si el servidor aún solicita la contraseña , le dio algo. a Introduzca la frase de contraseña: cuando se haya creado teclas (por lo que es normal)

si ssh no está escuchando, el puerto predeterminado 22 debe usar ssh -p port_nr

- SERVIDOR -----

4. modifique / etc / ssh / sshd_config para tener

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  %h/.ssh/authorized_keys

(sin comentarios si el caso)

Esto le dice a ssh que acepte autorizado_claves y busque en el directorio de inicio del usuario la picadura del nombre_clave escrita en el archivo .ssh / Authorized_keys

5 permisos establecidos en la máquina de destino

chmod 755 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

También apague la autenticación de pase

passwordAuthentication no

cerrar la puerta a todos los intentos de ssh root / admin /....@ your_domain

6 garantizar que la propiedad y la propiedad grupal de todos los directorios principales no root sean apropiadas.

chown -R ~ usernamehere
chgrp -R ~/.ssh/ user 

===============================================

7. considere el excelente http://www.fail2ban.org

8. TÚNEL ssh extra para acceder a un servidor MySQL (bind = 127.0.0.1)


55
¡Tenga en cuenta que "solo 4 seguridad" no es solo por seguridad! SSH ignorará el archivo si no tiene permisos restrictivos.
Navin

Asegurar la propiedad sería una gran adición a esta lista
steviejay

1
No tenía ni idea ssh-copy-id! Ese paso solo sería una gran respuesta.
James Marble

1
chmod 755 ~ / .ssh en lugar de 700 que veo en otro lugar parecía hacerlo
Jim W dice que reinstalar a Monica el

36

También asegúrese de que otros usuarios no puedan escribir su directorio personal

chmod g-w,o-w /home/USERNAME

La respuesta es robada desde aquí


44
Hacer chmod 700 ~/.ssh ; chmod 600 ~/.ssh/authorized_keys ; chmod g-w,o-w ~funcionó para mí. Gracias.
gbraad

1
¿Por qué no usar solo en su chmod og-w /home/USERNAMElugar?
Paramvir Singh Karwal

13

los desesperados también pueden asegurarse de que no tengan nuevas líneas adicionales en el archivo Author_keys debido a que copian el texto id_rsa.pub de un terminal confuso.


2
¡Esto es exactamente lo que me pasó! los dos terminales tienen el mismo ancho, por lo que es difícil de descifrar hasta que encendí los números de línea para ver dos líneas en el archivo autorizado_claves.
Shawn

1
Esta. Solo perdí una hora por esto. Y no es la primera vez. La respuesta de @ bortunac menciona la herramienta ssh-copy-id, que usaré en el futuro para evitar esto.
xdhmoore

Obtuve el contenido de id_rsa.pubusar en morelugar de cat, lo cual fue fatal debido a los saltos de línea invisibles.
Dan Halbert

8

usuario es tu nombre de usuario

mkdir -p /home/user/.ssh
ssh-keygen -t rsa
touch /home/user/.ssh/authorized_keys
touch /home/user/.ssh/known_hosts
chown -R user:user /home/user/.ssh
chmod 700 /home/user/.ssh
chmod 600 /home/user/.ssh/id*
chmod 644 /home/user/.ssh/id*.pub
chmod 644 /home/user/.ssh/authorized_keys
chmod 644 /home/user/.ssh/known_hosts

Mejor para root:mkdir -p /home/$USER/.ssh && chown -R $USER:$USER /home/$USER/.ssh && sudo -u $USER ssh-keygen -t rsa && touch /home/$USER/.ssh/authorized_keys && touch /home/$USER/.ssh/known_hosts && chmod 700 /home/$USER/.ssh && chmod 600 /home/$USER/.ssh/id* && chmod 644 /home/$USER/.ssh/id*.pub && chmod 644 /home/$USER/.ssh/authorized_keys && chmod 644 /home/$USER/.ssh/known_hosts && vim /home/$USER/.ssh/authorized_keys # paste keys here!
Odysseus

7

Tenga en cuenta que SELinux también puede desencadenar este error, incluso si todos los permisos parecen estar bien. Deshabilitarlo fue suficiente para mí (inserte las renuncias habituales sobre deshabilitarlo).


Puedes ver a SELinux interfiriendo /var/log/audit/audit.log. restorecon -R -v /root/.sshArreglado mi caso específico.
Dave Goodell

7

Es necesario enumerar una clave pública en .ssh / Authorized_keys , pero no es suficiente para que sshd (servidor) lo acepte. Si su clave privada está protegida con frase de contraseña, deberá darle a ssh (cliente) la frase de contraseña cada vez. O puede usar ssh-agent , o un equivalente de GNOME.

Su rastreo actualizado es consistente con una clave privada protegida con frase de contraseña. Ver ssh-agent, o usar ssh-keygen -p.


5

Comando de escritura:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Después de hacer esto, asegúrese de que su directorio sea así:

drwx------ 2 lab lab 4.0K Mar 13 08:33 .
drwx------ 8 lab lab 4.0K Mar 13 08:07 ..
-rw------- 1 lab lab  436 Mar 13 08:33 authorized_keys
-rw------- 1 lab lab 1.7K Mar 13 07:35 id_rsa
-rw-r--r-- 1 lab lab  413 Mar 13 07:35 id_rsa.pub

1
¿Cómo es tu respuesta diferente con la aceptada? ¿Lo has escrito 3 años después usando tu comando Ctrl + C Ctrl-V?
aguijón

5

Lo que finalmente hizo el truco para mí fue asegurarme de que el propietario / grupo no fuera root sino usuario:

chown -R ~/.ssh/ user
chgrp -R ~/.ssh/ user 

chown: usuario no válido: '/home/lsa/.ssh/'
Stepan Yakovenko

3

Prueba "ssh-add" que funcionó para mí.


3

Otro consejo para recordar. Desde v7.0 OpenSSH deshabilita las claves DSS / DSA ssh por defecto debido a su debilidad de herencia. Entonces, si tiene OpenSSH v7.0 +, asegúrese de que su clave no lo sea ssh-dss.

Si está atascado con las claves DSA, puede volver a habilitar el soporte localmente actualizando sus archivos sshd_configy ~/.ssh/configcon líneas como esta:PubkeyAcceptedKeyTypes=+ssh-dss


3

En mi caso, necesitaba poner mi authorized_keysarchivo .openssh.

Esta ubicación se especifica en /etc/ssh/sshd_configdebajo de la opción AuthorizedKeysFile %h/.ssh/authorized_keys.


Hay toda una clase de problemas que pueden ocurrir en el servidor (cuando se intenta conectar desde un cliente) que son imposibles de depurar sin acceso al servidor ... Esto es por diseño para ocultar información de clientes maliciosos, pero hace que sea más difícil depurar.
qneill

2

Asegúrese de que el usuario objetivo tenga establecida una contraseña. Corre passwd usernamepara establecer uno. Esto fue necesario para mí incluso si la contraseña de inicio de sesión SSH estaba deshabilitada.


2

esto resuelve mi problema

ssh-agent bash

ssh-add


Explica qué hace eso, por favor.
lyuboslav kanev

El agente ssh almacena sus claves ssh ... el comando bash inicia una nueva instancia de su shell. y ssh-add desbloquea tus llaves y las carga
Julian

2

Otro problema que debes tener en cuenta. Si su archivo generado no es predeterminado id_rsa y id_rsa.pub

Debe crear un archivo .ssh / config y definir manualmente qué archivo de identificación va a utilizar con la conexión.

El ejemplo está aquí:

host remote_host_name
hostname 172.xx.xx.xx
user my_user
IdentityFile /home/my_user/.ssh/my_user_custom.pub

2
El IdentityFile debería ser la clave privada
Ken H

@KenH sí claro. error tipográfico es. lo siento por eso.
Kunthar

1

Emití sudo chmod 700 ~/.sshy chmod 600 ~/.ssh/authorized_keysy chmod go-w $HOME $HOME/.sshdesde arriba y que fijo mi problema en un cuadro de CentOS7 que había ensuciado los permisos en al intentar obtener samba acciones de trabajo. Gracias


1

Parece un problema de permiso. Por lo general, sucede si el permiso de algún archivo / directorio no está configurado correctamente. En la mayoría de los casos son ~/.sshy ~/.ssh/*. En mi caso lo son /home/xxx.

Puede cambiar el nivel de registro de sshd modificando /etc/ssh/sshd_config(buscar LogLevel, establecerlo en DEBUG), luego verifique la salida /var/log/auth.logpara ver qué sucedió exactamente.


3
Esto parece sustancialmente idéntico a la respuesta aceptada y probablemente debería haber sido un comentario al respecto, no una respuesta. Con un poco más de representación, podrás publicar comentarios . Hasta entonces, no utilice las respuestas como solución alternativa.
Nathan Tuggy

Lo siento, pensé que era la forma de resolver todo tipo de preguntas. Ahora sé cómo hacerlo ahora, gracias.
Joey

1

Mi problema era un AuthorizedKeysFile modificado, cuando aún no se había ejecutado la automatización para rellenar / etc / ssh / certified_keys.

$sudo grep AuthorizedKeysFile /etc/ssh/sshd_config
#AuthorizedKeysFile .ssh/authorized_keys
AuthorizedKeysFile  /etc/ssh/authorized_keys/%u

1

Solo mire en /var/log/auth.log en el servidor . Establecer verbosidad adicional con -vv en el lado del cliente no ayudará, porque es poco probable que el servidor ofrezca demasiada información a un posible atacante.


1

Asegúrese de haber copiado toda la clave pública en authorized_keys; El ssh rsaprefijo es necesario para que la clave funcione.


2
ssh-copy-id usado
vishnu

1

necesita verificar las propiedades de los archivos. para asignar el uso de propiedad requerido:

$ chmod 600 ~/.ssh/sshKey
$ chmod 644 ~/.ssh/sshKey.pub

1

Mire en /var/log/auth.logel servidor los sshderrores de autenticación.

Si todo lo demás falla, ejecute el sshdservidor en modo de depuración:

sudo /usr/sbin/sshd -ddd -p 2200

Luego, conéctese desde el cliente:

ssh user@host -p 2200

En mi caso encontré la sección de error al final:

    debug1: userauth_pubkey: test whether pkalg/pkblob are acceptable for RSA SHA256:6bL+waAtghY5BOaY9i+pIX9wHJHvY4r/mOh2YaL9RvQ [preauth]
==> debug2: userauth_pubkey: disabled because of invalid user [preauth]
    debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa [preauth]
    debug3: userauth_finish: failure partial=0 next methods="publickey,password" [preauth]
    debug3: send packet: type 51 [preauth]
    debug3: receive packet: type 50 [preauth]

Con esta información, me di cuenta de que sshd_configestaba restringiendo los inicios de sesión a los miembros del sshgrupo. El siguiente comando corrigió este error de permiso:

sudo usermod -a -G ssh NEW_USER

0

en esa nota, asegúrese de que sshd config tiene -;

PermitRootLogin without-password

establecer como lo anterior, luego reiniciar sshd (/etc/init.d/sshd restart)

¡cierre sesión e intente iniciar sesión nuevamente!

por defecto creo que es -;

PermitRootLogin no

0

En mi caso es porque el grupo de usuarios no está configurado en AllowGroups del archivo de configuración / etc / ssh / sshd_config. Después de agregarlo todo funciona bien.


0

Tengo el directorio de inicio en una ubicación no estándar y en los sshdregistros tengo esta línea:

Could not open authorized keys '/data/home/user1/.ssh/authorized_keys': Permission denied

incluso si todos los permisos estuvieran bien (ver las otras respuestas).

He encontrado una solución aquí: http://arstechnica.com/civis/viewtopic.php?p=25813191&sid=0876f069ec2aa5fdcd691a2e2e7242c2#p25813191

En mi caso particular:

  • agregó una nueva línea en /etc/selinux/targeted/contexts/files/file_contexts.homedirs:

    • Esta es la línea original para los directorios principales regulares:

      /home/[^/]*/\.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0

    • Esta es mi nueva línea:

      /data/home/[^/]*/\.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0

  • seguido de una restorecon -r /data/y un sshdreinicio


0

Tuve este problema y ninguna de las otras respuestas lo resolvió, aunque, por supuesto, las otras respuestas son correctas.

En mi caso, resultó que el /rootdirectorio en sí (no por ejemplo /root/.ssh) tenía los permisos incorrectos. Lo necesitaba:

chown root.root /root
chmod 700 /root

Por supuesto, esos permisos deberían ser algo así (tal vez chmod 770) independientemente. Sin embargo, es impedido en concreto sshdde trabajo, a pesar de que /root/.sshy /root/.ssh/authorized_keysambos tenían permisos y propietarios correctos.


0

Tuve este problema cuando agregué el grupo del usuario de inicio de sesión a otro usuario. Digamos que hay un usuario ssh-login llamado userA y un usuario no ssh-login userB. userA también tiene el grupo userA. Modifiqué userB para tener el grupo userA también. Esto condujo al comportamiento descrito, de modo que el usuario A no pudo iniciar sesión sin una solicitud. Después de eliminar el grupo usuario A del usuario B, el inicio de sesión sin solicitud funcionó nuevamente.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.