☰

¿Hay alguna manera de que ssh ofrezca más claves para iniciar sesión automáticamente?

tag-icon • tag-icon ssh login
¿Hay alguna manera de que ssh ofrezca más claves para iniciar sesión automáticamente?

Aprendí en innumerables fuentes en línea que (aproximadamente), para iniciar sesión en un servidor remoto sin contraseña: generar una clave ssh, colocar la versión pub en Authorized_keys en el sistema remoto; coloque la versión privada en su directorio local ~/.ssh/; Cambie a 0600 y ¡puf!, ya está. Si bien eso es en gran medida correcto, encuentro que la clave (par) debe llamarse id_rsa (id_rsa.pub) o id_dsa (id_dsa.pub) para que SSH la ofrezca al control remoto. servidores.

Permítanme retroceder un poco. Tengo un inicio de sesión SurnameGen mi Mac local. Tengo una cuenta SurnameG en un sistema remoto, otro servidor.

Copié el contenido de ~/.ssh/surnameg.puben /home/surnameg/.ssh/authorized_keys de ese sistema. Probé con la -iopción de mi Mac para iniciar sesión por ssh y funciona bien.

Tengo un ~/.ssh/id_rsa(que generé para usar congithub.com).

Y, por supuesto, tengo ~/.ssh/surnamege incluso algunas otras claves allí, que no se "prueban" cuando intento iniciar sesión de la siguiente maneraotrosservidor.com:

ssh 1.2.3.4

Aquí, estoy intentando utilizar SurnameG(el usuario que ha iniciado sesión localmente actualmente) para iniciar sesión en mi SurnameGcuenta enotro servidor. Quiero que openssh ofrezca ~/.ssh/surnamegsu intento de conectarse, pero no lo hace; echemos un vistazo más de cerca a la opción detallada:

BOX:~ SurnameG$ ssh -v 1.2.3.4
OpenSSH_5.9p1, OpenSSL 0.9.8y 5 Feb 2013
debug1: Reading configuration data /Users/SurnameG/.ssh/config
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: Connecting to 1.2.3.4 [50.112.132.124] port 22.
debug1: Connection established.
debug1: identity file /Users/SurnameG/.ssh/id_rsa type 1
debug1: identity file /Users/SurnameG/.ssh/id_rsa-cert type -1
debug1: identity file /Users/SurnameG/.ssh/id_dsa type -1
debug1: identity file /Users/SurnameG/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
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 ax:64:3e:4a:e3:2c:e4:30:dd:36:a4:a0:9x:fa:ba:6b
debug1: Host '1.2.3.4' is known and matches the RSA host key.
debug1: Found key in /Users/SurnameG/.ssh/known_hosts:88
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
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/SurnameG/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Trying private key: /Users/SurnameG/.ssh/id_dsa
debug1: No more authentication methods to try.

Curiosamente, openssh sólo ofrece ~/.ssh/id_rsa, pero eso no es todo. ¿También "intenta" ~/.ssh/id_dsa? No estoy seguro de la diferencia entre los dos (ofrecer versus probar). De todos modos, si leo correctamente, openssh nunca prueba ninguna de mis otras claves privadas en ~/.ssh/*.

Bien, sé que puedo describir explícitamente cada servidor ~/.ssh/configcon algo como

Host otherserver
   HostName 1.2.3.4
   User surnameg
   IdentityFile ~/.ssh/surnameg

y luego inicie sesión con

ssh otherserver

y eso está muy bien y funciona muy bien. Pero realmente, mi ~/.ssh/config se está volviendo difícil de manejar. Lamentablemente no lo hice cd ~/.ssh && git inithace mucho tiempo. Pero yo divago.

Mi pregunta es la siguiente: ¿Existe una forma más simple, rápida y automatizada de hacer que ssh pruebe más claves en el directorio ~/.ssh dinámicamente al intentar iniciar sesión, o está editando su ~/.ssh/config para cada servidor que necesite? ¿Conectarse a la única forma de configurar ssh? ¿He entendido mal algo de lo anterior sobre cómo se supone que funciona SSH?

Respuesta1

Si desea ofrecer las mismas claves a todos los hosts, cárguelas en un agente SSH usando ssh-add. Muchas distribuciones de Linux inician una automáticamente; intente ssh-add -lverificar si se está ejecutando y luego cargue sus claves:

ssh-add ~/.ssh/id_rsa ~/.ssh/surnameg etc.

Si el agente no se inició automáticamente, coloque lo siguiente en su ~/.profile:

agent_running() {
    [ "$SSH_AUTH_SOCK" ] && { ssh-add -l >/dev/null 2>&1 || [ $? -eq 1 ]; }
}

env=~/.ssh/agent.env
if ! agent_running && [ -s "$env" ]; then
    . "$env" >/dev/null
fi
if ! agent_running; then
    ssh-agent >"$env"
    . "$env" >/dev/null
    ssh-add ~/.ssh/id_*
fi    
unset env

Respuesta2

Hay otro enfoque posible. Puede utilizar marcadores de posición en la IdentityFileopción en ssh_config. segúnman ssh_config:

  • %d—directorio de inicio del usuario local
  • %u—nombre de usuario local
  • %l—nombre de host local
  • %h—nombre de host remoto
  • %r—nombre de usuario remoto

Lo uso así (en el ssh_configarchivo global):

IdentityFile ~/.ssh/%r@%h

Esto significa que mis archivos de clave privada tienen nombres como [email protected].

información relacionada