web-dev-qa-db-fra.com

Utilisation de la même clé privée SSH sur plusieurs machines

J'ai un dépôt Github auquel je veux accéder à partir de deux machines Linux différentes.

Pour la première machine, j'ai suivi les instructions de Github pour générer des clés SSH, et ajouté la clé publique résultante à Github. Ce client fonctionne bien.

Pour le deuxième client, j'ai copié le /home/{user}/.ssh/id_rsa fichier du premier client. Je pensais que c'était peut-être tout ce que j'avais à faire, mais lorsque j'essaie de me connecter, je reçois "Autorisation refusée (publickey)".

Qu'est-ce que je rate?

linuxsshgithub
26
Yarin

La même clé SSH doit pouvoir être utilisée à partir de plusieurs clients. J'ai différentes clés SSH pour différents réseaux et elles sont en fait stockées sur un lecteur USB crypté que j'utilise depuis plusieurs ordinateurs différents sans problème.

SSH est très pointilleux sur les autorisations de fichiers, donc je vérifierais d'abord toutes les autorisations de /home/{user} Jusqu'au fichier id_rsa Lui-même.

SSH ne se soucie pas vraiment des autorisations d'écriture de groupe ou du monde, alors assurez-vous que chmod go-w Votre répertoire personnel et le répertoire ~/.ssh Pour les débutants. Je m'assurerais également qu'ils appartiennent à votre utilisateur chown ${USER}:${USER}.

Pour la clé SSH elle-même, je chmod 600 Les ...

Si vous voulez, j'ai des informations supplémentaires sur la façon dont je gère mes clés SSH dans mon réponse à une autre question SSH.

35
Jeremy Bouse

Si vous obtenez une autorisation refusée de la part de Github, il se peut qu'il ne récupère pas votre fichier de clé SSH copié, mais plutôt la valeur par défaut du système. Un moyen simple de contourner ce problème est de _ ~/.ssh/config fichier et y mettre les éléments suivants:

Host github.com
  Hostname      github.com
  User          git
  IdentityFile  ~/.ssh/yourkeyfile

Cela forcera votre client SSH à utiliser cette clé uniquement pour github.com.

J'espère que cela t'aides.

7
vmfarms

Je sais que c'est ancien, mais j'ai pensé que vous devez également copier la clé publique sur le deuxième client

(ou recalculez-le avec ssh-keygen -y -f ~/.ssh/id_rsa_ ..> ~/.ssh/id_rsa ... pub)

À partir de 1]:

  1. Méthode d'authentification par clé publique: "publickey"

    Le seul "nom de méthode" d'authentification REQUIS est "publickey"
    authentification. Toutes les implémentations DOIVENT prendre en charge cette méthode;
    cependant, tous les utilisateurs n'ont pas besoin de clés publiques, et la plupart des utilisateurs locaux
    Les politiques ne sont pas susceptibles d'exiger une authentification par clé publique pour tous
    utilisateurs dans un avenir proche.

    Avec cette méthode, la possession d'une clé privée sert de
    authentification. Cette méthode fonctionne en envoyant une signature créée
    avec une clé privée de l'utilisateur. Le serveur DOIT vérifier que la clé
    est un authentificateur valide pour l'utilisateur et DOIT vérifier que le
    La signature est valide. Si les deux sont valides, la demande d'authentification DOIT être
    accepté; sinon, il DOIT être rejeté. Notez que le serveur PEUT
    nécessitent des authentifications supplémentaires après une authentification réussie.

Votre client ssh commence l'authentification en envoyant la clé publique (la signature référencée en gras ci-dessus) au serveur. Le serveur, si la clé publique est une clé autorisée, renvoie un ID de session aléatoire à votre client. Votre client code ensuite cet ID de session avec la clé privée et le renvoie au serveur. Le serveur décode cet ID de session à l'aide de la clé publique et, s'il correspond à l'ID de session d'origine, authentifie votre client.

[1] [ http://www.openssh.org/txt/rfc4252.txt] [1]

2
Jacob Church

C'est probablement parce que vous n'avez pas copié l'autorisation du fichier sur le deuxième client.
Mais une clé privée est privée, la bonne façon est de créer une nouvelle clé privée sur le deuxième client, puis d'ajouter sa clé publique à Github

0
radius