Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

ssh acces par key sélectif

BrunoL

Bonjour,

suite à install d'ubuntu server 20.04. J'ai créé un user web_adm en plus du user bruno qui a fait l'install.
Tout se passe bien, bruno se connecte en ssh par mot de passe à web_adm sur localhost et vice-versa web_adm sur bruno.

Je modifie le type de connexion pour passer par key. Échange de key et modification de /etc/sshdconfig.
Là pb bruno se connecte bien à web_adm (sans psw) mais impossible que web_adm se connecte à bruno (sans psw).

Première idée de solution comparer les 2 users pour déterminer ce qui les distingue. Ceci fait rien ne les distingue les key sont bonnes et au bon endroit, les propriétés des fichiers sont identiques.

En mode verbeux et aprés avoir autorisé les connexion par key et psw, un lancement ssh indique :

...
Ubuntu 20.04.1 LTS
debug1: Authentification that can continue: publickey,password
debug1: Next authentification method: publickey
debug1: Offering public key: /home/web_adm/.ssh/id_rsa RSA SHA256:... agent
debug1: Authentification that can continue: publickey,password
... il cherche les autres mode de connexion sur key en vain et fini en
debug1: debug1: Authentification that can continue: password
... sur quoi web_adm se connecte par psw

Le ssh_agent -l est ok et donc je suis arrivé au bout et ne sait plus d'où cela peut venir.
Qu'ai-je loupé. Merci pour votre aide.

bruno

Bonjour,

Pas sûr de bien comprendre… En particulier parce que je ne vois pas l'intérêt de faire cela sur localhost.

Pour que l'utilisateur bruno puisse se connecter sur la machine serveur en tant que web_adm avec authentification par clés :

bruno@client:~$ ssh web_adm@serveur

il faut que la clé publique de bruno soit dans le fichier /home/web_adm/.ssh/authorized_keys sur serveur (emplacement par défaut mais cela peut-être ailleurs)

Pour faire l'inverse il faut que la clé publique de web_adm soit dans le fichier /home/bruno/.ssh/authorized_keys sur serveur :

web_adm@client:~$ ssh bruno@serveur

BrunoL

Merci Bruno pour ta réponse.
L'intérêt de le faire en localhost est de préparer une petite séance de formation à linux pour quelques jeunes (et moins jeunes ;-) intéressés. À mon avis cela leur permettra de maîtriser efficacement le concept de réseau et quelques manip simple sans leurs demander de toucher à rien sur leurs machines. Sauf à régler quelques problèmes comme je viens de le faire.

Sans en faire une règle, j'ai constaté que sur mon install U20.4 serveur, les utilisateurs sont dotés d'un répertoire .ssh avec de mauvaises propriétés. Ce que j'ai fini par identifier et régler (c'est .ssh lui-même). Ce que je ne comprends toujours pas c'est qu'avec la même config le user (admin du fait qu'il a fait l'install) ne peut pas être contacté en ssh par key alors qu'un autre user créé post install lui le peut ...
J'ai au passage du me battre un peu avec ssh-agent qui pollue un peu la situation avec des messages d'anomalies.

Nota : durant ma correction j'ai utilisé des users du réseau "réel" et le problème était identique.

bruno

BrunoL a écritSans en faire une règle, j'ai constaté que sur mon install U20.4 serveur, les utilisateurs sont dotés d'un répertoire .ssh avec de mauvaises propriétés.

C'est à dire ?
S'il s'agit des droits d'accès, la seule restriction concerne les fichiers de clé privées qui doivent être accessibles uniquement à leur propriétaire.

BrunoL a écritCe que je ne comprends toujours pas c'est qu'avec la même config le user (admin du fait qu'il a fait l'install) ne peut pas être contacté en ssh par key alors qu'un autre user créé post install lui le peut ...

Il n'y a aucune raison que ce soit le cas si les clés publiques ont été copiées au bon endroit. Peu importe que l'utilisateur soit « admin » ou pas.

BrunoL a écrit J'ai au passage du me battre un peu avec ssh-agent qui pollue un peu la situation avec des messages d'anomalies.

ssh-agent n'a rien à voir là dedans. Il sert juste à conserver les clés de l'utilisateur afin qu'il puisse se reconnecter sans avoir à re-saisir les mots de passe des clés privées.

BrunoL a écrit Nota : durant ma correction j'ai utilisé des users du réseau "réel" et le problème était identique.

Tu as donc dû reproduire la même erreur de manipulation.

Tu as marqué le sujet comme résolu, mais on ne sait absolument comment tu as résolu le problème :/

BrunoL

Bruno, la création du répertoire .ssh est faite avec [r_x] ce qui provoque le dysfonctionnement décrit précédemment. La solution est un .ssh avec [rwx]. À l'évidence les règles de droit d’accès concernent plus que les keys ce que je croyais également et qui m'a fait perdre beaucoup de temps.

Après cette modification tout est rentré dans l'ordre. Les keys et autres authorized_keys étaient donc bien à leur place et avec des propriétés correctes.

La situation me semble délicate car dans ma recherche de solution j'ai essayé de faire de mon second utilisateur un clone de celui ayant fait l'installation et donc l'ai rattaché au group adm, ce qui n'a rien changé. J'en déduis que l'utilisateur qui à réalisé l'instal a un profil plus subtil que cela.

J'ai évoqué ssh-agent car sur une install avec bureau ce service est activé en permanence. Or sur un serveur dans la mise en œuvre des key pour le fonctionnement du ssh il est nécessaire mais pas activé. Ce qui oblige à faire un

eval $(ssh-agent)

après chaque reboot voire ultérieurement car il semble s'arrêter de façon aléatoire ce qui a provoqué des messages polluant ma recherche de solution. D'où l'évocation de cet outil ...

Et je confirme que le problème est résolu car tout fonctionne dorénavant 😉

bruno

BrunoL a écritBruno, la création du répertoire .ssh est faite avec [r_x] ce qui provoque le dysfonctionnement décrit précédemment. La solution est un .ssh avec [rwx]. À l'évidence les règles de droit d’accès concernent plus que les keys ce que je croyais également et qui m'a fait perdre beaucoup de temps.

Non.
Pour être sûr, je viens de tester avec un utilisateur qui n'avait pas de clés SSH. Après création des clés avec la commande :

ssh-keygen t ed25519

et validation de l'emplacement par défaut .ssh/ed25519 le dossier est créé avec les bons droits d'accès :

lo@machine:~$ ls -al .ssh
total 16
drwx------  2 lo lo 4096 déc.   4 18:48 .
drwxr-xr-x 17 root root 4096 déc.   4 18:48 ..
-rw-------  1 lo lo  399 déc.   4 18:48 id_ed25519
-rw-r--r--  1 lo lo   94 déc.   4 18:48 id_ed25519.pub

Et quand bien même le dossier .ssh aurait des droits r-x------, cela fonctionnerait quand même.
Ce n'est donc pas l'origine de ton problème.

BrunoL a écrit La situation me semble délicate car dans ma recherche de solution j'ai essayé de faire de mon second utilisateur un clone de celui ayant fait l'installation et donc l'ai rattaché au group adm, ce qui n'a rien changé. J'en déduis que l'utilisateur qui à réalisé l'instal a un profil plus subtil que cela.

Un utilisateur d'Ubuntu peut acquérir les droits d'administration (root) parce qu'il est dans le groupe sudo et que les membres de ce groupe est autorisé à tout faire par sudoers. Je t'invite à consulter la documentions sur ces sujets. Mis cela n'a aucun lien avec SSH et l'authentification par clés.