¿Cómo configuro SSH para que no pruebe 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 client1@10.1.1.10

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

ssh user123@example.com

Me sale el error

Demasiados errores 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 probará todos.

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

Host example.com
Autenticaciones preferidas interactivas con el teclado, contraseña

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

Entonces, supongo que podría mover mis archivos de identidad fuera del ~/.ssh/directorio, o podría especificar cada host para el que quiero deshabilitar la autenticación del archivo de identidad en el archivo de configuración, pero ¿hay alguna manera de decirle a SSH que compre el valor predeterminado y no busque archivos de identidad? ¿O para especificar los que buscará?

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

En este ejemplo, ssh solo buscará las identidades dadas en los archivos ssh_config + las 4 que figuran 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 \
    user123@example.com

Las formas -iy -o IdentityFile=son intercambiables.

La respuesta corta de user76528 es correcta, pero acabo de tener este problema y pensé que alguna elaboración sería útil. También le puede interesar 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 cualquier otra opción en ssh_config, ssh no usa la primera IdentityFileque encuentra. En cambio, la IdentityFileopción agrega ese archivo a una lista de identidades utilizadas. Puede apilar varias IdentityFileopciones, y el cliente ssh las probará todas hasta que el servidor acepte una o rechace la conexión.

En segundo lugar, si usa un agente ssh, ssh intentará usar automáticamente las claves en el agente, incluso si no las ha especificado con la opción IdentityFile (o -i) de ssh_config. Esta es una razón común por la que puede obtener el Too many authentication failures for usererror. Usar la IdentitiesOnly yesopción deshabilitará este comportamiento.

Si ssh como múltiples usuarios para múltiples sistemas, le recomiendo poner IdentitiesOnly yesen su sección global de ssh_config, y poner cada uno IdentityFiledentro de las subsecciones de Host apropiadas.

Generalmente lo hago así:

$ ssh -o IdentitiesOnly=yes -F /dev/null -i ~/path/to/some_id_rsa root@server.mydom.com

Las opciones son las siguientes:

• -o IdentitiesOnly=yes- le dice a SSH que use solo las claves que se proporcionan a través de la CLI y ninguna desde $HOME/.ssho 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 usar explícitamente para la conexión

Ejemplo

$ ssh -v -o IdentitiesOnly=yes -F /dev/null -i ~/my_id_rsa root@someserver.mydom.com
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 no-more-sessions@openssh.com
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 sshsolo ha identificado la my_id_rsaclave privada a través de la CLI y que la usa para conectarse a un servidor.

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

En el escenario donde tiene muchas claves, invariablemente se encontrará con el error "Demasiadas fallas de autenticación". Si tiene una contraseña y desea simplemente usar la contraseña para iniciar sesión, así es como lo hace.

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

ssh -o PreferredAuthentications=password user@example.com

Use IdentityFile pero siga usando ssh-agent para evitar las frases de contraseña

La solución aceptada de usar IdentitiesOnly yessignifica que nunca podrá aprovechar ssh-agent, lo que da como resultado repetidas solicitudes para su frase de contraseña al cargar su clave.

Para seguir usando ssh-agenty evitar los errores 'Demasiadas fallas de autenticación', intente esto:

1. Elimine los scripts de inicio de la consola interactiva que carguen las claves automáticamente ssh-agent.

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

3. utilícelo ssh-add -Dcuando reciba errores de "demasiada autenticación". Esto simplemente 'restablece' (elimina) su caché de agente ssh. Luego intente la conexión nuevamente dentro de la misma sesión. Se le solicitará 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 reprompts.

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

El cliente ssh y el se ssh-agentestá comunicando a través de un socket de dominio Unix cuyo nombre se especifica al cliente mediante la SSH_AUTH_SOCKvariable de entorno (establecida por el agente al iniciarse).

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 user@server

Una invocación de cliente como esta fallará en la comunicación con el agente y solo podrá ofrecer al servidor las identidades disponibles como archivos en ~/.ssh/, o cualquiera especificado en la línea de comando que use -i.

debug1: pubkey_prepare: ssh_get_authentication_socket: Connection refused

Tuviste la respuesta todo el tiempo (casi):

Host *
PreferredAuthentications keyboard-interactive,password

Trabajó para mi.

agregue esto al final del ~/.ssh/configarchivo para evitar el uso de claves para servidores que no sean de configuración:

Host *
IdentitiesOnly=yes