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

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?

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 ~

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

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)

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í

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.

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

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

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.

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

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 

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

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

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.

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.

esto resuelve mi problema

ssh-agent bash

ssh-add

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

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

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.

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

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.

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

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

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

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

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

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.

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

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.

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.