it-swarm-es.com

¿Cómo configuro SSH para que no intente todos los archivos de identidad automáticamente?

He estado poniendo mis archivos de identidad ssh dentro de mi carpeta ~/.ssh /. Probablemente tengo unos 30 archivos allí.

Cuando me conecte a los servidores, especificaré el archivo de identidad a usar, con algo como

 ssh -i ~/.ssh/client1-identity [email protected] 

Sin embargo, si no especifico un archivo de identidad y solo uso algo como esto:

 ssh [email protected] 

Me sale el error

Demasiados fallos de autenticación para el usuario123

Entiendo que es porque si no se especifica ningún archivo de identidad, y ssh puede encontrar archivos de identidad, entonces los intentará todos.

También entiendo que puedo editar el archivo ~/.ssh/config y especificar algo como:

 Host example.com 
 PreferredAuthentications keyboard-interactive, password 

para evitar que la conexión intente con archivos de identidad conocidos.

Por lo tanto, supongo que podría mover mis archivos de identidad fuera del directorio ~/.ssh/, o podría especificar cada Host para el que deseo deshabilitar la autenticación del archivo de identidad en el archivo de configuración, pero ¿hay alguna forma de decirle a SSH que compre por defecto, no busque? para archivos de identidad? ¿O para especificar los que buscará?

96
cwd

Puede usar la opción IdentitiesOnly=yes junto con IdentityFile (ver página de manual ssh_config ) De esa manera, puede especificar qué archivo (s) debe buscar.

En este ejemplo, ssh solo buscará en las identidades proporcionadas en los archivos ssh_config + los 4 que aparecen en la línea de comando (las identidades proporcionadas por el agente serán ignoradas)

ssh -o IdentitiesOnly=yes \
    -o IdentityFile=id1.key \
    -o IdentityFile=id2.key \
    -i id3.key \
    -i id4.key \
    [email protected]

Los formularios -i y -o IdentityFile= son intercambiables.

93
user76528

la respuesta corta del usuario 76528 es correcta, pero acabo de tener este problema y pensé que alguna elaboración sería útil. También podría interesarle esta solución si se pregunta "¿Por qué ssh ignora mi opción de configuración de archivo de identidad"?

En primer lugar, a diferencia de todas las demás opciones en ssh_config, ssh no usa la primera IdentityFile que encuentra. En su lugar, la opción IdentityFile agrega ese archivo a una lista de identidades utilizadas. Puede apilar múltiples opciones IdentityFile, y el cliente ssh las probará todas hasta que el servidor acepte una o rechace la conexión.

Segundo, si usa ssh-agent, ssh intentará usar las claves en el agente automáticamente, incluso si no las ha especificado con la opción IdentityFile (o -i) de ssh_config. Este es un motivo común por el que puede obtener el error Too many authentication failures for user. Usar la opción IdentitiesOnly yes deshabilitará este comportamiento.

Si ssh como usuarios múltiples en múltiples sistemas, recomiendo poner IdentitiesOnly yes en su sección global de ssh_config, y poner cada IdentityFile dentro de las subsecciones de Host apropiadas.

77
chrishiestand

Generalmente lo hago así:

$ ssh -o IdentitiesOnly=yes -F /dev/null -i ~/path/to/some_id_rsa root[email protected]

Las opciones son las siguientes:

  • -o IdentitiesOnly=yes - le dice a SSH que use solo las claves que se proporcionan a través del CLI y ninguna del $HOME/.ssh o a través de ssh-agent
  • -F /dev/null - desactiva el uso de $HOME/.ssh/config
  • -i ~/path/to/some_id_rsa - la clave que desea utilizar explícitamente para la conexión

Ejemplo

$ ssh -v -o IdentitiesOnly=yes -F /dev/null -i ~/my_id_rsa [email protected]
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /dev/null
debug1: Connecting to someserver.mydom.com [10.128.12.124] port 22.
debug1: Connection established.
debug1: identity file /Users/sammingolelli/my_id_rsa type 1
debug1: identity file /Users/sammingolelli/my_id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5*
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<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: Server Host key: RSA f5:60:30:71:8c:a3:da:a3:fe:b1:6d:0b:20:87:23:e1
debug1: Host 'someserver' is known and matches the RSA Host key.
debug1: Found key in /Users/sammingolelli/.ssh/known_hosts:103
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
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/sammingolelli/my_id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to someserver.mydom.com ([10.128.12.124]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
Last login: Tue Dec  8 19:03:24 2015 from 153.65.219.15
someserver$

Observe en la salida anterior que ssh solo ha identificado la clave privada my_id_rsa a través de la CLI y que la utiliza para conectarse a someserver.

Específicamente estas secciones:

debug1: identity file /Users/sammingolelli/my_id_rsa type 1
debug1: identity file /Users/sammingolelli/my_id_rsa-cert type -1

y:

debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/sammingolelli/my_id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
18
slm

En el escenario en el que tiene muchas claves, invariablemente se encontrará con el error "Demasiadas fallas de autenticación". Si tiene una contraseña, y simplemente quiere usarla para iniciar sesión, aquí tiene cómo hacerlo.

Para usar SOLO la autenticación de contraseña y NO usar la clave pública, y NO usar el "teclado interactivo" (que es un superconjunto que incluye la contraseña), puede hacerlo desde la línea de comandos:

ssh -o PreferredAuthentications=password [email protected]
9
Greg Rundlett

Utilice IdentityFile pero siga usando ssh-agent para evitar repeticiones de frase de contraseña

La solución aceptada de usar IdentitiesOnly yes significa que nunca podrá tomar ventaja de ssh-agent, lo que resultará en indicaciones repetidas para su frase de contraseña al cargar su clave.

Para seguir usando ssh-agent y evitar los errores de 'Demasiados errores de autenticación', intente esto:

  1. Elimine cualquier secuencia de comandos de inicio de consola interactiva que cargue automáticamente las claves en ssh-agent.

  2. agregue AddKeysToAgent yes a la configuración ssh de su cliente. Esto le solicitará la contraseña en la primera conexión, pero luego agregará la clave a su agente.

  3. use ssh-add -D cuando obtenga 'demasiados errores de autenticación'. Esto simplemente 'restablece' (borra) su caché ssh-agent. Luego intente la conexión nuevamente dentro de la misma sesión. Se le pedirá una frase de contraseña y, una vez aceptada, se agregará a su agente. Como solo tendrá una clave en su agente, se le permitirá conectarse. ssh-agent todavía está allí para futuras conexiones durante la misma sesión para evitar repeticiones.

    Host ex example.com
       User joe
       HostName example.com
       PreferredAuthentications publickey,password
       IdentityFile /path/to/id_rsa
       AddKeysToAgent yes
    
6
AndrewD

El cliente ssh y ssh-agent se comunican a través de un socket de dominio Unix cuyo nombre se especifica para el cliente mediante la variable de entorno SSH_AUTH_SOCK (establecida por el agente en el inicio).

Por lo tanto, para evitar que una sola invocación del cliente consulte al agente, esta variable se puede establecer explícitamente en algo no válido, como una cadena vacía;

$ SSH_AUTH_SOCK= ssh [email protected]

Una invocación de cliente como esta no podrá comunicarse con el agente y solo podrá ofrecer al servidor las identidades disponibles como archivos en ~/.ssh /, o cualquier otra especificada en la línea de comandos usando -i.

debug1: pubkey_prepare: ssh_get_authentication_socket: Connection refused
1
mikini

agregue esto al final del archivo ~/.ssh/config para evitar el uso de claves para servidores que no sean de configuración:
Anfitrión *
IdentitiesOnly = yes

0
Maxim Akristiniy

Tuviste la respuesta todo el tiempo (casi):

Host *
PreferredAuthentications keyboard-interactive,password

Trabajó para mi.

0
Henry Grebler