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

102

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 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á?

linux unix authentication ssh cwd
fuente
44
Re "Entiendo que es porque ..." - use ssh -vpara averiguarlo con seguridad.
Grawity

Respuestas:

101

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 \
    [email protected]

Las formas -iy -o IdentityFile=son intercambiables.

init_js
fuente
77
Un ejemplo sería bueno
rubo77
1
¿No es así: IdentitiesOnly yes(sin el "=")?
Dimitrios Mistriotis
3
@DimitriosMistriotis Según la página de manual de ssh_config, cualquiera de ellos es aceptable:Configuration options may be separated by whitespace or optional whitespace and exactly one '='; the latter format is useful to avoid the need to quote whitespace when specifying configuration options using the ssh, scp, and sftp -o option.
Nick Anderegg
IdentitiesOnlypuede que no siempre funcione, es posible que deba excluir un host específicamente; ver superuser.com/questions/859661/...
aexl
79

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.

Chrishiestand
fuente
55
Bien explicado, gracias. No es obvio que ese parámetro 'IdentitiesOnly' significa TakeOnlyWhatIExplicitlySpecifyThenFailoverToPassword . Y aparentemente, la clave ./ssh/id_rsa todavía está en la lista.
Imbus
Poner IdentitiesOnly yesen la sección global de ssh_config es lo que lo hizo por mí. ¡Gracias!
jamix
1
Gracias por el comentario detallado. Solía ​​usar ('\' para nueva línea) Host * \ IdentityFile ~/.ssh/mykeycomo una opción de configuración, y al principio parecía extraño que tener una entrada diferente para un sitio específico, por ejemplo, Host special \ IdentityFile ~/.ssh/specialkey \ IdentitiesOnly yescontinuaba suministrando en mykeylugar de specialkey. Ciertamente no estaba claro, hasta que me di cuenta (por su respuesta) de que las entradas de IdentityFile se apilan en un orden de evaluación y se utilizará la última definida. La eliminación IdentityFile ~/.ssh/mykeysolucionó el problema y se utilizó la clave única correcta.
Ryder
1
Antes de intentar esto, noté que mis git pull/pushcomandos intentaban cada identidad cargada en mi agente. No fue un problema hasta que en un momento tuve demasiadas llaves.
sdkks
21

Generalmente lo hago así:

$ ssh -o IdentitiesOnly=yes -F /dev/null -i ~/path/to/some_id_rsa [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 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 [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 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).
slm
fuente
1
Gracias, esta es la única solución completa. Aparentemente, -F /dev/nulles la pieza que falta en las otras respuestas.
leden
10

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 [email protected]
Greg Rundlett
fuente
7

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
AndrewD
fuente
¿Aceptará las claves agregadas al llavero?
vfclists
2

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
mikini
fuente
Esta es una respuesta genial. Es simple y funciona cuando usa comandos que usan SSH "bajo el capó", como git. Una pena que no pueda votar más.
rsuarez
1

Tuviste la respuesta todo el tiempo (casi):

Host *
PreferredAuthentications keyboard-interactive,password

Trabajó para mi.

Henry Grebler
fuente
8
La pregunta fue sobre cómo limitar qué claves públicas se utilizan. Esta respuesta deshabilita la autenticación de clave pública por completo.
chrishiestand
1
Hice +1 porque era la respuesta que buscaba en Google, gracias @Henry Grebler
matiu
1

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

Host *
IdentitiesOnly=yes
Maxim Akristiniy
fuente