Comment se connecter en ssh à un pc sans utiliser de mot de passe
11 réponses
R User
Bonjour,
j'aurais besoin d'aide pour effectuer cette manipulation.
Soit un poste A et un poste B
J'ai besoin de me connecter en ssh sur B depuis A sans saisir de mot de
passe.
Je sais qu'il s'agit de créer des clés publiques, privées mais je ne sais
pas bien comment faire.
De plus une fois les clefs créés si qqun prend controle de A alors il aura
accès à B ?
j'aurais besoin d'aide pour effectuer cette manipulation.
Soit un poste A et un poste B J'ai besoin de me connecter en ssh sur B depuis A sans saisir de mot de passe. Je sais qu'il s'agit de créer des clés publiques, privées mais je ne sais pas bien comment faire.
ssh-keygen ssh-agent ssh-add
Avec ces mots clés, tu tombera sur des tas de tutoriaux sur le web.
-- Matthieu
"R User" <Ruser@nospam.fr> writes:
Bonjour,
j'aurais besoin d'aide pour effectuer cette manipulation.
Soit un poste A et un poste B
J'ai besoin de me connecter en ssh sur B depuis A sans saisir de mot de
passe.
Je sais qu'il s'agit de créer des clés publiques, privées mais je ne sais
pas bien comment faire.
ssh-keygen
ssh-agent
ssh-add
Avec ces mots clés, tu tombera sur des tas de tutoriaux sur le web.
j'aurais besoin d'aide pour effectuer cette manipulation.
Soit un poste A et un poste B J'ai besoin de me connecter en ssh sur B depuis A sans saisir de mot de passe. Je sais qu'il s'agit de créer des clés publiques, privées mais je ne sais pas bien comment faire.
ssh-keygen ssh-agent ssh-add
Avec ces mots clés, tu tombera sur des tas de tutoriaux sur le web.
-- Matthieu
_]NiX[_
R User fr.comp.os.linux.configuration lundi 28 mai 2007 13:19
Bonjour,
'Lo
j'aurais besoin d'aide pour effectuer cette manipulation.
Soit un poste A et un poste B J'ai besoin de me connecter en ssh sur B depuis A sans saisir de mot de passe.
On dira que tu veux te connecter de A (avec l'utilisateur toto) sur B (avec l'utilisateur titi). Cette méthode est sans doute perfectible.
_Sur_ _A_ :
On créé les clés :
$ ssh-keygen -b 1024 -t dsa (quand il demande le mot de passe tapper entrée, deux fois)
On envoi la clé publique sur B :
$ sftp put /home/toto/.ssh/id_dsa.pub
_sur_ _B_ :
On modifie un peu la configuration du serveur ssh pour ne plus accepter les connexions par mot de passe :
$ su # vi /etc/ssh/sshd_config Modifier : PasswordAuthentication no # /etc/rc.d/rc.sshd restart # exit
On ajouter la clé publique de A dans le fichier des clés autorisées :
$ su titi $ cat /home/titi/id_dsa.pub >> /home/titi/.ssh/authorized_keys
Se délogguer et se reloguer (ssh -l titi serveurB.domaine.tld), ça devrait fonctionner.
De plus une fois les clefs créés si qqun prend controle de A alors il aura accès à B ?
Oui, d'où l'intérêt de ne pas utiliser les comptes root pour faire ce genre de manip.
Merci pour votre aide
De rien, mais attention tu peux bloquer l'accès à ta machine. Le tout c'est de bien comprendre ce que tu fais.
T
N
R User fr.comp.os.linux.configuration lundi 28 mai 2007 13:19
Bonjour,
'Lo
j'aurais besoin d'aide pour effectuer cette manipulation.
Soit un poste A et un poste B
J'ai besoin de me connecter en ssh sur B depuis A sans saisir de mot de
passe.
On dira que tu veux te connecter de A (avec l'utilisateur toto) sur B (avec
l'utilisateur titi). Cette méthode est sans doute perfectible.
_Sur_ _A_ :
On créé les clés :
$ ssh-keygen -b 1024 -t dsa
(quand il demande le mot de passe tapper entrée, deux fois)
On envoi la clé publique sur B :
$ sftp titi@ip.du.serveur.B
put /home/toto/.ssh/id_dsa.pub
_sur_ _B_ :
On modifie un peu la configuration du serveur ssh pour ne plus accepter les
connexions par mot de passe :
$ su
# vi /etc/ssh/sshd_config
Modifier :
PasswordAuthentication no
# /etc/rc.d/rc.sshd restart
# exit
On ajouter la clé publique de A dans le fichier des clés autorisées :
$ su titi
$ cat /home/titi/id_dsa.pub >> /home/titi/.ssh/authorized_keys
Se délogguer et se reloguer (ssh -l titi serveurB.domaine.tld), ça devrait
fonctionner.
De plus une fois les clefs créés si qqun prend controle de A alors il aura
accès à B ?
Oui, d'où l'intérêt de ne pas utiliser les comptes root pour faire ce genre
de manip.
Merci pour votre aide
De rien, mais attention tu peux bloquer l'accès à ta machine. Le tout c'est
de bien comprendre ce que tu fais.
(quand il demande le mot de passe tapper entrée, deux fois)
Ou bien utiliser un agent SSH.
On modifie un peu la configuration du serveur ssh pour ne plus accepter les connexions par mot de passe :
Inutile.
R User
"_]NiX[_" a écrit dans le message de news: f3efdm$4he$
R User fr.comp.os.linux.configuration lundi 28 mai 2007 13:19
Bonjour,
'Lo
j'aurais besoin d'aide pour effectuer cette manipulation.
Soit un poste A et un poste B J'ai besoin de me connecter en ssh sur B depuis A sans saisir de mot de passe.
On dira que tu veux te connecter de A (avec l'utilisateur toto) sur B (avec l'utilisateur titi). Cette méthode est sans doute perfectible.
non en fait c'est plus compliqué que ce que je croyais car :
Soit A serveur de backup et B la machine à Backuper Il faut qu'un compte non root de A puisse se connecter à B en automatique pour effectuer la backup. Donc il faut que je créee une paire de clés sur B et que j'envoie la clé privée sur A. Mais je comprends plus rien sur la manière de génére les clés. Car il faut que je sois sur B authentifé avec un compte qui n'a que les droits suffisants pour effectuer la sauvegarde , que je génére les clés , que j'envoie la clé privée sur A et quand je serai sur A je m'authentifie en utilisant le compte user de B ?
_Sur_ _A_ :
On créé les clés :
$ ssh-keygen -b 1024 -t dsa (quand il demande le mot de passe tapper entrée, deux fois)
On envoi la clé publique sur B :
$ sftp put /home/toto/.ssh/id_dsa.pub
_sur_ _B_ :
On modifie un peu la configuration du serveur ssh pour ne plus accepter les connexions par mot de passe :
$ su # vi /etc/ssh/sshd_config Modifier : PasswordAuthentication no # /etc/rc.d/rc.sshd restart # exit
On ajouter la clé publique de A dans le fichier des clés autorisées :
$ su titi $ cat /home/titi/id_dsa.pub >> /home/titi/.ssh/authorized_keys
Se délogguer et se reloguer (ssh -l titi serveurB.domaine.tld), ça devrait fonctionner.
De plus une fois les clefs créés si qqun prend controle de A alors il aura accès à B ?
Oui, d'où l'intérêt de ne pas utiliser les comptes root pour faire ce genre de manip.
Merci pour votre aide
De rien, mais attention tu peux bloquer l'accès à ta machine. Le tout c'est de bien comprendre ce que tu fais.
T
N
"_]NiX[_" <nux@nox.nix> a écrit dans le message de news:
f3efdm$4he$1@open.netfinity.fr...
R User fr.comp.os.linux.configuration lundi 28 mai 2007 13:19
Bonjour,
'Lo
j'aurais besoin d'aide pour effectuer cette manipulation.
Soit un poste A et un poste B
J'ai besoin de me connecter en ssh sur B depuis A sans saisir de mot de
passe.
On dira que tu veux te connecter de A (avec l'utilisateur toto) sur B
(avec
l'utilisateur titi). Cette méthode est sans doute perfectible.
non en fait c'est plus compliqué que ce que je croyais car :
Soit A serveur de backup et B la machine à Backuper
Il faut qu'un compte non root de A puisse se connecter à B en automatique
pour effectuer la backup.
Donc il faut que je créee une paire de clés sur B et que j'envoie la clé
privée sur A.
Mais je comprends plus rien sur la manière de génére les clés. Car il faut
que je sois sur B authentifé avec un compte qui n'a que les droits
suffisants pour effectuer la sauvegarde ,
que je génére les clés , que j'envoie la clé privée sur A et quand je serai
sur A je m'authentifie en utilisant le compte user de B ?
_Sur_ _A_ :
On créé les clés :
$ ssh-keygen -b 1024 -t dsa
(quand il demande le mot de passe tapper entrée, deux fois)
On envoi la clé publique sur B :
$ sftp titi@ip.du.serveur.B
put /home/toto/.ssh/id_dsa.pub
_sur_ _B_ :
On modifie un peu la configuration du serveur ssh pour ne plus accepter
les
connexions par mot de passe :
$ su
# vi /etc/ssh/sshd_config
Modifier :
PasswordAuthentication no
# /etc/rc.d/rc.sshd restart
# exit
On ajouter la clé publique de A dans le fichier des clés autorisées :
$ su titi
$ cat /home/titi/id_dsa.pub >> /home/titi/.ssh/authorized_keys
Se délogguer et se reloguer (ssh -l titi serveurB.domaine.tld), ça devrait
fonctionner.
De plus une fois les clefs créés si qqun prend controle de A alors il
aura
accès à B ?
Oui, d'où l'intérêt de ne pas utiliser les comptes root pour faire ce
genre
de manip.
Merci pour votre aide
De rien, mais attention tu peux bloquer l'accès à ta machine. Le tout
c'est
de bien comprendre ce que tu fais.
"_]NiX[_" a écrit dans le message de news: f3efdm$4he$
R User fr.comp.os.linux.configuration lundi 28 mai 2007 13:19
Bonjour,
'Lo
j'aurais besoin d'aide pour effectuer cette manipulation.
Soit un poste A et un poste B J'ai besoin de me connecter en ssh sur B depuis A sans saisir de mot de passe.
On dira que tu veux te connecter de A (avec l'utilisateur toto) sur B (avec l'utilisateur titi). Cette méthode est sans doute perfectible.
non en fait c'est plus compliqué que ce que je croyais car :
Soit A serveur de backup et B la machine à Backuper Il faut qu'un compte non root de A puisse se connecter à B en automatique pour effectuer la backup. Donc il faut que je créee une paire de clés sur B et que j'envoie la clé privée sur A. Mais je comprends plus rien sur la manière de génére les clés. Car il faut que je sois sur B authentifé avec un compte qui n'a que les droits suffisants pour effectuer la sauvegarde , que je génére les clés , que j'envoie la clé privée sur A et quand je serai sur A je m'authentifie en utilisant le compte user de B ?
_Sur_ _A_ :
On créé les clés :
$ ssh-keygen -b 1024 -t dsa (quand il demande le mot de passe tapper entrée, deux fois)
On envoi la clé publique sur B :
$ sftp put /home/toto/.ssh/id_dsa.pub
_sur_ _B_ :
On modifie un peu la configuration du serveur ssh pour ne plus accepter les connexions par mot de passe :
$ su # vi /etc/ssh/sshd_config Modifier : PasswordAuthentication no # /etc/rc.d/rc.sshd restart # exit
On ajouter la clé publique de A dans le fichier des clés autorisées :
$ su titi $ cat /home/titi/id_dsa.pub >> /home/titi/.ssh/authorized_keys
Se délogguer et se reloguer (ssh -l titi serveurB.domaine.tld), ça devrait fonctionner.
De plus une fois les clefs créés si qqun prend controle de A alors il aura accès à B ?
Oui, d'où l'intérêt de ne pas utiliser les comptes root pour faire ce genre de manip.
Merci pour votre aide
De rien, mais attention tu peux bloquer l'accès à ta machine. Le tout c'est de bien comprendre ce que tu fais.
T
N
R User
"Fabien LE LEZ" a écrit dans le message de news:
http://www.jdmz.net/ssh/ merci pour le lien, c'est exactement ce que je veux faire mais j'ai un peu
de mal
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de news:
ebgl539gnogdrnmrugavrj23un0uv0b218@4ax.com...
http://www.jdmz.net/ssh/
merci pour le lien, c'est exactement ce que je veux faire mais j'ai un peu
http://www.jdmz.net/ssh/ merci pour le lien, c'est exactement ce que je veux faire mais j'ai un peu
de mal
Fabien LE LEZ
On Mon, 28 May 2007 16:14:16 +0200, "R User" :
Il faut qu'un compte non root de A puisse se connecter à B en automatique pour effectuer la backup. Donc il faut que je créee une paire de clés sur B et que j'envoie la clé privée sur A.
Tu peux créer les clés sur n'importe quelle machine (pas forcément A ou B). Ensuite, tu mets la clé privée sur A, et la clé publique dans $HOME/.ssh/authorized_keys sur B.
On conseille généralement de créer les clés sur A, car ça évite de se demander comment transférer la clé privée de manière sûre.
On Mon, 28 May 2007 16:14:16 +0200, "R User" <Ruser@nospam.fr>:
Il faut qu'un compte non root de A puisse se connecter à B en automatique
pour effectuer la backup.
Donc il faut que je créee une paire de clés sur B et que j'envoie la clé
privée sur A.
Tu peux créer les clés sur n'importe quelle machine (pas forcément A
ou B).
Ensuite, tu mets la clé privée sur A, et la clé publique dans
$HOME/.ssh/authorized_keys sur B.
On conseille généralement de créer les clés sur A, car ça évite de se
demander comment transférer la clé privée de manière sûre.
Il faut qu'un compte non root de A puisse se connecter à B en automatique pour effectuer la backup. Donc il faut que je créee une paire de clés sur B et que j'envoie la clé privée sur A.
Tu peux créer les clés sur n'importe quelle machine (pas forcément A ou B). Ensuite, tu mets la clé privée sur A, et la clé publique dans $HOME/.ssh/authorized_keys sur B.
On conseille généralement de créer les clés sur A, car ça évite de se demander comment transférer la clé privée de manière sûre.
R User
"Fabien LE LEZ" a écrit dans le message de news:
On Mon, 28 May 2007 16:14:16 +0200, "R User" :
Il faut qu'un compte non root de A puisse se connecter à B en automatique pour effectuer la backup. Donc il faut que je créee une paire de clés sur B et que j'envoie la clé privée sur A.
Tu peux créer les clés sur n'importe quelle machine (pas forcément A ou B). Ensuite, tu mets la clé privée sur A, et la clé publique dans $HOME/.ssh/authorized_keys sur B.
On conseille généralement de créer les clés sur A, car ça évite de se demander comment transférer la clé privée de manière sûre.
Ok merci ca j'ai compris , car en fait le principe est le suivant :
peu importe où tu génére la paire de clés, il faut qu'une fois généré la clé publique, tu mettes son contenu dans les clés publiques autorisées de la machine sur laquelle tu veux te connecter en t'authentifiant avec la clé privée depuis n'importe où. Donc ca j'ai pigé. Par contre si tu autorises ce type de connexion cela signifie que tu dois empecher la connexion par mot de passe ou peux tu faire les deux ?
En fait le mode de connexion par clé privée , clé publique est très sur , plus sur que la connexion par mot de passe, non ? Car il doit être plus difficile de générer la bonne clé privée que de générer le bon mot de passe. Par contre il est vrai que tu dois te "trimbaler" la clé privé partout où tu vas et là tu risques de laisser à droite à gauche, voir meme de la perdre. De plus suppose que je suis en entreprise, je veux me connecter à mon pc via ssh , je suis donc obligé de mettre la clé privée sur le poste (au moins le temps de l'authentification) et pendant ce temps là l'admnistrateur ou autre personne ayant accès au pc a tout le loisirs de prendre la clé privée alors qu'avec un mot de passe y a pas de lézard.
merci pour ton aide T
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de news:
75ql53t061d20hjm8mmifsfist7gd93mph@4ax.com...
On Mon, 28 May 2007 16:14:16 +0200, "R User" <Ruser@nospam.fr>:
Il faut qu'un compte non root de A puisse se connecter à B en automatique
pour effectuer la backup.
Donc il faut que je créee une paire de clés sur B et que j'envoie la clé
privée sur A.
Tu peux créer les clés sur n'importe quelle machine (pas forcément A
ou B).
Ensuite, tu mets la clé privée sur A, et la clé publique dans
$HOME/.ssh/authorized_keys sur B.
On conseille généralement de créer les clés sur A, car ça évite de se
demander comment transférer la clé privée de manière sûre.
Ok merci ca j'ai compris , car en fait le principe est le suivant :
peu importe où tu génére la paire de clés, il faut qu'une fois généré la clé
publique, tu mettes son contenu
dans les clés publiques autorisées de la machine sur laquelle tu veux te
connecter en t'authentifiant avec la clé privée
depuis n'importe où. Donc ca j'ai pigé. Par contre si tu autorises ce type
de connexion cela signifie
que tu dois empecher la connexion par mot de passe ou peux tu faire les deux
?
En fait le mode de connexion par clé privée , clé publique est très sur ,
plus sur que la connexion par mot de passe, non ?
Car il doit être plus difficile de générer la bonne clé privée que de
générer le bon mot de passe.
Par contre il est vrai que tu dois te "trimbaler" la clé privé partout où tu
vas et là tu risques de laisser à droite à gauche, voir
meme de la perdre. De plus suppose que je suis en entreprise, je veux me
connecter à mon pc via ssh , je suis donc
obligé de mettre la clé privée sur le poste (au moins le temps de
l'authentification) et pendant ce temps là l'admnistrateur
ou autre personne ayant accès au pc a tout le loisirs de prendre la clé
privée alors qu'avec un mot de passe y a pas de lézard.
Il faut qu'un compte non root de A puisse se connecter à B en automatique pour effectuer la backup. Donc il faut que je créee une paire de clés sur B et que j'envoie la clé privée sur A.
Tu peux créer les clés sur n'importe quelle machine (pas forcément A ou B). Ensuite, tu mets la clé privée sur A, et la clé publique dans $HOME/.ssh/authorized_keys sur B.
On conseille généralement de créer les clés sur A, car ça évite de se demander comment transférer la clé privée de manière sûre.
Ok merci ca j'ai compris , car en fait le principe est le suivant :
peu importe où tu génére la paire de clés, il faut qu'une fois généré la clé publique, tu mettes son contenu dans les clés publiques autorisées de la machine sur laquelle tu veux te connecter en t'authentifiant avec la clé privée depuis n'importe où. Donc ca j'ai pigé. Par contre si tu autorises ce type de connexion cela signifie que tu dois empecher la connexion par mot de passe ou peux tu faire les deux ?
En fait le mode de connexion par clé privée , clé publique est très sur , plus sur que la connexion par mot de passe, non ? Car il doit être plus difficile de générer la bonne clé privée que de générer le bon mot de passe. Par contre il est vrai que tu dois te "trimbaler" la clé privé partout où tu vas et là tu risques de laisser à droite à gauche, voir meme de la perdre. De plus suppose que je suis en entreprise, je veux me connecter à mon pc via ssh , je suis donc obligé de mettre la clé privée sur le poste (au moins le temps de l'authentification) et pendant ce temps là l'admnistrateur ou autre personne ayant accès au pc a tout le loisirs de prendre la clé privée alors qu'avec un mot de passe y a pas de lézard.
merci pour ton aide T
R User
"Fabien LE LEZ" a écrit dans le message de news:
On Mon, 28 May 2007 16:14:16 +0200, "R User" :
Il faut qu'un compte non root de A puisse se connecter à B en automatique pour effectuer la backup. Donc il faut que je créee une paire de clés sur B et que j'envoie la clé privée sur A.
Tu peux créer les clés sur n'importe quelle machine (pas forcément A ou B). Ensuite, tu mets la clé privée sur A, et la clé publique dans $HOME/.ssh/authorized_keys sur B.
On conseille généralement de créer les clés sur A, car ça évite de se demander comment transférer la clé privée de manière sûre.
Je suis confronté à un problème de transfert de la clé publique vers le poste distant. Comment tu fais pour faire ca ? Car le fichier authorized_keys contient déjà une clé publique .
merci d'avance T
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de news:
75ql53t061d20hjm8mmifsfist7gd93mph@4ax.com...
On Mon, 28 May 2007 16:14:16 +0200, "R User" <Ruser@nospam.fr>:
Il faut qu'un compte non root de A puisse se connecter à B en automatique
pour effectuer la backup.
Donc il faut que je créee une paire de clés sur B et que j'envoie la clé
privée sur A.
Tu peux créer les clés sur n'importe quelle machine (pas forcément A
ou B).
Ensuite, tu mets la clé privée sur A, et la clé publique dans
$HOME/.ssh/authorized_keys sur B.
On conseille généralement de créer les clés sur A, car ça évite de se
demander comment transférer la clé privée de manière sûre.
Je suis confronté à un problème de transfert de la clé publique vers le
poste distant.
Comment tu fais pour faire ca ?
Car le fichier authorized_keys contient déjà une clé publique .
Il faut qu'un compte non root de A puisse se connecter à B en automatique pour effectuer la backup. Donc il faut que je créee une paire de clés sur B et que j'envoie la clé privée sur A.
Tu peux créer les clés sur n'importe quelle machine (pas forcément A ou B). Ensuite, tu mets la clé privée sur A, et la clé publique dans $HOME/.ssh/authorized_keys sur B.
On conseille généralement de créer les clés sur A, car ça évite de se demander comment transférer la clé privée de manière sûre.
Je suis confronté à un problème de transfert de la clé publique vers le poste distant. Comment tu fais pour faire ca ? Car le fichier authorized_keys contient déjà une clé publique .
merci d'avance T
Matthieu Moy
"R User" writes:
Je suis confronté à un problème de transfert de la clé publique vers le poste distant. Comment tu fais pour faire ca ? Car le fichier authorized_keys contient déjà une clé publique .
Tu les met bout à bout.
La clé publique est assez courte et n'a rien de secret (par définition). Donc n'importe quel moyen est bon pour la transférer (copier-coller dans deux terminaux, mail ou n'importe quoi d'autre).
-- Matthieu
"R User" <Ruser@nospam.fr> writes:
Je suis confronté à un problème de transfert de la clé publique vers le
poste distant.
Comment tu fais pour faire ca ?
Car le fichier authorized_keys contient déjà une clé publique .
Tu les met bout à bout.
La clé publique est assez courte et n'a rien de secret (par
définition). Donc n'importe quel moyen est bon pour la transférer
(copier-coller dans deux terminaux, mail ou n'importe quoi d'autre).
Je suis confronté à un problème de transfert de la clé publique vers le poste distant. Comment tu fais pour faire ca ? Car le fichier authorized_keys contient déjà une clé publique .
Tu les met bout à bout.
La clé publique est assez courte et n'a rien de secret (par définition). Donc n'importe quel moyen est bon pour la transférer (copier-coller dans deux terminaux, mail ou n'importe quoi d'autre).
