Copier la clé ssh sur une autre machine pour que je puisse utiliser GitHub?
J'ai un serveur distant. Je peux déjà ssh avec succès sur ce serveur distant - ma clé est en authorized_keys sur le serveur distant.
Maintenant, je veux tirer de GitHub directement sur ce serveur distant. Mais je reçois permission denied (publickey) lorsque j'essaie ssh -T [email protected] sur le serveur distant.
Dois-je copier id_rsa.pub directement depuis mon ordinateur local sur le serveur distant, ou est-ce dangereux?
Si telle est la réponse, quelle est la meilleure façon de le faire?
Ou devrais-je générer une nouvelle clé publique sur le serveur distant et l'ajouter à mon compte github?
METTRE À JOUR:
Voici la sortie d'un ssh bavard:
~$ ssh -Tv [email protected]
OpenSSH_6.0p1 Debian-4+deb7u2, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to github.com [192.30.252.131] port 22.
debug1: Connection established.
debug1: identity file /home/richard/.ssh/id_rsa type -1
debug1: identity file /home/richard/.ssh/id_rsa-cert type -1
debug1: identity file /home/richard/.ssh/id_dsa type -1
debug1: identity file /home/richard/.ssh/id_dsa-cert type -1
debug1: identity file /home/richard/.ssh/id_ecdsa type -1
debug1: identity file /home/richard/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version libssh-0.6.0
debug1: no match: libssh-0.6.0
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-sha1 none
debug1: kex: client->server aes128-ctr hmac-sha1 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server Host key: RSA 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48
debug1: Host 'github.com' is known and matches the RSA Host key.
debug1: Found key in /home/richard/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/richard/.ssh/id_rsa
debug1: Trying private key: /home/richard/.ssh/id_dsa
debug1: Trying private key: /home/richard/.ssh/id_ecdsa
debug1: No more authentication
le id_rsa.pub peut être copié n’importe où sans risque réel. Ceci est votre clé publique et est destinée à des choses comme celle-ci. Il s’agit d’une moitié de paire de clés et le fait de la laisser fonctionner avec les endroits auxquels vous souhaitez accéder est le moyen par lequel vous laissez la clé privée fonctionner.
Pour permettre la connexion à distance, votre clé publique doit être répertoriée dans authorized_keys (authorized_keys2 sur certains systèmes). Une clé sur chaque ligne, dans ce format:
ssh-rsa AAAIHAVEREMOVEDTHEMAJORITYOFTHEKEYBECAUSEISEENONEEDTOPOSTTHATWALLOFTEXTHERE9yfRjxw== jarmund@jarmint
Pour ce faire, une fois que vous l'avez copié, ajoutez-le simplement au fichier authorized_keys comme ceci: cat id_rsa.pub >> ~/.ssh/authorized_keys
La plupart des systèmes sains refuseront lâchement de vous autoriser à utiliser une connexion basée sur une clé si le dossier .ssh a des autorisations trop lâches. Le dossier devrait être 700, donc si vous rencontrez toujours des problèmes: chmod 700 ~/.ssh
De plus, les fichiers du dossier .ssh doivent être 600: chmod 600 ~/.ssh
Éditer 1:
Le fichier lui-même, id_rsa.pub, n'est pas requis sur le serveur distant. Seul le contenu, dans le cadre de authorized_keys. Je recommande d'exécuter ssh -vT [email protected] pour activer la journalisation détaillée, afin que vous puissiez voir exactement les autorisations dont il se plaint.
Éditer 2:
Cela signifie qu'aucune des clés proposées ne correspond à celle du serveur distant. Ce que vous voulez voir ressemble à ceci:
debug1: Offering RSA public key: /home/jarmund/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 535
Choses à vérifier:
- Assurez-vous que l'une des clés privées est celle qui correspond à la clé publique que vous avez ajoutée à la
authorized_keysà distance - Assurez-vous que la clé correspond au nom d'utilisateur avec lequel vous essayez de vous connecter (cela devrait être la dernière partie de la clé publique)
- Essayez de renommer
authorized_keysenauthorized_keys2
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/richard/.ssh/id_rsa
debug1: Trying private key: /home/richard/.ssh/id_dsa
debug1: Trying private key: /home/richard/.ssh/id_ecdsa
debug1: No more authentication
Selon votre trace de débogage, aucun de ces fichiers de clés n'existe réellement sur le système local et ssh n'offrait aucune clé au serveur distant. Assurez-vous que la clé que vous souhaitez utiliser existe réellement sur l'hôte sur lequel vous exécutez ssh et que le fichier porte le bon nom. Si vous souhaitez utiliser un fichier de clé autre que l'un des fichiers par défaut, vous devez le spécifier sur la ligne de commande ssh:
ssh -i /path/to/some_key -Tv [email protected]
Le serveur a besoin de votre clé privée pour s’authentifier auprès de Github. Comme son nom l'indique, votre clé publique est considérée comme publique et ne peut donc pas suffire à s'authentifier.
Si vous n'avez pas besoin d'utiliser Github sur le serveur distant sans vous être connecté via ssh, vous devez utiliser le transfert ssh-agent. Un guide pour cela est disponible sur Github: https://developer.github.com/guides/using-ssh-agent-forwarding/ .
Sinon, vous devez générer une nouvelle clé et la lier à votre compte.
Vous pouvez directement mettre la commande.
$ cat ~/.ssh/id_rsa.pub
si vous avez la clé ssh déjà présente, elle la montrera. Sinon, cela donne une erreur. Vous devez ajouter une nouvelle clé.