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

llaves privadas ssh (27)

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

Agregué la clave ssh pública al archivo authorized_keys. ssh localhost debería iniciar sesión sin pedir la contraseña.

Hice eso e intenté escribir ssh localhost , pero aún así me pide que escriba la contraseña. ¿Hay algún otro ajuste por el que deba pasar para que funcione?

He seguido las instrucciones para cambiar los permisos:

A continuación se muestra el resultado si 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 la contraseña después del registro anterior. ¿Por qué no se está iniciando sesión sin una contraseña?

Asegúrese de que el usuario de destino tiene una contraseña establecida. Ejecute el passwd username de passwd username para establecer uno. Esto era necesario para mí, incluso si la contraseña de inicio de sesión SSH estaba deshabilitada.

Comando de escritura

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

Después de hacer esto, asegúrate de que tu 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

Consulte /var/log/auth.log en el servidor para ver los errores de autenticación sshd .

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

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

Luego conecte 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 mi sshd_config estaba restringiendo los inicios de sesión a los miembros del grupo ssh . El siguiente comando corrigió este error de permiso:

sudo usermod -a -G ssh NEW_USER

Debe verificar los permisos del archivo authorized_keys y las carpetas / carpetas principales en las que se encuentra.

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

Para más información vea 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 ~

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

En mi caso, necesitaba colocar mi archivo .openssh en .openssh .

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

Es necesario verificar las propiedades de los archivos. Para asignar el uso de la propiedad requerida:

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

Listar una clave pública en .ssh / authorized_keys es necesario pero no 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 puedes usar ssh-agent, o un gnome equivalente.

La traza de su ACTUALIZACIÓN es consistente con una clave privada protegida por frase de contraseña. Consulte ssh-agent, o ssh-keygen -p.

Lo que me sirvió de truco finalmente fue asegurarse de que el propietario / grupo no fuera root sino usuario:

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

Mi problema fue un AuthorizedKeysFile modificado, cuando aún no se había ejecutado la automatización para completar / etc / ssh / authorized_keys.

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

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

Si está atascado con las claves DSA, puede volver a habilitar el soporte local actualizando sus archivos sshd_config y ~/.ssh/config con líneas como las siguientes: PubkeyAcceptedKeyTypes=+ssh-dss

Otro tema que hay que tener cuidado. Si su archivo generado no es por defecto id_rsa e id_rsa.pub

Debe crear el archivo .ssh / config y definir manualmente el archivo de identificación que 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

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 ~/.ssh y ~/.ssh/* . En mi caso son /home/xxx .

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

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

SELinux también puede hacer que authorized_keys no funcione. 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 corregir esto así:

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

Simplemente busque en /var/log/auth.log en el servidor . La configuración de verbosidad adicional con -vv en el lado del cliente no ayudará, ya que es poco probable que el servidor ofrezca demasiada información a un posible atacante.

También asegúrese de que su directorio de inicio no sea escribible por otros

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

La respuesta es robada desde here

Tenga en cuenta que SELinux puede provocar este error también, incluso si todos los permisos parecen estar bien. Deshabilitarlo hizo el truco por mí (inserte los descargos de responsabilidad habituales sobre deshabilitarlo).

Tengo el directorio principal en una ubicación no estándar y en los registros sshd 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:

Se agregó una nueva línea en /etc/selinux/targeted/contexts/files/file_contexts.homedirs :
- Esta es la línea original para los directorios de inicio regulares:
  /home/[^/]*//.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0
- esta es mi nueva linea
  /data/home/[^/]*//.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0
seguido de un restorecon -r /data/ y un reinicio sshd

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 directorio /root 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í (independientemente del chmod 770 ) independientemente. Sin embargo, específicamente evitó que sshd funcionara, a pesar de que /root/.ssh y /root/.ssh/authorized_keys tenían permisos y propietarios correctos.

configurar ssh authorized_keys parece ser simple pero oculta algunas trampas que estoy tratando de entender

- SERVIDOR -

en / etc / ssh / sshd_config configure passwordAuthentication yes para 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í, al presionar ENTER solo se obtienen DEFAULT 2 archivos " id_rsa " e " id_rsa.pub " en ~ / .ssh / pero si le asigna un name_for_the_key los archivos generados se guardan en su pwd

2. Coloque el archivo your_key.pub en la máquina ssh-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 de ssh user_name@host_name funcionará solo para id_rsa predeterminado, por lo que aquí está la segunda trampa, ya que necesita ssh -i path/to/key_name user@host

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

Si el servidor todavía pide la contraseña , le dio un smth. para ingresar la frase de contraseña: cuando haya creado claves (por lo que es normal)

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

- SERVIDOR -----

4. modifique / etc / ssh / sshd_config para que tenga

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

(no es el caso)

Esto le dice a ssh que acepte authorized_keys y busque en el directorio de inicio del usuario la cadena de key_name 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 apaga el pase de autenticación

passwordAuthentication no

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

6 Asegúrese de que la propiedad y la propiedad de grupo de todos los directorios principales que no sean root sean apropiados.

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

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

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

8. SCH TUNNEL adicional para acceder a un servidor MySQL (bind = 127.0.0.1)

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

PermitRootLogin without-password

establecer como se indica anteriormente, luego reinicie sshd (/etc/init.d/sshd restart)

cerrar sesión e intentar iniciar sesión de nuevo!

por defecto, creo que es -;

PermitRootLogin no

esto resuelve mi problema

ssh-agent bash
ssh-add

los desesperados también pueden asegurarse de que no tengan nuevas líneas adicionales en el archivo authorized_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

sudo chmod 700 ~/.ssh y chmod 600 ~/.ssh/authorized_keys y chmod go-w $HOME $HOME/.ssh desde arriba y solucioné mi problema en una caja de CentOS7 en la que había desordenado los permisos mientras tratando de hacer funcionar las acciones de samba. Gracias