Lösung 1:
Derselbe SSH-Schlüssel sollte von mehreren Clients verwendet werden können. Ich habe verschiedene SSH-Schlüssel für verschiedene Netzwerke und sie sind tatsächlich auf einem verschlüsselten USB-Laufwerk gespeichert, das ich problemlos von mehreren verschiedenen Computern aus verwende.
SSH ist sehr wählerisch in Bezug auf Dateiberechtigungen, daher würde ich zuerst alle Berechtigungen von /home/{user} überprüfen bis hinunter zur id_rsa Datei selbst.
SSH kümmert sich nicht wirklich um Gruppen- oder World-Schreibberechtigungen, stellen Sie also sicher, dass Sie chmod go-w Ihr Home-Verzeichnis und die ~/.ssh Verzeichnis für den Anfang. Ich würde auch sicherstellen, dass sie Ihrem Benutzer chown ${USER}:${USER} gehören .
Für den SSH-Schlüssel selbst habe ich chmod 600 sie...
Wenn Sie möchten, habe ich zusätzliche Informationen darüber, wie ich meine SSH-Schlüssel verwalte, in meiner Antwort auf eine andere SSH-Frage.
Lösung 2:
Wenn Ihnen von Github die Berechtigung verweigert wird, kann es sein, dass es nicht Ihre kopierte SSH-Schlüsseldatei aufnimmt, sondern den Systemstandard. Ein einfacher Weg, dies zu umgehen, ist ein ~/.ssh/config Datei und fügen Sie Folgendes ein:
Host github.com
Hostname github.com
User git
IdentityFile ~/.ssh/yourkeyfile
Dadurch wird Ihr SSH-Client gezwungen, diesen Schlüssel nur für github.com zu verwenden.
Hoffe das hilft.
Lösung 3:
Ich weiß, das ist alt, aber ich wollte darauf hinweisen, dass Sie auch die Öffentlichkeit kopieren müssen Schlüssel zum zweiten Client
(oder neu berechnen mit ssh-keygen -y -f ~/.ssh/id_rsa_..> ~/.ssh/id_rsa...pub)
Von [1]:
-
Authentifizierungsmethode mit öffentlichem Schlüssel:"publickey"
Der einzige ERFORDERLICHE Authentifizierungs-'Methodenname' ist "publickey".
Authentifizierung. Alle Implementierungen MÜSSEN diese Methode unterstützen;
jedoch müssen nicht alle Benutzer über öffentliche Schlüssel verfügen, und die meisten sind lokal
Es ist unwahrscheinlich, dass Richtlinien für alle eine Public-Key-Authentifizierung erfordern
Benutzer in naher Zukunft.Bei dieser Methode dient der Besitz eines privaten Schlüssels als
Authentifizierung. Diese Methode funktioniert durch Senden einer erstellten Signatur
mit einem privaten Schlüssel des Benutzers. Der Server MUSS überprüfen, ob der Schlüssel
ein gültiger Authentifikator für den Benutzer ist, und MUSS überprüfen, ob die
Unterschrift gültig. Wenn beide zutreffen, MUSS die Authentifizierungsanfrage erfolgen
akzeptiert; andernfalls MUSS es abgelehnt werden. Beachten Sie, dass der Server KANN
erfordern nach erfolgreicher Authentifizierung zusätzliche Authentifizierungen.
Ihr ssh-Client beginnt die Authentifizierung, indem er den öffentlichen Schlüssel (die Signatur, auf die oben in Fettdruck verwiesen wird) an den Server sendet. Wenn der öffentliche Schlüssel ein autorisierter Schlüssel ist, sendet der Server eine zufällige Sitzungs-ID an Ihren Client zurück. Ihr Client codiert dann diese Sitzungs-ID mit dem privaten Schlüssel und sendet diese an den Server zurück. Der Server entschlüsselt diese Sitzungs-ID mithilfe des öffentlichen Schlüssels und authentifiziert Ihren Client, wenn er mit der ursprünglichen Sitzungs-ID übereinstimmt.
[1] [http://www.openssh.org/txt/rfc4252.txt][1]