¿Dejar de que el cliente ssh ofrezca todas las claves públicas que puede encontrar?

32

Como la mayoría de los administradores de sistemas, uso openssh todo el tiempo. Tengo alrededor de una docena de claves ssh, me gusta tener una clave ssh diferente para cada host. Sin embargo, esto causa un problema cuando me conecto a un host por primera vez, y todo lo que tengo es una contraseña. Solo quiero conectarme al host usando una contraseña, sin clave ssh en este caso. Sin embargo, el cliente ssh ofrecerá todas las claves públicas en mi ~/.ssh/(lo sé mirando la salida de ssh -v). Como tengo tantos, me desconectaré por demasiados errores de autenticación.

¿Hay alguna forma de decirle a mi cliente ssh que no ofrezca todas las claves ssh?

ssh public-key private-key

— Rory
fuente

2

¿Por qué querrías una clave diferente para cada host? Las claves también se pueden compartir entre hosts dentro de un único dominio administrativo. Obviamente, usaría una clave para sus máquinas de trabajo y otra para sus máquinas privadas, pero ¿cuál es la lógica detrás del uso de una clave separada para cada máquina en el trabajo?

— Alex Holst

@ AlexHolst Estoy usando muchas teclas. Tengo uno predeterminado encriptado (que requiere que ingrese una contraseña) para la infraestructura interna. Tengo otro no encriptado (sin contraseña) que utilizo para un servicio específico donde no podía usar un agente ni quería escribir cada minuto la contraseña. Tengo otros para conexiones que no son parte de nuestra infraestructura interna. Es una buena práctica, porque aunque debería ser bastante difícil para alguien recuperar la clave privada de la clave pública, se puede hacer. por ejemplo, el error de Debian openssh hace algunos años ...

— Huygens

@Huygens Me encantaría ver su documento de análisis de riesgos que resultó en la conclusión de que necesita usar varias claves SSH, pero tener un texto claro está bien. Puedes publicar un enlace?

— Alex Holst

@AlexHolst no tienes que ser tan "directo". En primer lugar, mi respuesta fue sobre las razones para tener múltiples pares de claves. Creo que te di varios. Después, todos tenemos que lidiar con caprichos y demás. Tengo un sistema de prueba para el que no puedo usar una aplicación que está haciendo un túnel de datos a través de SSH sin que se me solicite continuamente la contraseña clave, lo que hace que el software no sea utilizable. Parece ser un error debido a la incompatibilidad de versiones o no. Recibo una notificación por correo electrónico para cualquier inicio de sesión SSH, y soy el único que inicia sesión en ese cuadro. Entonces el riesgo es aceptable.

— Huygens

31

Este es el comportamiento esperado de acuerdo con la página de manual de ssh_config:

 IdentityFile
         Specifies a file from which the user's DSA, ECDSA or DSA authentica‐
         tion identity is read.  The default is ~/.ssh/identity for protocol
         version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa and ~/.ssh/id_rsa for
         protocol version 2.  Additionally, any identities represented by the
         authentication agent will be used for authentication.  

         [...]

         It is possible to have multiple identity files specified in configu‐
         ration files; all these identities will be tried in sequence.  Mul‐
         tiple IdentityFile directives will add to the list of identities
         tried (this behaviour differs from that of other configuration
         directives).

Básicamente, especificar IdentityFiles solo agrega claves a una lista actual que el agente SSH ya presentó al cliente.

Intente anular este comportamiento con esto al final de su .ssh/configarchivo:

Host *
  IdentitiesOnly yes

También puede anular esta configuración en el nivel de host, por ejemplo:

Host foo
  User bar
  IdentityFile /path/to/key
  IdentitiesOnly yes

— Mathias Bynens
fuente

44

También puede usar ssh -o "IdentitiesOnly true" -v -A user@hostcuál es lo que uso para iniciar sesión en una máquina que no tiene ninguna de mis claves, pero quiero ofrecer el reenvío de agente para continuar. ( -vpara depuración detallada).

— Eckes

1

@eckes es un buen consejo, pero ¿no debería serlo yes(y no true)?

— aexl

IdentitiesOnlypuede que no siempre ayude, es posible que deba excluir un host específicamente; ver superuser.com/questions/859661/...

— aexl

38

Aunque otros han insinuado esto con soluciones basadas en la configuración, probablemente valga la pena señalar que puede hacerlo fácilmente solo una vez en la línea de comandos con:

ssh -o 'PubkeyAuthentication no' myhostname.mydomain

— Andrew Ferrier
fuente

3

Perfecto .. LA solución en mi humilde opinión

— drAlberT

1

Correcto, esta debería haber sido la respuesta aceptada.

— JM Becker

11

Siguiendo la solución de James Sneeringer, es posible que solo desee establecer un ssh_config en la línea de:

Host *.mycompany.com
  IdentityFile .ssh/id_dsa_mycompany_main

Host *.mycustomer.com
  IdentityFile .ssh/id_dsa_mycustomer

Host *
  RSAAuthentication no #this should be up top, avoid ssh1 at all costs
  PubkeyAuthentication no

Si se conecta con una clave particular a muchas máquinas que no están en un dominio común, considere darles todos los CNAME en su propio DNS. Hago esto con todos los sistemas del cliente.

— Justin Alan Ryan
fuente

2

Similar a la solución de user23413, puede deshabilitar por completo la autenticación de clave pública para un host particular (o patrón comodín):

Host *.example.org
RSAAuthentication no        # SSHv1
PubkeyAuthentication no     # SSHv2

— James Sneeringer
fuente

-1

Si señala un archivo de clave en particular con ssh -i / ruta / a / clave, solo lo usará incluso si otros están cargados en el agente, y no se le pedirá la contraseña. También puede editar su ~ / .ssh / config y agregar algo como esto ...

Host foo.example.com
IdentityFile .ssh / id_rsa_foo.example.com

también puedes hacer ...

Host * .example.org
IdentityFile .ssh / id_rsa_example.org

— ryanc
fuente

Eso solo se agrega a la clave de destino al final de la lista, lo que no resolverá el problema. IdentitiesOnlysolo con esa voluntad.

— Jo Rhett