Bonsoir,
Les spécialistes préconisent pour des raisons de sécurité, une connexion SSH sur SERVEUR par “Authentification par Clef” plutôt que par “Mot de Passe”.
J’ai lu de nombreux posts sur le sujet pour essayer de trouver des réponses claires à mes interrogations (trop évidentes peut être ?)
Il semblerait (mais je me trompe peut être) que l’utilisateur sur le CLIENT soit “obligé ?” de se connecter au moins UNE fois par “Mot de Passe” sur le SERVEUR, afin d’effectuer les opérations nécessaires à l’enregistrement de sa clé. Mais bon, à confirmer ?
Mes questions :
Q1) Concernant le SERVEUR avec l’unique possibilité imposée d’une connexion par “clef”, le réflexe de prime abord serait de dire que pour TOUTE tentative de connexion à venir (via /etc/ssh/sshd_config):
- “PubkeyAuthentication=oui”
- “PasswordAuthentication=non !” (y compris pour la PREMIÈRE connexion de l’utilisateur à partir du CLIENT)
Est-ce exact ?
Dans ce cas, c’est à la charge de l’utilisateur “CLIENT” d’arriver à se connecter sur le SERVEUR en appliquant la méthode de MEO qui va bien (rappelée pour info plus bas).
Mais pour ma part, ayant eu ce premier réflexe, j’ai dû finalement me résigner à d’abord passer “PasswordAuthentication=oui” pour que cela marche (i.e. transfert de clef …)
Sûrement une fausse manipe ou une omission? 
Bien entendu, une fois la manipe réalisée j’ai repassé "PasswordAuthentication=non !"
Cette manipe si elle m’a permis d’aboutir m’étonne, car il est clair que pour moi utilisateur “CLIENT”, je ne suis pas censé avoir de droits “root” sur le SERVEUR (même si là, c’est le cas …).
Q2) Sinon peut être est il inutile de repasser “PasswordAuthentication=non !” car “PubkeyAuthentication=oui” serait prioritaire sur un “PasswordAuthentication=oui” (ce dont je doute …) ?
En tout cas il est étonnant d’avoir les 2 autorisations qui perdurent, car en cas de problème avec la clef (e.g. “phrase de passe” erronée rentrée intentionnellement ou non), si on bascule automatiquement sur le mode de connexion par “Mot de Passe”, c’est exactement le contraire de l’objectif de départ.
Q3) Le fait de pouvoir appliquer les droits adhoc sur les Fichiers/Répertoires (cf. plus bas) ne pose pas de problème à l’utilisateur sur le CLIENT mais sur le SERVEUR en revanche, il n’est pas censé s’y être encore connecté pour le faire ; sauf peut être si une PREMIERE connexion par “Mot de Passe” lui a été autorisée grâce à un “PasswordAuthentication=oui” fixé momentanéement sur le SERVEUR (Ce que j’ai fait en fait …) ou tout autre “stratagème”
Et dans ce cas, qui prévient l’administrateur du SERVEUR de repasser en “PasswordAuthentication=non” ?
Bien sûr celui-ci dispose de moyens de le savoir sans être explicitement “informé” mais bon, je ne suis pas tout seul sur le réseau et si il bascule le SERVEUR en “PasswordAuthentication=non”, le problème va immanquablement se poser pour un nouvel utilisateur qui à son tout voudra initialiser une connexion SSH en mode “Authentification par Clef”.
C’est donc le “Serpent qui se mord la queue” et il y a sûrement une réponse plus appropriée à cette question qui me préoccupe.
Q4) Quelle est la différence entre le “PasswordAuthentication” du “/etc/ssh/sshd_config” sur le SERVEUR et le “PasswordAuthentication” du “/etc/ssh/ssh_config” sur le CLIENT ?
Cela aurait-il un rapport avec la question qui me préoccupe ?
Voilà, merci par avance pour votre attention à la lecture de ce long post ainsi que pour les éléments de réponses que vous pourrez m’apporter.
=====================================
Procédure mise en oeuvre (pour info)
Installation “Debian 7 / SSH Serveur”
A) Machine0=ServCalc
- administrée par “root0”
- utilisateur & MdP : “smecaflux/passflux”
Fichier configuration SSH du “Serveur” : /etc/ssh/sshd_config
- PubkeyAuthentication : “yes” (admin0 IMPOSE la connexion par clef)
- PasswordAuthentication :
- “no” : admin0 IMPOSE la connexion par clef (et donc Authentification par MdP refusée ???)
- ou bien “yes” ??? : admin0 autorise au moins pour la PREMIERE CONNEXION d’un utilisateur afin que celui-ci soit en mesure d’effectuer son TRANSFERT de clef ???)
B) Machine1=WrkStat
- administrée par “root1”
- utilisateur & MdP : “smecaflux/passflux”
Fichier configuration SSH du “Client” : /etc/ssh/ssh_config
- PasswordAuthentication :
- “no” ??? admin1 INTERDIT la connexion “MdP” sur TOUT serveur (la seule justement autorisée par admin0 sur “SerCalc” étant une connexion par “clé”)
- “yes” ??? À priori admin1 de “WrkStat” ne connait pas la politique mise en oeuvre par admin0 de “SerCalc”
-
Génération de la clé : ssh-keygen -t dsa
-
Droits des Répertoires et Fichiers
-
sur le CLIENT :
chmod 755 $HOME
chmod 700 $HOME/.ssh
chmod 600 $HOME/.ssh/* -
sur le SERVEUR :
chmod 755 $HOME
chmod 700 $HOME/.ssh
chmod 600 $HOME/.ssh/*
NB. ??? Sur le SERVEUR cela suppose que l’utilisateur “smecaflux” se soit DEJÀ connecté au moins “1 fois” avec “Mot de Passe” pour appliquer les droits
(PAS par authentification par clé puisque c’est justement ce que l’on cherche à faire …) ???
3)Transfert clé publique “Station => Serveur”
3a)ssh-copy-id -i ~/.ssh/id_dsa.pub smecaflux@ServCalc
ou
3b) cat ~/.ssh/id_dsa.pub | ssh ServCalc "cat - >> ~/.ssh/authorized_keys"
ou
3c)
- scp ~/.ssh/id_dsa.pub ServCalc:/tmp
- smecaflux@ServCalc password ? := passflux (! le MdP que l’on ne devrait justement “jamais” / ou “plus” rentrer puisque connexion par clé )
- ssh smecaflux@ServCalc
- cat /tmp/id_dsa.pub >> ~/.ssh/authorized_keys
- rm /tmp/id_dsa.pub
) !