Problème de clé ssh/putty - Server refused our key

Support Debian
#1

Bonjour,

J’ai quelques problèmes pour me configurer ssh…

Utilisant à la fois Windows en client et debian en serveur, j’utilise actuellement ssh pour me connecter à mon serveur.

Tel quel j’utilise les mots de passe. Mais je souhaite utiliser maintenant le système de clés privées et de clé publiques pour m’y connecter.

Pour cela, initialement, je m’étais donc télécharger puttygen. Or le format de putty est propriétaire. Il faut effectuer un conversion de format de façon à ce qu’il soit reconnu par le serveur.

Trois solutions possible :
-Créer ma paire de clés via puttygen. Importer la clé publique dans le serveur et effectuer la conversion qui s’impose. Ca ne marche pas…

-Créer ma paire de clés sur le serveur via ssh-keygen puis récupérer ma clé publique, ainsi que la clé privée sur mon client win. Importer la clé publique via putygen (conversion/import key) et enregister en .PPK. Ca ne marche pas…

-Créer ma paire de clé via puttygen, sur le serveur, via les putty-tools (cf. apt-cache search). A priori, ca me semblait la solution la plus cool dans la mesure ou la conversion n’est pas utile, les clés étant créées nativement au format de putty. Mais… Ca ne marche tjs pas.

Dans le cas de cette troisième solution, j’ai effectuée, les commandes suivantes :
Pour obtenir la clé privée :

Multipass:/home/.ssh# puttygen -t rsa -b 2048 -C “my home key : christian@thison ador.homeftp.org” -o mykey.ppk
++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++
Enter passphrase to save key:
Re-enter passphrase to verify:

Ce qui me donne, dans le répertoire /home/.ssh :
Multipass:/home/.ssh# ls
authorized_keys mykey.ppk

(Mykey.ppk étant la privée, donc. Je précise ici que mon user a pour répertoire de connexion /home. Son répertoire .ssh s’y trouve donc).

Pour ce qui est de la clé publique (je ne met pas toute la clé) :
Multipass:/home/christian/.ssh# puttygen -O public-openssh mykey.ppk
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQB7aOZDMMLT2cLQPI0hwp17KZWcjv39JPBPWWdHFOhDn9fDUYTCMSp1 (etc…)

Après quoi, il ne reste plus qu’à copier la clé publique et l’enregistrer dans .ssh/authorized_keys.

Ensuite, je récupère le tout via samba sur mon Windows, j’ouvre en utilisant Putty, en choisissant, bien sûr, la clé via “ssh” et “auth”

Et là, c’est le drame : j’obiens :

Using username “christian”.
Server refused our key
christian@Multipass’s password:

Et c’est systèmétatique…

Alors, au niveau des droits sur les fichiers, j’ai :
Multipass:/home/.ssh# ls -l
total 8
-rw------- 1 christian root 1269 2008-05-04 01:06 authorized_keys
-rw-r–r-- 1 christian root 1482 2008-05-04 00:48 mykey.ppk

Au niveau des droits sur le répertoire /home (dès fois qu’il y ait un rapport):
drwxrwx— 15 christian christian 4096 2008-05-03 23:29 home

Et au niveau du fichier de conf de sshd_conf, j’ai :

Package generated configuration file

See the sshd(8) manpage for details

What ports, IPs and protocols we listen for

Port 22

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 yes
###PermitRootLogin without-password
StrictModes yes

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
#PasswordAuthentication no

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

UsePAM yes

Alors Pleaaaase!!! Ou est-ce que j’ai fait une erreur???
Argghhh Ca fait dix plombes que je m’acharne sur toutes les solutions imaginables, mais je ne vois pas le problème!

Rgs,
Chris

#2

?
Y a un pb avec le forum? Y a 15 000 messages d’apparus en 15 mm…

J’ajoute juste que j’ai créé mes clé en root. Après, j’ai modifié l’owner sur mes fichiers de façon à ce que “christian” soit propriétaire mais… même sans ça, ça ne changeait rien.

Bref, un petit coup de main serait bienvenu…

Chris

#3

Yo, apparemment, après avoir créé lé clé publique avec puttygen sur windows (sans utiliser les outils puttygen sous linux, donc, soit ma première solution), j’ai tenté de copier le résultat de la clé (un simple copier), pour en coller le résultat dans un fichier vide (en fait authorized_keys, dans le .ssh du répertoire de connexion de mon user.

Après quoi, je fais habituellement (façon de parler) un simple :angry: authorized_keys. Or, il faut en fait “traduire” le format en rsa. Aussi… je me pose la qestion : le pb ne viendrait-il pas du fait que je ne fasse pas l’enregistrement en .rsa, par exemple?

Quelqu’un sait?

Thx,
Chris

#4

hi,

Baaah… toujours aucun résultat. Si je m’en tiens aux tutoriaux, je suis “dedans” pourtant. Les droits sur les fichiers et les répertoires semblent nickel. Je copie les fichiers comme il faut… Quand à ssh-add, c’est utilisé lorsque l’on prends un agent style “pageant” je crois.

Aaaarrgghhh quelqu’un est spécialiste? Ca ne m’avait pas paru si sorcier, pourtant…

Rgs,
Chris

#5

Vérifies les droits de authorized_keys (lecture seule) et les droits de ta clef privé (lecture seul pour toi et pas pour les autres), je relirais mieux ton post mais je ne connais pas bien putty

#6

Ayant effectué quelques modif’, j’ai attribué l’autorisation à un autre user de se connecter ssh. C’est toujours “moi-même” mais plus christian. A savoir ChrisAubin_.

C’est la seule modif’ que j’ai effectué au sujet d’ssh par rapport au dernier message que j’ai laissé, ci-dessus.

En tout cas, pour répondre à ta demande :

Pour le répertoire de connexion, situé dans le répertoire /chrisAUABIN_, le .ssh est :
drwxr-xr-x 2 chrisAUBIN_ chrisAUBIN_ 1024 2008-05-15 00:56 .ssh

Pour le répertoire de connexion lui-même :
drwxr-xr-x 4 chrisAUBIN_ chrisAUBIN_ 1024 2008-05-15 00:54 chrisAUBIN

Pour authorized_keys :
-rw------- 1 chrisAUBIN_ chrisAUBIN_ 576 2008-05-15 00:56 authorized_keys

Et là… je vois que je suis en lecture écriture pour l’owner mais pas pour les groupes. Je vais changer ça et mettre un droit en lecture seule (je ne vois pas en quoi ça peut poser un pb, vu que seul le user propriétaire peut y faire qq chose). Il faudrait qu’il soit en droit 444?

Pour ce qui est de la clé privée, il faudrait qu’elle ait des droits 400, alors?

Thx, François.

#7

C’est là ou tu te plantes. C’est pas la clef publique mais la clef privée qu’il faut importer et transformer dans puttygen.

  • générer la paire sur le serveur Debian
  • clef publique sur le serveur (authorized_keys)
  • clef privée copiée, importée et transformée dans puttygen sur le windows

Ca marche très bien je l’utilise pour putty en console et également winscp.

#8

Merci pour ta réponse!

Ok… Je vais voir ça. Humpf… tu parles d’une erreur, encore… Et pour les droits, je dois les attribuer à qui et “combien”?

Ce que je veux dire : pour l’utilisateur Toto, par exemple : le propriétaire du fichier authorized_key doit être toto, je suppose? Idem pour le .ssh? au niveau des groupes? Rien de spécial (root? l’utilisateur toto?).

Je dois en quel niveau de droits? 444? 440, 400?

Dernière question, mon répertoire de connexion pour le user “chrisAUBIN” se situe dans /chrisAUBIN et non dans un /home/chrisAUBIN.

Or au niveau du fichier sshd_config, nous avons :
AuthorizedKeysFile %h/.ssh/authorized_keys

Tel quel, j’irais bien croire, avec le recul que le %h signifie en fait /home. Je crois qu’on peut avoir %% ou même rien du tout… Il se pourrait donc que j’ai mal configuré mon truc, ici. C’est pareil : j’ai des difficultés à trouver une information claire. Tu saurais ce qu’il en est? Quelle est la différence, exactement?

Thx! :smiley:
Chris

#9

Tu as un tuto dans le truc et astuces. authorizedkeys ne doit pas être en écriture pour les autres, tu peux le mettre en 644 par exemple.

%h est le home indiqué dans /etc/passwd, le répertoire de login de l’utilisateur. Tu peux éventuellement mettre un lien.

La clef publique est celle qu’on donne, la clef privée t’est personnelle et doit rester dans ton répertoire. Vérifie que ta clef ne soit pas dans la liste noire sortie dernièrement, tu seras blaqueboulée par le serveur sinon.

#10

La clef publique doit être intégrée au fichier authorized_keys de l’utilisateur avec lequel tu te connectes.
En admettant que tu te connectes en user “toto” à partir de putty, il faudra alors que dans le ~/.ssh/authorized_keys de toto il y ait ta clef publique renseignée.
Pour les droits ce sont des droits classiques. Sur le fichier authorized_keys de toto, c’est du rw r r. L’important est de cacher les clefs privées, pas les clefs publiques. Par contre il faut bien entendu que le fichier appartienne à ton utilisateur.
Concernant le %h, c’est pas le /home mais le “host” donc surement le répertoire user. Dans ton cas (bizzare) c’est donc /chrisAUBIN et donc /chrisAUBIN/.ssh

Résumons :
Au final tu devras donc avoir un fichier “toto rw r r toto toto /chrisAUBIN/.ssh/authorized_keys” qui contient ta clef publique.

#11

“Tu as un tuto dans le truc et astuces.”

Sur le site? Ok, je vais chercher. J’ai trouvé évidemment pas mal de choses sur le sujet mais ça ne m’a pas toujours paru très clair.

“authorizedkeys ne doit pas être en écriture pour les autres, tu peux le mettre en 644 par exemple.”

Ok, en 440 pour authorized_keys et 644 pour le .ssh, par exemple?

%h est le home indiqué dans /etc/passwd, le répertoire de login de l’utilisateur. Tu peux éventuellement mettre un lien.

Ah! Ok. je saisis la nuance. Dans ce cas %% renverrai à quoi? et si l’on ne met rien, cela renverrai à qq chose? Quand tu parles de mettre un lien, qu’est ce que tu entends par là? Un lien symbolique? Tu peux expliciter? :slightly_smiling:

“Vérifie que ta clef ne soit pas dans la liste noire sortie dernièrement, tu seras blaqueboulée par le serveur sinon.”

Je serai “blackboulé”, tu veux dire lol. Ok. Je ne savais pas qu’il y avait une liste noire quelque part… oopppss… je n’ai rien paramétré de spécial par rapport à ça. Il y a une blacklist quelque part, avec ssh? Ok… je vais chercher un peu.

#12

Petite précision nécessaire, ceci est bien vrai dans le cas d’une utilisation “classique” de SSH. La procédure avec putty et puttygen est un peu tordue et inverse les utilisations de clefs privées/publiques alors que les clefs ont été générées sur le serveur.
La clef privée de toto n’est donc pas dans le répertoire .ssh mais sur Windows, et c’est bien la clef publique qui reste sur le serveur.
Je dis pas cela pour contrarier mais pour éviter les incompréhensions :mrgreen:

#13

lol, oui, mon cas est bizarre… je ne voulais pas que mon user apparaisse dans les répertoire de /home… disons que j’avais mes raisons, même si celles-ci ne sont peut-être pas aussi utile que je le pensais au départ.

Cela étant, je suis à 755 sur mon répertoire chrisAUBIN,

Pareil pour le .ssh.

et hier, j’avais ramené les droits en 400 pour le authorized_key, avec pour proprio chrisAUBIN et idem pour le groupe (ça ne marche pas plus…)

Le répertoire de connexion est situé au bon endroit, à savoir dans /chrisAUBIN. Donc, ça, c’est ok.

Je fais immédiatement la modif’ :
je suis maintenant en -rwxr–r-- 1 sur authorized_key.

Et je me suis mis en 644 sur le répertoire .ssh… C’est mieux?

#14

superlemmings, non c’est normal. Il y a deux types de clefs dans ssh:

  1. La clef identifiant la machine, le serveur: clef privée sur le serveur, clef publique dans le known_hosts du client

  2. La clef identifiant le client: clef publique dans .ssh/authorizedkeys du répertoire home du serveur (c’est tout pour le serveur) et clef privé sur le poste client. Si ce poste client est un linux, cette clef privée doit être dans le .ssh sous un nom donné (id_dsa par défaut) et associé à la machine (j’ai plusieurs clefs par exemple et n’ai pas à préciser laquelle utiliser quand je vais sur une machine). Sous putty, il faut donc mettre la clef privée.

Un tuto est là http://forum.debian-fr.org/viewtopic.php?f=8&t=5472

Sinon, il y a eu un pbm spécifique à Debian dernièrement et il est possible que des clefs faibles circulent et soit générée par une etch non à jour. Du coup un paquet openssh-blacklist est installé lors de la mise à jour et invalide toute connexion ssh fait avec l’aide d’une de ces clefs (l’empreinte de la clef est vérifiée). La commande ssh-vulnkey te dit si une des clefs est sur liste noire ou non.
Pour le répertoire .ssh:
Mets les droits 700 (rwx------):
Mets les droits 600 a tes clefs privés.
Vérfies les propriétés.

#15

“Petite précision nécessaire, ceci est bien vrai dans le cas d’une utilisation “classique” de SSH. La procédure avec putty et puttygen est un peu tordue et inverse les utilisations de clefs privées/publiques alors que les clefs ont été générées sur le serveur.
La clef privée de toto n’est donc pas dans le répertoire .ssh mais sur Windows, et c’est bien la clef publique qui reste sur le serveur.
Je dis pas cela pour contrarier mais pour éviter les incompréhensions”

Autrement dit, au moment de générer les clés : je migre la clé privé sur mon poste, comme d’hab’ et la clé publique, hop dans authorized_key (que ce soit bien clair).

Par curiosité, tu as déjà testé le package puttygen, sur Debian ou autre? En ligne de commande, comme je l’ai mis au début du sujet?

#16

Sonador, oui ce qu’il dit est exact sauf sur l’aspect tordu: c’est l’utilisation normale des clefs: la clef privé ne quitte jamais celui à qui elle appartient.

#17

Ok.

La commande ssh-vulnkey n’a pas l’air d’exister. Je vais voir pour l’installer.

Donc : j’applique les droits tels que tu me les as indiqués.
Je vais recréer des clés, avec ssh-key.

La clé publique dans authorized_keys, situé dans .ssh.

Et la privée je me la renvoie par mon Samba, par exemple, sur mon poste. Cette clé privée devra être en droit 600. Le .ssh devra être en droit 700 et le répertoire /chrisAUBIN, contenant le .ssh en droit 755, par exemple.

Cette clé, je vais la transformer en .ppk via puttygen (en l’important). je ne sais plus si je dois faire quelque chose de spécifique sur authorized_keys pour qu’il y ait compatibilité avec le client… Pour les droits, en tout cas, c’est fait. Thx.

Je vais regarder le tuto que tu m’as mis en lien et je fais un test.

Thx!!
Chris

#18

mmm j’ai installé le packetage relatif à openssh-blacklist.

Multipass:/chrisAUBIN/.ssh# apt-cache search ssh-vulnkey
openssh-blacklist - list of blacklisted OpenSSH RSA and DSA keys
Multipass:/chrisAUBIN/.ssh# apt-get install openssh-blacklist
…

Multipass:/chrisAUBIN/.ssh# ssh-vulnkey
-su: ssh-vulnkey: command not found
Multipass:/chrisAUBIN/.ssh# apt-get install ssh-vulnkey
Lecture des listes de paquets… Fait
Construction de l’arbre des dépendances… Fait
E: Impossible de trouver le paquet ssh-vulnkey
Multipass:/chrisAUBIN/.ssh# apt-cache show ssh-vulnkey
W: Impossible de trouver le paquet ssh-vulnkey
E: Aucun paquet n’a été trouvé

Y a qq chose à savoir au sujet de cette commande? J’aurais pensé qu’elle s’installerait avec le package openssh-blacklist, du coup.

Thx
Multipass:/chrisAUBIN/.ssh#

#19

Ah… bon, j’ai fait ceci :
ssh-keygen -t rsa

Une fois la clé créé :
cp id_rsa.pub authorized_keys

J’ai ensuite renvoyé la clé dans mon partage :
cp id_rsa /home/Partage

Une fois récupéré j’ai ouvert puttygen, effectué la conversion en .ppk. Et fait une tentative.
Le résultat est le même…

Faut vraiment que je liste le lien que tu m’as passé, fran. Si je trouve une incohérence avec ce que j’ai fait… diable… Damned… il est où le problème…

Thx,
Chris

#20

[quote=“sonador”]Une fois récupéré j’ai ouvert puttygen, effectué la conversion en .ppk. Et fait une tentative.
Le résultat est le même… [/quote]
Tentative… oui mais est-ce que tu dis bien à PUTTY de se servir de cette clef ? Il ne suffit pas de convertir en .PPK il faut quand même indiquer à putty d’utiliser ce fichier de clef pour initier la connexion.

Quel est le message de refus de putty lors de la connexion ? S’il n’y en a pas et qu’il te présente le login/password, c’est qu’il ne tient pas compte du fichier de clef.

Pour la mettre sur windows ça n’a pas trop d’influence :smiley:

J’ai mal exprimé mon propos. Ce qui est anormal au sens courant dans l’utilisation de cette méthode, c’est que ce n’est pas le client qui génère son couple de clef mais la machine accédée. En l’occurence le serveur génère la clef “privée” et il en fait cadeau au client. Disons que c’est un peu contraire aux principes de sécurités qu’on connait…
Mais bon c’était pour l’anectode, aucune influence que la résolution du problème. :wink: