La mejor manera de usar múltiples claves privadas SSH en un cliente


872

Quiero usar varias claves privadas para conectarme a diferentes servidores o diferentes porciones del mismo servidor (mis usos son la administración del sistema del servidor, la administración de Git y el uso normal de Git dentro del mismo servidor). Intenté simplemente apilar las claves en los id_rsaarchivos en vano.

Aparentemente, una forma sencilla de hacerlo es usar el comando

ssh -i <key location> login@server.example.com 

Eso es bastante engorroso.

¿Alguna sugerencia sobre cómo hacer esto un poco más fácil?


1
Escribí este artículo que profundiza en varias configuraciones y sus fortalezas / deficiencias.
Raffi

Respuestas:


1235

De mi .ssh/config:

Host myshortname realname.example.com
    HostName realname.example.com
    IdentityFile ~/.ssh/realname_rsa # private key for realname
    User remoteusername

Host myother realname2.example.org
    HostName realname2.example.org
    IdentityFile ~/.ssh/realname2_rsa  # different private key for realname2
    User remoteusername

Y así.


25
Gracias Randal! Hice un poco de investigación en .ssh / config y encontré esto: github.com/guides/multiple-github-accounts Me señaló en la dirección correcta.
Justin

66
Esta fue una gran ayuda (además de stackoverflow.com/a/3828682/169153 ). Si desea usar masillas, siga este documento aquí: blog.padraigkitterick.com/2007/09/16/…
Urda

2
Encontré esta publicación muy útil. Un error que cometí al crear el archivo de configuración fue que puse un archivo .txt en la carpeta .ssh en lugar de ejecutar el comando "touch" para crear un archivo de configuración.
M_x_r

53
Tenga en cuenta que también puede especificar varias IdentityFileentradas para el mismo Host, que luego se prueban en orden al conectarse.
sschuberth

12
Se usa IdentitiesOnly yespara evitar ~ / .ssh / id_rsa o cualquier otra identidad. (Esto originalmente era una edición)
user3338098

371

Puede indicar a ssh que intente varias claves sucesivas al conectarse. Así es cómo:

$ cat ~/.ssh/config
IdentityFile ~/.ssh/id_rsa
IdentityFile ~/.ssh/id_rsa_old
IdentityFile ~/.ssh/id_ed25519
# ... and so on

$ ssh server.example.com -v
....
debug1: Next authentication method: publickey
debug1: Trying private key: /home/example/.ssh/id_rsa
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/example/.ssh/id_rsa_old
debug1: read PEM private key done: type RSA
....
[server ~]$

De esta manera, no tiene que especificar qué clave funciona con qué servidor. Solo usará la primera tecla de trabajo.

Además, solo ingresaría una frase de contraseña si un servidor determinado está dispuesto a aceptar la clave. Como se vio anteriormente, ssh no intentó pedir una contraseña, .ssh/id_rsaincluso si la tenía.

Seguramente no supera una configuración por servidor como en otras respuestas, pero al menos no tendrá que agregar una configuración para todos y cada uno de los servidores a los que se conecta.


13
Esta es una solución fantástica para la pregunta formulada, pero no satisfizo las necesidades que pretendía el autor de la pregunta. Para mí, fue exactamente la solución correcta y satisface perfectamente la necesidad de la "Mejor manera de usar múltiples claves privadas SSH en un cliente".
Wade

2
Esto no parece funcionar bajo la declaración de Host en el archivo de configuración
Maksim Luzik

30
Esto no funciona bien con git, ya que si tiene dos claves de implementación de github, la primera de la lista es válida y funcionará, pero luego github se quejará de que el repositorio no coincide.
Adam Reis

1
Si el servidor SFTP / target tiene políticas de seguridad que bloquean la cuenta (digamos después de 3 intentos de conexión fallidos múltiples), esto no terminaría bloqueando la cuenta. Se intenta una conexión, pero con un archivo de "clave incorrecta"
alchemist.gamma

77
Tenga en cuenta si tiene algo como fail2ban en esos servidores. Podría terminar en una de esas cárceles ... debido a los intentos fallidos generados por las otras llaves ...
Piccolo

254

La respuesta de Randal Schwartz casi me ayudó en todo momento. Tengo un nombre de usuario diferente en el servidor, así que tuve que agregar la palabra clave Usuario a mi archivo:

Host           friendly-name
HostName       long.and.cumbersome.server.name
IdentityFile   ~/.ssh/private_ssh_file
User           username-on-remote-machine

Ahora puedes conectarte usando el nombre descriptivo:

ssh friendly-name

Se pueden encontrar más palabras clave en la página de manual de OpenSSH . NOTA: Algunas de las palabras clave enumeradas pueden estar presentes en su archivo / etc / ssh / ssh_config .


Si no me equivoco, el usuario que normalmente especifica directamente en la URL al conectarse con el usuario @ host
a1an

3
Prefiero usar la palabra clave 'Puerto' también. Otra palabra clave interesante es 'StrictHostKeyChecking'.
Ethan

122

Las respuestas anteriores han explicado correctamente la forma de crear un archivo de configuración para administrar múltiples claves ssh. Creo que lo importante que también debe explicarse es la sustitución de un nombre de host con un nombre de alias mientras se clona el repositorio .

Supongamos que el nombre de usuario de la cuenta de GitHub de su empresa es abc1234 . Y supongamos que el nombre de usuario de su cuenta personal de GitHub es jack1234

Y, supongamos que ha creado dos claves RSA, a saber, id_rsa_company e id_rsa_personal . Por lo tanto, su archivo de configuración se verá a continuación:

# Company account
Host company
HostName github.com
PreferredAuthentications publickey
IdentityFile ~/.ssh/id_rsa_company

# Personal account
Host personal
HostName github.com
PreferredAuthentications publickey
IdentityFile ~/.ssh/id_rsa_personal

Ahora, cuando clona el repositorio (denominado demo) de la cuenta de GitHub de la compañía, la URL del repositorio será algo así como:

Repo URL: git@github.com:abc1234/demo.git

Ahora, mientras lo hace git clone, debe modificar la URL del repositorio anterior como:

git@company:abc1234/demo.git

Observe cómo github.com ahora se reemplaza con el alias "compañía" como hemos definido en el archivo de configuración.

De manera similar, debe modificar la URL de clonación del repositorio en la cuenta personal según el alias proporcionado en el archivo de configuración.


10
Desearía poder votar esta respuesta más de una vez ... esta es la forma correcta de abordar el problema, y ​​es más segura y rápida que otras opciones. Más escalable también (permite definir diferentes claves para el mismo nombre de host)
guyarad

44
No pierdas más tiempo, esta es LA respuesta. Muchas gracias.
Luis Milanese

2
Realmente desearía haber encontrado esta respuesta antes ... pero mejor tarde que nunca, ¡Muchas gracias!
Hildy

2
¡Gran explicación! Funciona perfecto para mi. Y si olvidó clonar el repositorio con el alias, a menudo puede editar la URL de origen remota después.
tkahn

1
solo paga la atención porque el archivo de configuración debe ser (chmod 600)
Christiano Matos

106
ssh-add ~/.ssh/xxx_id_rsa

Asegúrese de probarlo antes de agregar con:

ssh -i ~/.ssh/xxx_id_rsa username@example.com

Si tiene algún problema con los errores, a veces, cambiar la seguridad del archivo ayuda:

chmod 0600 ~/.ssh/xxx_id_rsa

44
Esta es la solución más sucinta y elegante en mi opinión. ¡Trabajado como un encanto!
artur

@Bobo, ¿puede ponerlo en su bashrc o bash_profile (o lo que sea el equivalente de mac)?
T0xicCode

66
+1 para chmod 0600 - los problemas de permisos me impedían conectarme
amacy

Funcionó como un encanto para mí (y no te olvides de las 0600 permanentes).
Dmytro Uhnichenko

1
Vino de ubuntu en mac y esto era exactamente lo que necesitaba.
hariom

42
  1. Genere una clave SSH:

    $ ssh-keygen -t rsa -C <email1@example.com>
    
  2. Genere otra clave SSH :

    $ ssh-keygen -t rsa -f ~/.ssh/accountB -C <email2@example.com>
    

    Ahora, deben existir dos claves públicas ( id_rsa.pub , accountB.pub ) en el ~/.ssh/directorio.

    $ ls -l ~/.ssh     # see the files of '~/.ssh/' directory
    
  3. Cree un archivo de configuración ~/.ssh/configcon los siguientes contenidos:

    $ nano ~/.ssh/config
    
    Host bitbucket.org
        User git
        Hostname bitbucket.org
        PreferredAuthentications publickey
        IdentityFile ~/.ssh/id_rsa
    
    Host bitbucket-accountB
        User git
        Hostname bitbucket.org
        PreferredAuthentications publickey
        IdentitiesOnly yes
        IdentityFile ~/.ssh/accountB
    
  4. Clonar de la defaultcuenta.

    $ git clone git@bitbucket.org:username/project.git
    
  5. Clonar de la accountBcuenta.

    $ git clone git@bitbucket-accountB:username/project.git
    

Ver más aquí


24

Estoy de acuerdo con Tuomas sobre el uso de ssh-agent. También quería agregar una segunda clave privada para el trabajo y este tutorial funcionó de maravilla para mí.

Los pasos son los siguientes:

  1. $ ssh-agent bash
  2. $ ssh-add /path.to/private/key p.ej ssh-add ~/.ssh/id_rsa
  3. Verificar por $ ssh-add -l
  4. Pruébelo con, $ssh -v <host url>por ejemplossh -v git@assembla.com

44
Después de haberlo usado ssh-agentdurante años, recientemente cambié a usar Gnome's gnome-keyringdentro de mi i3wm. La razón es simple: el administrador de llaveros de Gnome maneja automáticamente la adición y eliminación de claves ssh sin que tenga que recordarlo ssh-add. Además, me proporcionó una contraseña única para desbloquearlos (y tiempo de espera en un tiempo específico, por seguridad). A cada uno lo suyo. Como uso la configuración de gnome en Arch, fue plug and play con mi configuración. Si eres anti-gnomo, ignora este comentario.
eduncan911

@ eduncan911, estoy de acuerdo en que gnome-keyring puede ser útil, pero en realidad no maneja las claves ed25519, por lo que para mí no es un principiante. Actualización: veo en wiki.archlinux.org/index.php/GNOME/… que ahora usa el agente ssh del sistema, por lo que ya no es un problema.
Brian Minton

15

Me encontré con este problema hace un tiempo, cuando tenía dos cuentas de Bitbucket y quería tener que almacenar claves SSH separadas para ambas. Esto es lo que funcionó para mí.

Creé dos configuraciones ssh separadas de la siguiente manera.

Host personal.bitbucket.org
    HostName bitbucket.org
    User git
    IdentityFile /Users/username/.ssh/personal
Host work.bitbucket.org
    HostName bitbucket.org
    User git
    IdentityFile /Users/username/.ssh/work

Ahora, cuando tenía que clonar un repositorio de mi cuenta de trabajo, el comando era el siguiente.

git clone git@bitbucket.org:teamname/project.git

Tuve que modificar este comando para:

git clone git@**work**.bitbucket.org:teamname/project.git

Del mismo modo, el comando clonar de mi cuenta personal tuvo que modificarse para

git clone git @ personal .bitbucket.org: nombre / personalproject.git

Consulte este enlace para más información.



11

Ahora, con la versión reciente de Git, podemos especificar sshCommand en el archivo de configuración de Git específico del repositorio:

  [core]
      repositoryformatversion = 0
      filemode = true
      bare = false
      logallrefupdates = true
      sshCommand = ssh -i ~/.ssh/id_rsa_user
   [remote "origin"]
      url = git@bitbucket.org:user/repo.git
      fetch = +refs/heads/*:refs/remotes/origin/*

1

Puede crear un archivo de configuración con nombre configen su ~/.sshcarpeta. Puede contener:

Host aws
    HostName *yourip*
    User *youruser*
    IdentityFile *idFile*

Esto te permitirá conectarte a máquinas como esta

 ssh aws

¿Qué forma toma idFile? Un camino absoluto. ¿Puedes dar un ejemplo
Peter Mortensen

1

IMPORTANTE: debe iniciar ssh-agent

Debe iniciar ssh-agent (si aún no se está ejecutando) antes de usar ssh-add de la siguiente manera:

eval `ssh-agent -s` # start the agent

ssh-add id_rsa_2 # Where id_rsa_2 is your new private key file

Tenga en cuenta que el comando eval inicia el agente en Git Bash en Windows. Otros entornos pueden usar una variante para iniciar el agente SSH.


1

En Ubuntu 18.04 (Bionic Beaver) no hay nada que hacer.

Después de haber creado una segunda clave SSH con éxito, el sistema intentará encontrar una clave SSH coincidente para cada conexión.

Para que quede claro, puede crear una nueva clave con estos comandos:

# Generate key make sure you give it a new name (id_rsa_server2)
ssh-keygen

# Make sure ssh agent is running
eval `ssh-agent`

# Add the new key
ssh-add ~/.ssh/id_rsa_server2

# Get the public key to add it to a remote system for authentication
cat ~/.ssh/id_rsa_server2.pub

1

Múltiples pares de claves en GitHub

1.0 archivo de configuración SSH

1.1 Crear ~ / .ssh / config

1.2 chmod 600 ~ / .ssh / config ( debe )

1.3 Ingrese lo siguiente en el archivo:

Anfitriona de pizza

HostName github.com

Autenticaciones preferidas publickey # opcional

IdentityFile ~ / .ssh / privatekey1

Caso A: nuevo y fresco clon de Git

Use este comando para clonar Git:

$ git clone git@pizza:yourgitusername/pizzahut_repo.git

Nota: Si desea cambiar el nombre de host "pizza" de .ssh / config en el futuro, vaya a la carpeta clonada Git, edite la línea URL del archivo .git / config (vea el caso B)

Caso B: ya tengo la carpeta de clonación Git

2.1 Vaya a la carpeta clonada y luego vaya a la carpeta .git

2.2 Editar archivo de configuración

2.3 Actualice la URL de * antiguo a nuevo :

(Old) URL = git@github.com:yourgitusername/pizzahut_repo.git

(New) URL = git@pizza:yourgitusername/pizzahut_repo.git


1

Para mí, la única solución de trabajo era simplemente agregar esto en el archivo ~/.ssh/config:

Host *
  IdentityFile ~/.ssh/your_ssh_key
  IdentityFile ~/.ssh/your_ssh_key2
  IdentityFile ~/.ssh/your_ssh_key3
  AddKeysToAgent yes

your_ssh_keyEs sin ninguna extensión. No utilice .pub.


0

En CentOS 6.5 con OpenSSH_5.3p1 y OpenSSL 1.0.1e-fips, resolví el problema cambiando el nombre de mis archivos clave para que ninguno de ellos tuviera el nombre predeterminado.

Mi directorio .ssh contiene id_rsa_foo e id_rsa_bar, pero no id_rsa, etc.


¿Y cómo se usan las teclas? ¿Hay alguna autodetección?
robsch

Vea la respuesta de Randal Schwartz para una forma de seleccionar la clave correcta para un host dado stackoverflow.com/questions/2419566/…
Chris Owens

Sí, eso lo hace más explícito. Incluso usar la -iopción puede resultar en algo así no such identity: /home/embo/.ssh/id_rsa: No such file or directory.
Peter Mortensen

0

Como se menciona en una página de blog de Atlassian , genere un archivo de configuración dentro de la carpeta .ssh , que incluya el siguiente texto:

#user1 account
 Host bitbucket.org-user1
     HostName bitbucket.org
     User git
     IdentityFile ~/.ssh/user1
     IdentitiesOnly yes

 #user2 account
 Host bitbucket.org-user2
     HostName bitbucket.org
     User git
     IdentityFile ~/.ssh/user2
     IdentitiesOnly yes

Luego, simplemente puede pagar con el dominio de sufijo y dentro de los proyectos puede configurar los nombres de los autores, etc. localmente.


0

Aquí está la solución que utilicé inspirada en la respuesta de sajib-khan . La configuración predeterminada no está establecida; es mi cuenta personal en GitLab y la otra especificada es la cuenta de mi empresa. Aquí esta lo que hice:

Generar la clave SSH

ssh-keygen -t rsa -f ~/.ssh/company -C "name.surname@company.com"

Edite la configuración SSH

nano ~/.ssh/config
    Host company.gitlab.com
    HostName gitlab.com
    PreferredAuthentications publickey
    IdentityFile ~/.ssh/company

Eliminar las claves SSH almacenadas en caché

ssh-add -D

¡Pruébalo!

ssh -T git@company.gitlab.com

¡Bienvenido a GitLab, @ hugo.sohm!

ssh -T git@gitlab.com

¡Bienvenido a GitLab, @HugoSohm!

Úsalo!

Cuenta de la compañia

git clone git@company.gitlab.com:group/project.git

Cuenta personal / predeterminada

git clone git@gitlab.com:username/project.git

Aquí está la fuente que usé.


0

Me encanta el enfoque para establecer lo siguiente en el archivo ~ / .ssh / config:

# Configuration for GitHub to support multiple GitHub  keys
Host  github.com
  HostName github.com
  User git

# UseKeychain adds each keys passphrase to the keychain so you
# don't have to enter the passphrase each time.
  UseKeychain yes

# AddKeysToAgent would add the key to the agent whenever it is
# used, which might lead to debugging confusion since then
# sometimes the one repository works and sometimes the
# other depending on which key is used first.
#  AddKeysToAgent yes

# I only use my private id file so all private
# repositories don't need the environment variable
# `GIT_SSH_COMMAND="ssh -i ~/.ssh/id_rsa"` to be set.
  IdentityFile ~/.ssh/id_rsa

Luego, en su repositorio, puede crear un .envarchivo que contenga el sshcomando que se utilizará:

GIT_SSH_COMMAND="ssh -i ~/.ssh/your_ssh_key"

Si luego usa, por ejemplo, dotenv, la variable de entorno del entorno se exporta automáticamente y whoop whoop, puede especificar la clave que desea por proyecto / directorio. La frase de contraseña se solicita solo una vez, ya que se agrega al llavero.

Esta solución funciona perfectamente con Git y está diseñada para funcionar en una Mac (debido a UseKeychain).


-1

Puede probar este paquete sshmulti npm para mantener varias claves SSH.


Recomiendo no usar npm para algo como esto. Tenía una cascada de dependencias, que, en una breve inspección, incluyen una gama de desarrolladores de lobos solitarios, paquetes de varios años. La propia página sshmulti npm declara que no ha sido probada.
Jack Wasey
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.