[REGLE] Clé SSH, pas de mot de passe

Support Debian
#1

Bonjour,

J’aimerais mettre en place une connexion SSH sans mot de passe afin de transférer des sauvegardes via rsync.
Actuellement, lors de la connexion, le serveur me demande un mot de passe.

Voici ce que j’ai fais:

J’ai généré la clé sur le serveur qui envoi les fichiers à sauvegarder (dans le dossier /home/user/.ssh/)
J’ai transféré cette clé vers le serveur qui réceptionnera les fichiers vers /home/user/.ssh/id_dsa.pub (.ssh en chmod 700, l’user est bien le propriétaire)
Copié la clé dans authorized_keys avec: cat /home/user/.ssh/id_dsa.pub >> /home/user/.ssh/authorized_keys
Chmod 600 sur authorized_keys

lorsque je lance la connexion, un mot de passe m’est demandé.
J’ai fais exactement la même procédure sur 2 autres serveurs et cela fonctionne parfaitement. Je pensais à un problème au niveau de SSH, mais je n’ai rien trouvé d’anormale à mon niveau, voici le fichier:

[code]# Package generated configuration file

See the sshd_config(5) manpage for details

What ports, IPs and protocols we listen for

Port 2200

Use these options to restrict which interfaces/protocols sshd will bind to

#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2

HostKeys for protocol version 2

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

Lifetime and size of ephemeral version 1 server key

KeyRegenerationInterval 3600
ServerKeyBits 768

Logging

SyslogFacility AUTH
LogLevel INFO

Authentication:

LoginGraceTime 120
PermitRootLogin no
StrictModes yes
#AllowUsers
RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

Don’t read the user’s ~/.rhosts and ~/.shosts files

IgnoreRhosts yes

For this to work you will also need host keys in /etc/ssh_known_hosts

RhostsRSAAuthentication no

similar for protocol version 2

HostbasedAuthentication no

Uncomment if you don’t trust ~/.ssh/known_hosts for RhostsRSAAuthentication

#IgnoreUserKnownHosts yes

To enable empty passwords, change to yes (NOT RECOMMENDED)

PermitEmptyPasswords no

Change to yes to enable challenge-response passwords (beware issues with

some PAM modules and threads)

ChallengeResponseAuthentication no

Change to no to disable tunnelled clear text passwords

#PasswordAuthentication yes

Kerberos options

#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

GSSAPI options

#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

Allow client to pass locale environment variables

AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

Set this to ‘yes’ to enable PAM authentication, account processing,

and session processing. If this is enabled, PAM authentication will

be allowed through the ChallengeResponseAuthentication and

PasswordAuthentication. Depending on your PAM configuration,

PAM authentication via ChallengeResponseAuthentication may bypass

the setting of “PermitRootLogin without-password”.

If you just want the PAM account and session checks to run without

PAM authentication, then enable this but set PasswordAuthentication

and ChallengeResponseAuthentication to ‘no’.

UsePAM yes
[/code]

Le fait de décocher #AuthorizedKeysFile %h/.ssh/authorized_keys ne change rien.

Auriez-vous une idée svp ?
Merci d’avance pour le coup de main.

#2

Beuh,
Avec la config par défault:

ssh-keygen -t rsa
ssh-copy-id user@host

Dans ton cas, j’imagine que des choses ont changés, ce pourquoi il refuse d’utiliser la clé
As-tu regardé dans les journaux system ?

#3

T’as fait une faute de frappe je pense ^’

[quote=“haleth”]
Dans ton cas, j’imagine que des choses ont changés, ce pourquoi il refuse d’utiliser la clé
As-tu regardé dans les journaux system ?[/quote]

+1 , regarde le auth.log tu devrais avoir un message d’erreur relativement explicite.

Sinon t’as démarche me semble pas fausse, ta commande rsync ressemble à quelque chose comme ? :

rsync -avz --omit-dir-times -e "ssh -i /home/user/.ssh/id_dsa" /rep/a/synchro/ srvdestinataire.domaine.com:/rep/a/synchro/

Enfin si tu fais la meme chose sur d’autres serveurs jpense pas que l’erreur vienne de la commande rsync, mais une erreur de manip dans les echanges de key, tu l’as bien coller dans le répertoire .ssh/id_dsa de l’utilisateurX sur la machine destinataire ? ^’

1 : essaye juste de te connecter avec la key en SSH sur le serveur destinataire avec l’user du srv destinataire. Si la ca fonctionne déjà tu sais que ton jeu de key est correctement crée mais que c’est la ssh-copy-id qui a merdé =o

#4

Merci, j’ai corrigé!

Si tu n’aimes pas les logs, tu peux aussi regardé avec ssh:

ssh -vvv user@host

#5

Je viens de regarder dans les logs, je n’ai rien de généré m’informant du problème, du moins, je n’ai rien vu, si je saisis le mot de passe de connexion, celle-ci est bien enregistrée.

Je viens d’utiliser le fichier sshd_config d’un serveur pour lequel cela fonctionne, et le problème reste similaire:

ssh user@serveur.com
Connection OK, mais demande de mot de passe :confused:

J’ai copié la clé via scp (en vérifiant avant la copie, puis après si celle-ci était bien transférée).

Merci à vous.

#6

Ton problème viens surement de la copie de la clé sur le serveur destinataire, vérifie si ta commande ssh-copy-id est bien passé ^’.

Edit : et essaye ton jeu de clé sur le serveur 1 et sur le serveur 2… pour bien localisé la panne, mais jsuis à peu près sur que tu t’es miss dans la copie de la clé sur le serveur 2.

Edit 2 : faut que j’arrête d’envoyer trop vite, euh tant qu’on y est … tu dois forcement avoir une erreur de refus de la clé dans les logs… sinon c’est que ton paramètre “la clé est la >” n’est pas pris en compte.

Si t’as rien dans les logs et qu’il te demande quand même le mot de passe, c’est soit que t’exécutes la commande sur le srv1 avec un user différents de celui que t’as utilisé pour le transfert de la clé, soit que ton paramètre de localisation de clé est pas bon(dans ta commande rsync… ca serait etonnant si comme tu le dis ca marche pour d’autres serveurs mais bon une faute de frappe c’est vite arrivée).

jte file le tuto que j’ai utilié quand j’ai mis en place une synchro de répertoire avec rsync + key :
blogmotion.fr/systeme/connexion- … passe-2709

Ca peut peut être t’aider ^’

#7

Si tu n’es pas trop pressé, je te donnerai mon avis ce soir tard (> minuit).
C’est un domaine que j’utilise couramment : avec et sans pass.

EDIT :
Le sshd_config que tu donnes dans ton 1er post est celui du client ou celui du serveur ?

#8

Vite fait, la seule chose qui me semble pouvoir jouer est :

Essaie, et le résultat n’est pas forcément le même, de décommenter cette ligne et de mettre à ‘no’.
Je repasse ce soir.

#9

Encore merci à vous de prendre le temps de me répondre :023

Pour l’instant, je ne m’y suis pas lancé, j’utilise juste une connexion direct: ssh user@host.com pour tester.

[quote=“ricardo”]EDIT :
Le sshd_config que tu donnes dans ton 1er post est celui du client ou celui du serveur ?[/quote]
Le sshd_config est celui de la machine recevant les fichiers de backup.

Je viens de refaire la procédure à l’instant sur mon pc chez moi:

Copie du fichier id_dsa.pub localisé dans /home/user/.ssh vers —> /home/user/.ssh sur le pc distant, avec la commande suivante:

scp /home/user/.ssh/id_dsa.pub user@host.com:/home/user/.ssh/
La clé est bien copiée.

cat /home/user/.ssh/id_dsa.pub >> /home/user/.ssh/authorized_keys
chmod 600 authorized_keys

Connexion: IT WORK’S :mrgreen:

Je viens de refaire la même chose sur le serveur refusant ma clé: Demande de password.

Au niveau log (auth), j’ai la connexion normale de l’user, comme si de rien…

No problem :slightly_smiling:

#10

[quote=“ricardo”]Vite fait, la seule chose qui me semble pouvoir jouer est :

Essaie, et le résultat n’est pas forcément le même, de décommenter cette ligne et de mettre à ‘no’.
Je repasse ce soir.[/quote]

Hummm il n’aime pas :unamused:
–> Permission denied (publickey)

#11

[quote=“dopi”][quote=“ricardo”]Vite fait, la seule chose qui me semble pouvoir jouer est :

Essaie, et le résultat n’est pas forcément le même, de décommenter cette ligne et de mettre à ‘no’.
Je repasse ce soir.[/quote]

Hummm il n’aime pas :unamused:
–> Permission denied (publickey)[/quote]

C’est donc bien ce que je pensais.
Il te dit qu’il n’accepte pas la liaison avec password parce qu’il y a la présence d’un jeu de clefs.
Si j’ai bien compris, c’est ce que tu recherches : liaison ssh sans pass mais avec clef, non :question:

Donc, maintenant, il faut trouver pourquoi il ne voit pas la clef.
S’il voyait la clef, au lieu de

Permission denied (publickey) >>
tu aurais :

Entrez la passphrase >>
ou quelque chose du même genre.

Je vais tester chez moi pour donner les termes exacts.

#12

Voici la phrase exacte (sauf le chemin 8) ) d’une réponse à une requête SSH avec présence d’un jeu de clefs :

Enter passphrase for key '/home/ricardo/chemin_de_la_clef_privée'
#13

Salut,

Rajoute donc ceci à ton fichier ~/.ssh/config :

Host __adresse_ip_de_ton_host Hostname __ton_hostname_cible Port 22 User __ton_user IdentityFile ~/.ssh/__ta_clef_privee.key
Les valeurs avec commençant par deux tirets bas à modifier à ta convenance…

Espérant que ça fonctionne !

#14

Je crois qu’il serait bon d’être plus clair sur ce que tu veux faire car j’ai des doutes :

[quote]J’aimerais mettre en place une connexion SSH sans mot de passe afin de transférer des sauvegardes via rsync.[/quote]Sans MDP mais avec un jeu de clefs : OK ?

[quote]J’ai généré la clé sur le serveur qui envoi les fichiers à sauvegarder (dans le dossier /home/user/.ssh/)
J’ai transféré cette clé vers le serveur qui réceptionnera les fichiers vers /home/user/.ssh/id_dsa.pub …[/quote]
“serveur qui envoit les fichiers”, “serveur qui réceptionne les fichiers” : c’est pas très clair pour moi.
Il y a deux machines en jeu :
celle à partir de laquelle tu envoies la requête SSH et sur laquelle tu comptes placer la sauvegarde, je l’appelle "client"
celle sur laquelle se trouvent les fichiers à sauvegarder, je l’appelle "serveur"
OK ?
Ces deux machines sont en réseau interne (LAN) ou le serveur est à l’extérieur (WAN) ?
Sans parler de sauvegarde ‘rsync’ proprement dite mais seulement de liaison SSH,
Dans le schéma que je propose :
– la clef privée se trouve bien dans “client” /home/user/.ssh/id_rsa avec droits 600 ?
– la clef publique se trouve bien dans “serveur” /home/user/.ssh/authorized_keys/id_rsa.pub avec droits 644 ?

#15

Salut,

[quote=“ricardo”]
– la clef publique se trouve bien dans “serveur” /home/user/.ssh/authorized_keys/id_rsa.pub [/quote]

authorized_keys est un fichier non un répertoire, mais vu l’heure …

[quote=“dopi”]Voici ce que j’ai fais:

J’ai généré la clé sur le serveur qui envoi les fichiers à sauvegarder (dans le dossier /home/user/.ssh/)

…

J’ai fais exactement la même procédure sur 2 autres serveurs et cela fonctionne parfaitement. Je pensais à un problème au niveau de SSH, mais je n’ai rien trouvé d’anormale à mon niveau …[/quote]

Aurais tu deux clés (minimum) dans ton répertoire /home/user/.ssh/ ?

Par défaut, SSH utilise id_dsa (ou id_rsa)

Si tel est le cas il te faut le spécifier.

  • exemple :

:~$ ls -al .ssh total 84 drwxr-xr-x 2 user user 4096 janv. 2 18:03 . drwxr-xr-x 111 user user 12288 juin 1 18:51 .. -rw------- 1 user user 16872 mai 8 10:09 authorized_keys -rw------- 1 user user 12603 oct. 6 2012 id_rsa -rw------- 1 user user 12603 oct. 10 2012 id_rsa1 -rw------- 1 user user 2796 oct. 10 2012 id_rsa1.pub -rw------- 1 user user 2796 oct. 6 2012 id_rsa.pub -rw------- 1 user user 4423 mai 29 16:59 known_hosts :~$
Ce qui donnerait :

  • De plus, donne nous le retour complet suivant.
#16

OK .

Les deux machines sont distante.
Un serveur avec des données à sauvegarder (SERVEUR)
Un serveur qui réceptionne ces données (CLIENT)

[quote=“ricardo”]-- la clef privée se trouve bien dans “client” /home/user/.ssh/id_rsa avec droits 600 ?
– la clef publique se trouve bien dans “serveur” /home/user/.ssh/authorized_keys/id_rsa.pub avec droits 644 ?[/quote]
Oui, mais c’est id_dsa, je ne sais pas si c’est utile de le préciser.

Voici le retour d’une connexion avec -vvv:

[code]jerome@host:~$ ssh -vvv jerome@host.com
OpenSSH_5.1p1 Debian-5, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to host.com [83.xx.xx.xx] port 22.
debug1: Connection established.
debug1: identity file /home/jerome/.ssh/identity type -1
debug1: identity file /home/jerome/.ssh/id_rsa type -1
debug3: Not a RSA1 key file /home/jerome/.ssh/id_dsa.
debug2: key_type_from_name: unknown key type '-----BEGIN’
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END’
debug3: key_read: missing keytype
debug1: identity file /home/jerome/.ssh/id_dsa type 2
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5p1 Debian-6+squeeze2
debug1: match: OpenSSH_5.5p1 Debian-6+squeeze2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-5
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 114/256
debug2: bits set: 511/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /home/jerome/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 7
debug3: check_host_in_hostfile: filename /home/jerome/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 8
debug1: Host ‘host.com’ is known and matches the RSA host key.
debug1: Found key in /home/jerome/.ssh/known_hosts:7
debug2: bits set: 517/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/jerome/.ssh/identity ((nil))
debug2: key: /home/jerome/.ssh/id_rsa ((nil))
debug2: key: /home/jerome/.ssh/id_dsa (0xb7746c60)
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,gssapi,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/jerome/.ssh/identity
debug3: no such identity: /home/jerome/.ssh/identity
debug1: Trying private key: /home/jerome/.ssh/id_rsa
debug3: no such identity: /home/jerome/.ssh/id_rsa
debug1: Offering public key: /home/jerome/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
jerome@host.com’s password:

[/code][quote=“BelZéButh”]Si tel est le cas il te faut le spécifier.[/quote]
J’ai exactement le même résultat :confused:

#17

debug3: Not a RSA1 key file /home/jerome/.ssh/id_dsa.

Hop, problem solved;

Utilise ssh-keygen & ssh-copy-id

#18

Bon, ca avance un peu :slightly_smiling:
J’ai remarqué que mon user avait comme home directory: /var/www/ (Je ne sais pas si c’est la cause?)
J’ai créé un nouvel utilisateur, j’ai utilisé exactement la même procédure que cité plus haut et…Bingo, du 1er coup c’est connecté.
Je pense que c’est mon user qui à donc un problème, cependant, je ne peux pas changer son répertoire, si cela en est la cause. Qu’en pensez-vous ?

#19

Bah oui c’est très certainement la cause…

Tu peux changer son répertoire en éditant ton fichier /etc/passwd :

“user:x:1012:1013:,:/home/user:/bin/bash”

Tu changes la partie en gras et voila.
Sinon… tu crées un répertoire /var/www/.ssh/ et tu mets tes fichiers de key dedans et ca devrait fonctionner aussi :wink:.
Quand tu te connectes avec un jeu de clés il recherche les infos dans le répertoire user/.ssh/ si le home d’user est /var/www il va donc allez chercher dans /var/www/.ssh/

Edit pour en dessous :

Ou il veut faire une synchro de répertoire web avec l’utilisateur www-data… ? :smiley:

#20

[quote=“dopi”]Bon, ca avance un peu :slightly_smiling:
J’ai remarqué que mon user avait comme home directory: /var/www/ (Je ne sais pas si c’est la cause?)
J’ai créé un nouvel utilisateur, j’ai utilisé exactement la même procédure que cité plus haut et…Bingo, du 1er coup c’est connecté.
Je pense que c’est mon user qui à donc un problème, cependant, je ne peux pas changer son répertoire, si cela en est la cause. Qu’en pensez-vous ?[/quote]
Pour sûr que c’est là où le bât blesse :smiley:
Pour qu’un utilisateur ait un dossier perso sur /var/www, il n’y a pas une histoire de ‘sftp’ :question:
Cet utilisateur a une entrée réduite sur la machine, on dirait.