Transfert clé privée sur nouveau PC ?

Bonjour,

J’aimerais savoir comment peut-on faire pour transferer sa clé privée utilisée sur un pc sur un nouveau pc s’il vous plaît ?

Merci d’avance

Quelle “clé privée” ?

Celle du login ? celle de root ? celle du montage crypté ? celle de ssh ?
celle d’un vnc ? celle d’un partage samba ? celle d’un compte de courrier ? …

En utilisant la commande ssh-copy-id peut être??

C’est la clé ssh crée avec le login de l’utilisateur.

Personne n’a une idée ?

Les clés ssh sont dans $HOME/.ssh/id_*

Oui je sais qu’elle se trouve a cette endroit, mais quand je transfert le fichier de mon ancien pc dans mon nouveau pc dans le même repertoire ça ne fonctionne pas.

Tu recopies tout le répertoire .shh. Je la’i fait plein de fois, c’est efficace. Regarde juste tes droits.

Répertoire .ssh, non?

Merci pour ton tuto sur le wiki François au sujet des clés ssh et les connections automatiques

Bonjour à tous,

une nouvelle sur le forum !
bon bien que le topic date, mais j’ai un doute sur l’utilisation des cles si quelqu un peut me donner un avis éclairé :slightly_smiling:

si je retire l’accès par mot de passe, et n’ai pas accès au serveur physique, que la machine A pour une raison lambda crash je n’ai plus accès au serveur car plus de clés disponible,

je suis partie d’une machin A se connectant au serveur B en ssh avec une cle et une passephrase tout fonctionne :

sur une machine A, une cle privee id_rsa
une cle publique id_rsa.pub
une passphrase

envoi sur la machine/serveur b de la cle publique id_rsa.pub > ok
test de connexion ssh depuis a vers b > ok

maintenant si je veux utiliser depuis une nouvelle machine B
la cles privee emise par la machine A, je transfert en ssh tout le repertoire comme indiqué précédemment dans le topic :

scp -r /home/user/.ssh/ user@192.168.1.5:/home/office/.ssh/

transfert ok !

Mais quand je test la connexion depuis machine B vers A j’ai droit à un beau refus:

il trouve bien la clefs :

Enter passphrase for key ‘/home/user/.ssh/id_rsa’:
Permission denied (publickey).

Pourtant la cles est bien la meme et la passphrase est fonctionnelle…

quelqu un aurait il une idée ?

merci de vos avis eclairés :stuck_out_tongue:

Salut,

Le fichier [mono]/etc/ssh/sshd_config[/mono] de la machine A est-il modifié en ce sens ([mono]PubkeyAuthentication yes[/mono]) ?
Le service ssh doit être relancer.
Quels sont les droits du répertoire et fichiers en [mono]/home/user/.ssh/…[/mono] ?

hello Blezebuth,

merci, ou machine a et b ont bien
PubkeyAuthentication yes

les droits sur machine a sur le repertoire
cd /home/user/.ssh/
ls -l
sont :
-rw------- 1 user user 3326 juil. 12 13:44 id_rsa
-rw-r–r-- 1 user user 753 juil. 12 12:02 id_rsa.pub
-rw-r–r-- 1 user user 666 juil. 13 16:11 known_hosts

peut etre un probleme de droit pour executer le fichier ailleurs ?
merci d’avance

En est il de même sur la machine B ?
Depuis B, lances une session vers A, en mode verbeux (option -v).

et colles le retour complet, stp.

merci,

pour les droits sur la machine b:
cd /home/user/.ssh/

-rw------- 1 user user 1507 Jul 12 13:50 authorized_keys
-rw-r–r-- 1 user user 0 Jul 12 13:50 known_hosts

connexion depuis la machine b vers a :

user@dev:~$ ssh -v user@192.168.1.26 -p 22

OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.1.26 [192.168.1.26] port 22.
debug1: Connection established.
debug1: identity file /home/nico/.ssh/id_rsa type -1
debug1: identity file /home/nico/.ssh/id_rsa-cert type -1
debug1: identity file /home/nico/.ssh/id_dsa type -1
debug1: identity file /home/nico/.ssh/id_dsa-cert type -1
debug1: identity file /home/nico/.ssh/id_ecdsa type -1
debug1: identity file /home/nico/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/nico/.ssh/id_ed25519 type -1
debug1: identity file /home/nico/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 pat OpenSSH_6.6.1* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5-etm@openssh.com none
debug1: kex: client->server aes128-ctr hmac-md5-etm@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA cd:07:2b:04:68:cc:89:73:bb:14:16:5b:4e:a4:68:2f
The authenticity of host ‘192.168.1.26 (192.168.1.26)’ can’t be established.
ECDSA key fingerprint is cd:07:2b:04:68:cc:89:73:bb:14:16:5b:4e:a4:68:2f.
Are you sure you want to continue connecting (yes/no)?

etc…

une idée ?)

Le dernier message indique un problème sur l’identification de la machine, pas sur la clef. Répond yes et continue (mais je pense que le pbm est plus loin)

donc je fais yes et je me connecte

yes
Warning: Permanently added ‘192.168.1.26’ (ECDSA) to the list of known hosts.
debug1: ssh_ecdsa_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,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/nico/.ssh/id_rsa
debug1: Trying private key: /home/nico/.ssh/id_dsa
debug1: Trying private key: /home/nico/.ssh/id_ecdsa
debug1: Trying private key: /home/nico/.ssh/id_ed25519
debug1: Next authentication method: password
nicolas@192.168.1.26’s password:
debug1: Authentication succeeded (password).
Authenticated to 192.168.1.26 ([192.168.1.26]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
Welcome to Ubuntu 14.04.2 LTS (GNU/Linux 3.16.0-43-generic x86_64)

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

user@office-OptiPlex-755:~$

en fait si je tente de me connecter depuis machine c vers b
en utilisant la cle de machine a ; impossible de se connecter

Visiblement ta clef n’est pas reconnue. Je pense à un boxon sur les noms d’utilisateurs, ton login, c’est user, office ou nico? C’est important. Redécris ton système avec les logins. nico possède-t-il les clefs ssh, clefs que tu as copié sur /home/office ce qui n’est pas le bon répertoire (ce serait /home/nico)

merci,
ce sont des machines differentes avec des utilisateurs differents
je vais essayer en mettant le meme user sur toutes les machines

helo,
la solution est trouvée!
mon set up etait correct

donc pour utiliser une clé ssh privee sur un autre serveur que celui
ou elle a ete créée

voici comment j ai procédé :

machine A creation d’un user X puis creation cles id-rsa et id_rsa.pub
ssh-keygen -t rsa -b 4096
file : (blank)
passphrase:xxxxxxxxxxxxxxx

machine B creation d’un user Y puis transfert de la cle publique (id_rsa.pub) avec:
ssh-copy-id -i ~/.ssh/id_rsa.pub y@xxx.xxx.x.xx -p xx

resultat : machine A se connecte a machine B a l’aide de la passphrase

Maintenant pour utiliser la cle privee creee sur machine A sur un autre machine C

machine c :
creation d’un user X (le meme nom que celui de la machine A)
transfert du repertoire.ssh :

scp -r /home/x/.ssh/ @xxx.xxx.x.x:/home/x/.ssh/

machine C peut maintenant se connecter a machine B
avec la meme passphrase que celle utilisée sur la machine A.

Conclusion, pour moi le serveur machine B a le compte root desactivée, plus d’authentification par mot de passe, et en cas de crash de machine A
je peux toujours utiliser n’importe quelle machine avec la même clé,

merci pour le coup de main !