Solution 1 :
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 une clé USB cryptée que j'utilise sans problème à partir de plusieurs ordinateurs différents.
SSH est très pointilleux sur les autorisations de fichiers, je vérifierais donc d'abord toutes les autorisations de /home/{user} jusqu'au id_rsa fichier lui-même.
SSH ne se soucie pas vraiment des autorisations d'écriture de groupe ou de monde, alors assurez-vous d'avoir chmod go-w votre répertoire personnel et le ~/.ssh répertoire pour les débutants. Je m'assurerais également qu'ils appartiennent à votre utilisateur chown ${USER}:${USER} .
Pour la clé SSH elle-même, j'ai chmod 600 eux...
Si vous le souhaitez, j'ai des informations supplémentaires sur la façon dont je gère mes clés SSH dans ma réponse à une autre question SSH.
Solution 2 :
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 d'obtenir un excellent ~/.ssh/config fichier et mettez-y ce qui suit :
Host github.com
Hostname github.com
User git
IdentityFile ~/.ssh/yourkeyfile
Cela forcera votre client SSH à utiliser cette clé pour github.com uniquement.
J'espère que cela vous aidera.
Solution 3 :
Je sais que c'est vieux, mais j'ai pensé que je ferais remarquer que vous devez également copier le public clé du second client
(ou recalculez-le avec ssh-keygen -y -f ~/.ssh/id_rsa_..> ~/.ssh/id_rsa...pub)
À partir de [1] :
Méthode d'authentification par clé publique :"publickey"
Le seul "nom de méthode" d'authentification OBLIGATOIRE est "clé publique"
authentification. Toutes les implémentations DOIVENT prendre en charge cette méthode;
cependant, tous les utilisateurs n'ont pas besoin d'avoir des clés publiques, et la plupart des utilisateurs locaux
les politiques ne sont pas susceptibles d'exiger l'authentification par clé publique pour tous
utilisateurs dans un futur 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 authentifiant valide pour l'utilisateur, et DOIT vérifier que le
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
exiger 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 encode 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, il authentifie votre client.
[1] [http://www.openssh.org/txt/rfc4252.txt][1]