☰

¿Cómo configuro SSH para no tener que escribir una contraseña y sin usar una clave pública?

tag-icon • tag-icon ssh unix
¿Cómo configuro SSH para no tener que escribir una contraseña y sin usar una clave pública?

Sé que hay docenas de preguntas aquí sobrecómo conectarse a un servidor SSH sin tener que escribir su contraseña cada vez, y la respuesta siempre es "usar una clave pública". Bueno, me encuentro en la rara circunstancia de que esa no sea realmente una opción. Por alguna razón inexplicable, el demonio OpenSSH en el servidor al que intento conectarme está configurado con

RSAAuthentication no
PubkeyAuthentication no

en /etc/ssh/sshd_config. No tengo ningún acceso administrativo en el servidor, por lo que no puedo cambiar estas ni otras opciones de configuración del servidor. (Por supuesto, tengo control total sobre la configuración del cliente: OpenSSH 5.8 en Linux).

¿Cuáles son mis opciones y, en particular, cuál es la opción más segura para evitar tener que escribir mi contraseña cada vez que quiero ingresar mediante SSH a este servidor? Mantengo mis propias computadoras bastante bien protegidas, así que supongamos que los riesgos de seguridad de almacenar la contraseña en un archivo en el cliente son aceptablemente bajos, si es que eso es realmente necesario.

Los otros métodos de autenticación que el servidor puede aceptar son, evidentemente, GSS API (del que no sé nada), teclado interactivo (del que tampoco sé nada) y contraseña. A continuación se muestran algunas opciones de configuración relevantes:

#ChallengeResponseAuthentication yes

#KerberosAuthentication no

GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

#UsePAM no

y aquí hay un -vvseguimiento de depuración ():

debug1: Authentications that can continue: gssapi-with-mic,password,keyboard-interactive
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found
debug1: Unspecified GSS failure.  Minor code may provide more information

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

debug2: we did not send a packet, disable method
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug1: Authentications that can continue: gssapi-with-mic,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug1: Next authentication method: password

Respuesta1

En este caso, escribir (o mejor grabar) un guión esperado sería una de sus opciones.

Cada sistema es diferente por lo que no habrá un script, pero con autoexpect es muy fácil grabar un script para este propósito.

Respuesta2

Según la información recopilada hasta ahora, el servidor sftp.pass.psu.eduadmite la autenticación Kerberos 5 (GSSAPI) y está en el dce.psu.edudominio.

Kerberos esmuycomún en redes con muchos servidores y estaciones de trabajo; Muchas grandes instituciones educativas lo han creado. Una de sus ventajas sobre la autenticación de clave pública es que una única kinitproporciona automáticamente credenciales a todas las máquinas en el ámbito de Kerberos, sin tener que copiar las claves públicas de cada una. Otra es la compatibilidad con protocolos: las mismas credenciales de Kerberos se pueden utilizar con más de 30 protocolos (correo, sistemas de archivos, bases de datos...), no sólo SSH.

(Con respecto a los "administradores despistados solo de Windows": el dce.psu.eduámbito en realidad parece estar basado en Active Directory y alojado en servidores de Windows).

Intente seguir estos pasos:

  1. Inicie sesión en Kerberos. (Las herramientas kinity klistpueden estar en "krb5-user" o un paquete similar, si aún no están incluidos con el sistema).

    kinitosu nombre de usuario@dce.psu.edu

    Si no se muestran errores, el inicio de sesión fue exitoso. klistdebería mostrar un krbtgt/dce.psu.edu@...elemento " ".

  2. Ahora conéctese al servidor SSH, con las -vvopciones; Si la autenticación tiene éxito, bien.

    Si no es así, es posible que tengas que editar tu /etc/krb5.confarchivo. En la [domain_realm]sección, agregue lo siguiente:

    [domain_realm]
    .psu.edu = dce.psu.edu

  3. Con la configuración predeterminada de Krb5, el boleto obtenido en el punto 1 debe ser válido por 10 horas y renovable por hasta una semana. Sin embargo, no tengo forma de verificar la configuración.

    Si quieres guardar la contraseña en un archivo, kinit your_principal < password.txtdebería funcionar un sencillo, aunque no es del todo fiable.

    Con ktutilél es posible hacer un"tabla de teclas"para su uso en lugar de la contraseña.

    $ktutil
ktutil: addent -contraseña -ptu_principal-k 1 -e aes256-cts-hmac-sha1-96
Contraseña paratu_principal: *********
ktutil: wktarchivo_tab_claves
ktutil:  CtrlD

    e inicie sesión usando:

    $ kinit-ktarchivo_tab_claves tu_principal

Respuesta3

Consideraría una solución mixta, en la que ingresa la contraseña solo una vez y la computadora mantiene un conector al servidor SSH remoto. puedes seguirestos pasosconfigurar el ControlMastersolo por esa razón.

información relacionada