multiple - ssh config github host

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

Question

Quiero usar varias claves privadas para conectarse a diferentes servidores o diferentes partes 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 archivos id_rsa en vano.

Aparentemente, una forma sencilla de hacer esto es usar el comando

ssh -i <key location> [email protected]

Eso es bastante engorroso.

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

Answer 1

1. Generar clave SSH:

   $ ssh-keygen -t rsa -C <[email protected]>

2. Generar another SSH key :

   $ ssh-keygen -t rsa -f ~/.ssh/accountB -C <[email protected]>

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

   $ ls -l ~/.ssh # see the files of ''~/.ssh/'' directory

3. Cree el archivo de configuración ~/.ssh/config con el siguiente contenido:

   $ 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. Clone desde la cuenta por default .

   $ git clone [email protected]:username/project.git

5. Clonar desde cuenta accountB

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

Ver más aquí

Answer 2

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

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

Answer 3

Desde 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
User remoteusername

Y así.

Answer 4

En Centos 6.5 ejecutando OpenSSH_5.3p1, OpenSSL 1.0.1e-fips, resolví el problema cambiando el nombre de mis archivos de claves 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.

Answer 5

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ó como un encanto para mí.

Los pasos son los siguientes:

1. $ ssh-agent bash
2. $ ssh-add /path.to/private/key por ejemplo, ssh-add ~/.ssh/id_rsa
3. Verificar por $ ssh-add -l
4. ssh -v [email protected] con $ssh -v <host url> por ejemplo, ssh -v [email protected]

Answer 6

La respuesta de Randal Schwartz casi me ayudó en todo el camino. Tengo un nombre de usuario diferente en el servidor, así que tuve que agregar la palabra clave de 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 amigable:

ssh friendly-name

Más palabras clave se pueden encontrar en la página de manual de OpenSSH . NOTA: Es posible que algunas de las palabras clave enumeradas ya estén presentes en su archivo / etc / ssh / ssh_config .

Answer 7

Las respuestas anteriores han explicado correctamente la forma de crear un archivo de configuración para administrar varias claves ssh. Creo que lo importante que también debe explicarse es el reemplazo de un nombre de host con un nombre de alias al clonar el repositorio .

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

Y, suponga 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 esté clonando el repositorio (llamado demo) de la cuenta de GitHub de la compañía, la URL del repositorio será algo así como:

Repo URL: [email protected]:abc1234/demo.git

Ahora, mientras 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.

Del mismo modo, debe modificar la URL de clonación del repositorio en la cuenta personal en función del alias proporcionado en el archivo de configuración.

Answer 8

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

He creado 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 tuve que clonar un repositorio de mi cuenta de trabajo, el comando era el siguiente.

git clone [email protected]:teamname/project.git

Tuve que modificar este comando para:

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

Del mismo modo, el comando de clonación de mi cuenta personal tuvo que ser modificado para

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

Consulte este enlace para más información.

Answer 9

Puede crear un archivo de configuración llamado config en su carpeta ~/.ssh . Puede contener:

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

Esto te permitirá conectarte a máquinas como esta.

 ssh aws

Answer 10

Puede indicar a ssh que intente varias teclas sucesivamente 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 utilizará la primera llave de trabajo.

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

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

Answer 11

Usa ssh-agent para tus llaves.

Answer 12

IMPORTANTE: Debes 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.

Answer 13

foo:~$ssh-add ~/.ssh/xxx_id_rsa

Asegúrate de probarlo antes de agregar con:

ssh -i ~/.ssh/xxx_id_rsa [email protected]

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

chmod 0600 ~/.ssh/xxx_id_rsa