No se puede configurar el inicio de sesión ssh sin escribir la contraseña

8

Configuré automáticamente el inicio de sesión ssh sin escribir la contraseña en un servidor:

cd ~/.ssh

ssh-keygen

ssh-copy-id -i ~/.ssh/id_rsa.pub tim@server1

Funciona en el servidor.

Más tarde hice lo mismo en un servidor diferente.

ssh-copy-id -i ~/.ssh/id_rsa.pub tim@server2

Inmediatamente yo ssh tim@server2, pero aún requiere mi contraseña. ¿Hice algo incorrectamente? ¿Cuáles son algunos motivos posibles por los que no configuré correctamente en el segundo servidor? (tenga en cuenta que el segundo servidor ejecuta el sistema de archivos Kerberos y Andrew)

$ ssh -v tim@server2
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to server2 [...] port 22.
debug1: Connection established.
debug1: identity file /home/tim/.ssh/id_rsa type 1
debug1: identity file /home/tim/.ssh/id_rsa-cert type -1
debug1: identity file /home/tim/.ssh/id_dsa type -1
debug1: identity file /home/tim/.ssh/id_dsa-cert type -1
debug1: identity file /home/tim/.ssh/id_ecdsa type -1
debug1: identity file /home/tim/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/tim/.ssh/id_ed25519 type -1
debug1: identity file /home/tim/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<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: Server host key: RSA xxx
debug1: Host 'server2' is known and matches the RSA host key.
debug1: Found key in /home/tim/.ssh/known_hosts:70
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Trying private key: /home/tim/.ssh/id_dsa
debug1: Trying private key: /home/tim/.ssh/id_ecdsa
debug1: Trying private key: /home/tim/.ssh/id_ed25519
debug1: Next authentication method: keyboard-interactive
Password:

Probé el método de Anthon de usar las llaves Diffie-Hellman, pero aún así me pide mi contraseña.

$ cd ~/.ssh
$ ssh-keygen -t dsa
$ ssh-copy-id -i ~/.ssh/id_dsa.pub tim@server2
$ ssh -v tim@server2
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to server2 [...] port 22.
debug1: Connection established.
debug1: identity file /home/tim/.ssh/id_rsa type 1
debug1: identity file /home/tim/.ssh/id_rsa-cert type -1
debug1: identity file /home/tim/.ssh/id_dsa type 2
debug1: identity file /home/tim/.ssh/id_dsa-cert type -1
debug1: identity file /home/tim/.ssh/id_ecdsa type -1
debug1: identity file /home/tim/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/tim/.ssh/id_ed25519 type -1
debug1: identity file /home/tim/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<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: Server host key: RSA ...
debug1: Host 'server2' is known and matches the RSA host key.
debug1: Found key in /home/tim/.ssh/known_hosts:70
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Next authentication method: publickey
debug1: Offering DSA public key: /home/tim/.ssh/id_dsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Trying private key: /home/tim/.ssh/id_ecdsa
debug1: Trying private key: /home/tim/.ssh/id_ed25519
debug1: Next authentication method: keyboard-interactive
Password:
ssh Tim
fuente
¿Su directorio de inicio está montado después de iniciar sesión?
muru
Después de cada inicio de sesión en el pasado, mi casa siempre estaba montada.
Tim
Sí, una vez que inicia sesión, obtiene su directorio de inicio, pero ¿qué pasa antes de que se complete el inicio de sesión? (Considere directorios de inicio cifrados, o un directorio de inicio de red, etc.)
muru
Escuché que server2usa el sistema de archivos Andrew. ¿Eso significa que mi casa no está montada antes de que se complete el inicio de sesión? ¿Cómo puedo averiguarlo para su pregunta?
Tim
No estoy seguro de cómo funciona el sistema de archivos de Andrew, pero si tiene otro inicio de sesión en el mismo servidor, úselo y vea si puede ver el contenido del timdirectorio de inicio de.
muru

Respuestas:

10

Usted menciona que el segundo servidor está usando el Sistema de archivos Andrew (AFS).

No he trabajado con eso, pero por lo que entiendo, AFS es un sistema de archivos protegido por Kerberos que requiere un ticket kerberos para funcionar. Eso significa que debe iniciar sesión en el reino Kerberos de su sitio para poder acceder a su directorio de inicio.

Si server2inicia sesión con contraseña, es probable que esté configurado para que inicie sesión en su reino Kerberos a través de PAM. Sin embargo, si está utilizando claves SSH, server2no obtendrá la información que necesita para hacerlo y no podrá acceder a su directorio de inicio.

Afortunadamente, a partir del ssh -vresultado de su pregunta, podemos inferir que su servidor tiene GSSAPIhabilitada la autenticación. Esto debería permitirle realizar un inicio de sesión sin contraseña, siempre que tenga un ticket kerberos válido para su reino. Haz lo siguiente:

  • Inicie sesión server2y ejecute el klistprograma. Esto devolverá algo en las siguientes líneas:

    Ticket cache: FILE:/tmp/krb5cc_2000
Default principal: [email protected]

Valid starting     Expires            Service principal
28-05-15 15:01:31  29-05-15 01:01:31  krbtgt/[email protected]
    renew until 29-05-15 15:01:28
28-05-15 15:02:04  29-05-15 01:01:31  IMAP/[email protected]
    renew until 29-05-15 15:01:28

    busca la línea que comienza con Default principal:. Le dice cuál es su principal kerberos (en el ejemplo anterior, es [email protected]). Escribe esto. Tenga en cuenta que no es una dirección de correo electrónico y que distingue entre mayúsculas y minúsculas; es decir, el principal termina con EXAMPLE.ORG, no example.org.

  • En su máquina cliente, ejecute kinitcon el nombre de su director (es decir, en el ejemplo anterior, sería kinit [email protected]). Si todo va bien, cuando klistvuelva a ejecutar ahora, verá que tiene un caché de tickets en su máquina local.
  • Si ahora ejecuta ssh -K server2, debería poder iniciar sesión y el sistema no debería solicitar una contraseña.

Tenga en cuenta que debido a cómo funciona Kerberos, la caché de tickets tiene una validez limitada. No es posible solicitar un caché de tickets con una validez superior a la que configuró el administrador del reino (que suele ser algo así como 10 horas más o menos). Una vez que su boleto haya expirado, deberá ejecutar kinitnuevamente e ingresar su contraseña una vez más.

Wouter Verhelst
fuente
Gracias. "En su máquina cliente, ejecute kinit", ¿quiere decir que tengo que instalar Kerberos en mi Ubuntu local?
Tim
Parte de las herramientas kerberos, sí. Encontrarás las herramientas necesarias en el krb5-userpaquete.
Wouter Verhelst
¿Debo usar rsa o dsa al crear las claves públicas y copiarlas en el servidor? (Seguí la sugerencia de Anthon de usar dsa en este momento)
Tim
Debido a AFS en el servidor, no puede usar claves públicas SSH, necesita usar kerberos en su lugar. Así que no importa ;-)
Wouter Verhelst
¿Son GSSAPI, dsa y rsa todos los métodos de autenticación?
Tim
5

Debe intentar conectarse al servidor2 con:

ssh -v tim@server2

y compare eso con lo mismo, conectarse a server1esto le dirá exactamente dónde difieren los dos servidores.

Lo más probable es que haya una diferencia en /etc/ssh/sshd_configambas máquinas. dónde server2o si ~/.sshtiene problemas de accesibilidad (no lo suficientemente restringidos).

En la -vsalida, puede ver que ofrece una clave privada RSA para verificar en (in /home/tim/.ssh/id_rsa), pero parece que server2solo es compatible con Diffie-Hellman (e intenta /home/tim/.ssh/id_dsaque probablemente ni siquiera esté allí).

Anthon
fuente
gracias, actualicé con el resultado de ejecutar su comando. No estoy seguro de lo que significa
Tim
@Tim actualizó mi respuesta, debe verificar con el administrador del servidor2 por qué no parece admitir las claves públicas / privadas de RSA.
Anthon
Además de preguntarle al administrador (que creo que es imposible hacer ningún cambio basado en mis experiencias), ¿hay alguna forma de trabajar con lo que el servidor espera?
Tim
@Tim, primero asegúrese de que ~/.sshen el servidor tenga instaladas sus claves autorizadas ( ~/.ssh/authorized_keys). Entonces, lo que podría intentar hacer es ssh-keygengenerar un par de claves diffie-hellman usando ssh-keygen -t dsay copiarlo.
Anthon
(1) Hay un archivo ~/.ssh/authorized_keysen el servidor. ¿Eso significa que tiene instaladas las claves autorizadas? (2) ¿cómo debo copiar el par de claves diffie-hellman generado al servidor? por scp ~/.ssh/id_dsa.pub tim@server2:~/.ssh/authorized_keys? ¿sobrescribirá eso ~/.ssh/authorized_keysen el servidor?
Tim
4

Agregue la siguiente entrada en la máquina cliente desde la que está intentando ssh.

archivo de configuración: /etc/ssh/ssh_config

GSSAPIAuthentication no

Después de eso podrás enviar ssh a la máquina.

Si no tiene permisos de edición para ese archivo, también puede agregar

Host *
  GSSAPIAuthentication no

para ~/.ssh/config(crear este archivo si no existe)

sudhams reddy
fuente