Je souhaite utiliser plusieurs clés privées pour me connecter à différents serveurs ou à différentes parties du même serveur (mes utilisations sont l'administration système du serveur, l'administration de Git et l'utilisation normale de Git au sein du même serveur). J'ai essayé d'empiler simplement les clés dans les id_rsafichiers en vain.

Apparemment, un moyen simple de le faire est d'utiliser la commande

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

C'est assez lourd.

Avez-vous des suggestions sur la façon de procéder un peu plus facilement?

De mon .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

Etc.

Vous pouvez demander à ssh d'essayer plusieurs touches successivement lors de la connexion. Voici comment:

$ 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 cette façon, vous n'avez pas à spécifier quelle clé fonctionne avec quel serveur. Il utilisera simplement la première clé de travail.

Vous ne devez également saisir une phrase secrète que si un serveur donné est prêt à accepter la clé. Comme vu ci-dessus, ssh n'a pas essayé de demander un mot de passe .ssh/id_rsamême s'il en avait un.

Cela ne surpasse certainement pas une configuration par serveur comme dans les autres réponses, mais au moins vous n'aurez pas à ajouter une configuration pour tous les serveurs auxquels vous vous connectez!

La réponse de Randal Schwartz m'a presque aidé tout du long. J'ai un nom d'utilisateur différent sur le serveur, j'ai donc dû ajouter le mot-clé User à mon fichier:

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

Vous pouvez maintenant vous connecter en utilisant le nom convivial:

ssh friendly-name

D'autres mots clés peuvent être trouvés sur la page de manuel d'OpenSSH . REMARQUE: certains des mots clés répertoriés peuvent déjà être présents dans votre fichier / etc / ssh / ssh_config .

Les réponses précédentes ont correctement expliqué la façon de créer un fichier de configuration pour gérer plusieurs clés ssh. Je pense que la chose importante qui doit également être expliquée est le remplacement d'un nom d'hôte par un nom d'alias lors du clonage du référentiel .

Supposons que votre le nom d'utilisateur du compte GitHub de entreprise soit abc1234 . Et supposez que le nom d'utilisateur de votre compte GitHub personnel est jack1234

Et supposons que vous ayez créé deux clés RSA, à savoir id_rsa_company et id_rsa_personal . Donc, votre configuration fichier de ressemblera à ci-dessous:

# 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

Maintenant, lorsque vous clonez le référentiel (nommé démo) du compte GitHub de l'entreprise, l'URL du référentiel sera quelque chose comme:

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

Maintenant, en faisant cela git clone, vous devez modifier l'URL du référentiel ci-dessus comme:

git@company:abc1234/demo.git

Remarquez comment github.com est maintenant remplacé par l'alias "entreprise" comme nous l'avons défini dans le fichier de configuration.

De même, vous devez modifier l'URL de clonage du référentiel dans le compte personnel en fonction de l'alias fourni dans le fichier de configuration.

ssh-add ~/.ssh/xxx_id_rsa

Assurez-vous de le tester avant d'ajouter avec:

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

Si vous rencontrez des problèmes avec des erreurs, il peut parfois être utile de modifier la sécurité du fichier:

chmod 0600 ~/.ssh/xxx_id_rsa

1. Générez une clé SSH:

   $ ssh-keygen -t rsa -C <email1@example.com>
   

2. Générez une autre clé SSH :

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

   Maintenant, deux clés publiques ( id_rsa.pub , accountB.pub ) devrait être existe dans le ~/.ssh/répertoire.

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

3. Créez un fichier de configuration ~/.ssh/configavec le contenu suivant:

   $ 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. Cloner à partir du defaultcompte.

   $ git clone git@bitbucket.org:username/project.git
   

5. Clonez depuis le accountBcompte.

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

Voir plus ici

Je serais d'accord avec Tuomas sur l'utilisation de ssh-agent. Je voulais également ajouter une deuxième clé privée pour le travail et ce tutoriel a fonctionné comme un charme pour moi.

Les étapes sont les suivantes:

1. $ ssh-agent bash
2. $ ssh-add /path.to/private/key par exemple ssh-add ~/.ssh/id_rsa
3. Vérifier par $ ssh-add -l
4. Testez-le avec $ssh -v <host url>par exemplessh -v git@assembla.com

J'avais rencontré ce problème il y a quelque temps, quand j'avais deux comptes Bitbucket et que je voulais avoir à stocker des clés SSH distinctes pour les deux. C'est ce qui a fonctionné pour moi.

J'ai créé deux configurations ssh distinctes comme suit.

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

Maintenant, quand j'ai dû cloner un référentiel de mon compte professionnel - la commande était la suivante.

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

J'ai dû modifier cette commande pour:

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

De même, la commande de clonage de mon compte personnel a dû être modifiée pour

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

Reportez - vous à ce lien pour plus d'informations.

Utilisez ssh-agent pour vos clés.

Maintenant, avec la version récente de Git, nous pouvons spécifier sshCommand dans le fichier de configuration Git spécifique au référentiel:

  [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/*

Vous pouvez créer un fichier de configuration nommé configdans votre ~/.sshdossier. Il peut contenir:

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

Cela vous permettra de vous connecter à des machines comme celle-ci

 ssh aws

IMPORTANT: vous devez démarrer ssh-agent

Vous devez démarrer ssh-agent (s'il ne fonctionne pas déjà) avant d'utiliser ssh-add comme suit:

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

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

Notez que la commande eval démarre l'agent sur Git Bash sous Windows. D'autres environnements peuvent utiliser une variante pour démarrer l'agent SSH.

Sur Ubuntu 18.04 (Bionic Beaver), il n'y a rien à faire.

Après avoir créé une deuxième clé SSH avec succès, le système essaiera de trouver une clé SSH correspondante pour chaque connexion.

Juste pour être clair, vous pouvez créer une nouvelle clé avec ces commandes:

# 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

Plusieurs paires de clés sur GitHub

1.0 Fichier de configuration SSH

1.1 Créer ~ / .ssh / config

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

1.3 Saisissez les informations suivantes dans le fichier:

Pizza hôte

HostName github.com

PreferredAuthentications publickey # facultatif

IdentityFile ~ / .ssh / privatekey1

Cas A: nouveau clone de Git

Utilisez cette commande pour cloner Git:

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

Remarque: Si vous souhaitez modifier le nom d'hôte «pizza» de .ssh / config à l'avenir, accédez au dossier cloné Git, modifiez la ligne d'URL du fichier .git / config (voir le cas B)

Cas B: Vous avez déjà un dossier de clonage Git

2.1 Accédez au dossier cloné, puis accédez au dossier .git

2.2 Modifier le fichier de configuration

2.3 Mettez à jour l'URL de * ancien vers nouveau :

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

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

Pour moi, la seule solution de travail était d'ajouter simplement ceci dans le fichier ~/.ssh/config:

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

your_ssh_keyest sans aucune extension. Ne pas utiliser .pub.

Sur CentOS 6.5 exécutant OpenSSH_5.3p1 et OpenSSL 1.0.1e-fips, j'ai résolu le problème en renommant mes fichiers de clé afin qu'aucun d'entre eux n'ait le nom par défaut.

Mon répertoire .ssh contient id_rsa_foo et id_rsa_bar, mais pas id_rsa, etc.

Comme mentionné sur une page de blog Atlassian , générez un fichier de configuration dans le dossier .ssh , comprenant le texte suivant:

#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

Ensuite, vous pouvez simplement commander avec le domaine suffixe et dans les projets, vous pouvez configurer les noms des auteurs, etc. localement.

Voici la solution que j'ai utilisée inspirée de la réponse de sajib-khan . La configuration par défaut n'est pas définie; c'est mon compte personnel sur GitLab et l'autre spécifié est mon compte d'entreprise. Voici ce que j'ai fait:

Générez la clé SSH

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

Modifier la configuration SSH

nano ~/.ssh/config

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

Supprimer la ou les clés SSH mises en cache

ssh-add -D

Essaye-le!

ssh -T git@company.gitlab.com

Bienvenue sur GitLab, @ hugo.sohm!

ssh -T git@gitlab.com

Bienvenue sur GitLab, @HugoSohm!

Utilise le!

Compte d'entreprise

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

Compte personnel / par défaut

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

Voici la source que j'ai utilisée.

J'adore l'approche pour définir ce qui suit dans le fichier ~ / .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

Ensuite, dans votre référentiel, vous pouvez créer un .envfichier qui contient la sshcommande à utiliser:

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

Si vous utilisez ensuite par exemple dotenv, la variable d'environnement d'environnement est exportée automatiquement et whoop whoop, vous pouvez spécifier la clé souhaitée par projet / répertoire. La phrase secrète n'est demandée qu'une seule fois car elle est ajoutée au trousseau.

Cette solution fonctionne parfaitement avec Git et est conçue pour fonctionner sur un Mac (en raison de UseKeychain).

Vous pouvez essayer ce package sshmulti npm pour gérer plusieurs clés SSH.