[Tuto] SSH, mode console avec échange de clé : Une seule règle pour accéder à tous vos serveurs SSH

Bambusa29

Chevalier Jedi
10 Avril 2022
321
144
83
Bonjour,

Petit Tuto rapide pour gérer simplement la configuration SSH coté client pour accéder en mode console à vos serveurs avec échanges de clés.
Le but est d'avoir une seule règle pour accéder à tous vos serveurs SSH.

1) Préambule
2) Configuration optimale avec échange de clés
3) Configuration coté serveur
4) Exemple utilisation
5) NB : Création des clés
6) Utilisation avec Dolphin

1) Préambule

Par défaut le fichier de configuration 'config' du client SSH se trouve dans le répertoire .ssh, à la racine de votre répertoire utilisateur /home
Dans ce même répertoire se trouve aussi vos clés publiques et privés générés localement (cas standard, voir plus loin).

Ce fichier de configuration est optionnel, mais il vous facilite bien la vie quand vous gérer plusieurs serveurs SSH.

2) Configuration optimale avec échange de clés

Voici ma config avec un seul bloc pour accéder à tous mes serveurs en SSH avec une seule règle. Je vais utiliser un nom de domaine locale pour accéder à mes serveurs. Libre à vous de déclarer les URL de vos machines au niveau de votre dns local ou de votre fichier /etc/hosts

On vas s'arrêter dessus quelques minutes pour le détailler :

Code:
Host *
    HostName %h.yannick.lan
    User yannick
    Port 1122
    IdentityFile /home/yannick/.ssh/%h.pub
    IdentitiesOnly yes
    StrictHostKeyChecking yes

- Host : c'est l'alias en quelque sorte qui définit votre bloc. Vous pourrez vous connecter directement a votre serveur avec cet alias :

Code:
ssh alias

Remarque : ici, j'utilise une '*' pour indiquer que l'alias est dynamique et peut être n'importe quoi

- HostName : les deux caractères '%h' (hôte destinataire) indique que j'utilise l'alias du Host pour former mon url.
- User : l'utilisateur qui se connectera en SSH
- Port : Le port qui n'est pas standard
- IdentityFile : Indique le chemin de la clé privée. Ma clé devra donc se nommer 'alias.yannick.lan' (alias.yannick.lan.pub ici car je ne garde que la clé publique)

Remarque : J'utilise ici une subtilité de ssh-agent couplé avec mon coffre fort numérique pour ne garder que la clé publique localement. La clé privée est quant a elle dans mon coffre fort numérique et je l'ai supprimé localement après l'avoir créer.

- IdentitiesOnly : Indique que l'on peut se connecter qu'avec un échange de clé
- StrictHostKeyChecking : indique que je n'accepte que les connexions avec les serveurs distants enregistrées dans le fichier local 'known_hosts' (se trouve dans le même répertoire .ssh)

Remarque : Je devrais donc au préalable faire un premier 'ssh yannick@alias.yannick.lan -p 1122' pour enregistrer le serveur dans le fichier 'known_hosts'.
Attention : vous devez utilisez exactement le même HostName lors de l'enregistrement. Si vous utilisez par exemple son adresse IP à la place de son nom de domaine, la connexion par alias sera refusée.

3) Configuration coté serveur :

J'ai le même fichier de configuration sur tous mes serveurs. Même chose que le coté client; il n'accepte que les connexion par échange de clés.
Il n'autorise les accès que venant de mon PC.

Le fichier se trouve dans /etc/ssh/sshd_config.d/

Code:
Port 1122
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 2m
PermitRootLogin no
AllowGroups ssh
AllowUsers yannick@192.168.xx.xx
PermitEmptyPasswords no
StrictModes yes
MaxAuthTries 6
MaxSessions 10

Match user yannick
    PubkeyAuthentication yes
    PasswordAuthentication no
    ChallengeResponseAuthentication no
Match all

X11Forwarding no

Il faudra aussi copier la clé publique dans le fichier 'authorized_keys' du répertoire .ssh de l'utilisateur sur le serveur.

Faire un 'chmod 400 authorized_keys' et un 'chmod 700 .ssh'

4) Exemple utilisation :

J'ai par exemple une machine qui s'appel "apache" et l'autres "jellyfin"

J'y accéderais donc en tapant simplement : ssh apache et ssh jellyfin.

5) NB : Création des clés :
J'utilise cette commande ci avec OpenSSH pour générer mes clés :

Code:
ssh-keygen -t ed25519 -C "alias@alias.yannick.lan" -N "passwd" -f /home/yannick/.ssh/alias

J'utilise l'algo 'ed25519' qui génère une clé plus courte mais qui est considéré comme plus sur que le RSA.

L'option -N "password" est optionnelle. Elle rajoute une "passphrase" pour le chiffrage/décryptage de la clé. Elle est gérée automatiquement par mon coffre fort. Si pas de mot de passe, vous devez passez une chaîne vide : -N "".

6) Utilisation avec Dolphin

Pour ouvrir une session SFTP avec Dolphin (cela devrait être pareil avec Nautilus), nous pouvons aussi utilisez les alias tel que définit dans le post initial.

Prenons l'exemple d'un host alias qui héberge un serveur web alias qui se trouve dans /var/www :

Code:
fish://alias/var/www/alias
 
Dernière édition par un modérateur:
Très sympa ce guide , je pense que je vais m’en servir pour mes différents serveurs 😊
J’aurais probablement des questions quand je commencerais sa mise en place 😁
 
  • J'aime
Réactions: Bambusa29
Je ne peux plus éditer mon message !!

6) Utilisation avec Dolphin

Pour ouvrir une session SFTP avec Dolphin (cela devrait être pareil avec Nautilus), nous pouvons aussi utilisez les alias tel que définit dans le post initial.

Prenons l'exemple d'un host alias qui héberge un serveur web alias qui se trouve dans /var/www :

Code:
fish://alias/var/www/alias
 
Très intéressant, merci à toi. Pour stocker les clés tu utilises quel coffre ?
 
Très intéressant, merci à toi. Pour stocker les clés tu utilises quel coffre ?

J'utilise KeePassXC pour sa facilité de gestion (j'utilisais Vaultwarden auparavant), mais n'importe quel gestionnaire de mots de passe pouvant communiquer avec un agent ssh fera l'affaire (cela limite le choix).
 
Ah c'est bien ce qu'il me semblait j'utilise Vaultwarden et je connaissais pas cette fonctionnalité.
 
Aller, j'essaye de me trouver un peu de temps ce matin pour mettre en place ces clés SSH sur les différents serveurs, ce sera plus pratique que les mdp.
 
@Bambusa29 Petites questions avant que je ne me lance,
Est-ce qu'on peut toujours utiliser le couple login/mdp quand on a activé la clé SSH ?

Et quid d'une restauration de la clé sur un nouveau système ? On peut réutiliser une clé qu'on avait créé sur un système fraichement installé ? Ou bien faut-il tout recréer de 0 ?
Je demande ça, car je fais pas mal d'essais en ce moment, et il m'arrive fréquemment de réinstaller complètement l'OS.
 
3) Configuration coté serveur :

J'ai le même fichier de configuration sur tous mes serveurs. Même chose que le coté client; il n'accepte que les connexion par échange de clés.
Il n'autorise les accès que venant de mon PC.

Le fichier se trouve dans /etc/ssh/sshd_config.d/
@Bambusa29 Comment tu nommes ce fichier de configuration ? config comme le fichier sur le client ?

Tu parles aussi fréquemment de l'utilisation de ton gestionnaire de mot de passe. Sais-tu comment faire avec Bitwarden ? il n'est pas présent dans un terminal...

edit : encore autre chose :ROFLMAO:
Quid de la connexion avec des users différents entre différentes machines ?
Par exemple, sur les NUC, je vais me connecter en root, alors que sur les nas ce sera avec un user différents pour chacun...
Comment je peux adapter le fichier de configuration du client ?
 
Dernière édition:
@Bambusa29 Comment tu nommes ce fichier de configuration ? config comme le fichier sur le client ?

Peut importe le nom, il faut seulement que le fichier soit sous le forme *.conf (ici ssh_keys.conf)

Voila un exemple :

Code:
Port 1122

SyslogFacility AUTH
LogLevel INFO

LoginGraceTime 2m
PermitRootLogin no
AllowUsers yannick@192.168.2.5 rsync@192.168.2.249 ssh_sudo@192.168.2.249
StrictModes yes
MaxAuthTries 6
MaxSessions 10
X11Forwarding no

Match user ssh_sudo
    PubkeyAuthentication yes
    PasswordAuthentication no
    ChallengeResponseAuthentication no
Match all

Match user rsync
    PubkeyAuthentication yes
    PasswordAuthentication no
    ChallengeResponseAuthentication no
Match all

Match user yannick
    PubkeyAuthentication yes
    PasswordAuthentication no
    ChallengeResponseAuthentication no
Match all

Tu parles aussi fréquemment de l'utilisation de ton gestionnaire de mot de passe. Sais-tu comment faire avec Bitwarden ? il n'est pas présent dans un terminal...

Je n'utilise plus BitWarden (Vaultwarden); je ne saurais te dire s'il intègre un agent ssh : c'est lui qui fait le lien avec openssh et gère les clés. Le gestionnaire de mot de passe stock la clé privée et publi. Localement dans le répertoire .ssh coté client, il y a la clé publique pour faire le lien avec le gestionnaire de mot de passe.

edit : encore autre chose :ROFLMAO:
Quid de la connexion avec des users différents entre différentes machines ?
Par exemple, sur les NUC, je vais me connecter en root, alors que sur les nas ce sera avec un user différents pour chacun...
Comment je peux adapter le fichier de configuration du client ?

Tu peux indiquer tout ca dans ton fichier config (dans le répertoire .ssh) coté client.
Par exemple chez moi, j'ai une règle particulière pour me connecter en ssh sur mon firewall qui n'accepte que le 'root' et un port particulier :

Code:
Host *
    HostName %h.yannick.lan
    User yannick
    Port 1122
    IdentityFile /home/yannick/.ssh/%h.pub
    IdentitiesOnly yes
    StrictHostKeyChecking yes

Host ipfire
    HostName 192.168.2.250
    User root
    Port 222
    IdentityFile /home/yannick/.ssh/ipfire.pub
    IdentitiesOnly yes
    StrictHostKeyChecking yes
 
  • J'aime
Réactions: MilesTEG
Ok super !
Merci pour ces infos/conseils.

Tu me confirmes que le nom du fichier de configuration peut-être ssh_keys.conf à la fois sur le client et sur les serveurs ?

Pour Bitwarden, je crois qu'il faut passer par bitwarden-cli, mais ça m'a l'air bien lourd à gérer... car pas de Touch-ID pour déverrouiller...

Tu utilises quoi du coup à la place de Bitwarden ?

L'option -N "password" est optionnelle. Elle rajoute une "passphrase" pour le chiffrage/décryptage de la clé. Elle est gérée automatiquement par mon coffre fort. Si pas de mot de passe, vous devez passez une chaîne vide : -N "".
Et à propos du passphrase, que je vais probablement mettre.
Il faudra le taper ou en faire un copier/coller pour valider la connexion, c'est ça ?
La clé privée n'est pas à entrer, c'est ça ?


Du coup j'envisage de procéder ainsi :

Avec iTerm2, qui possède un gestionnaire de mot de passe que j'utilise actuellement :
1712738806922.png

  • Je stocke les clés dedans en plus de les copier/coller dans Bitwarden (même si je pense que ça ne servira pas) :
  • Je stocke les mots de passe des différentes clés dedans, + dans Bitwarden ;
  • J'accède en SSH à mes serveurs via la connexion clé privée / publique + MDP de clé

Avec Tabby qui possède aussi un gestionnaire de mot de pass & Clé plus avancé que iTerm2 :
1712738856909.png

Avec tabby que je n'utilise pas trop, car le gestionnaire de favoris de connexion n'est pas aussi bien selon moi que celui d'iTerm2, mais son gestionnaire de mot de passe est bien meilleur : il peut stocker les clés privées.



Me reste une dernière question : je me suis crée un script pour faire le tour des serveurs et de les mettres à jour (apt update && apt upgrade) via une connexion ssh pour laquelle je donne un mot de passe unique (oui c'est pas bien) pour root via une invite (pas mis en dur dans le script), et après je n'interagis plus.
Comment pourrais-je faire pour faire la même chose avec le système de clés ?
 
Tu peux indiquer tout ca dans ton fichier config (dans le répertoire .ssh) coté client.
Par exemple chez moi, j'ai une règle particulière pour me connecter en ssh sur mon firewall qui n'accepte que le 'root' et un port particulier :

Code:
Host *
HostName %h.yannick.lan
User yannick
Port 1122
IdentityFile /home/yannick/.ssh/%h.pub
IdentitiesOnly yes
StrictHostKeyChecking yes

Host ipfire
HostName 192.168.2.250
User root
Port 222
IdentityFile /home/yannick/.ssh/ipfire.pub
IdentitiesOnly yes
StrictHostKeyChecking yes
Il n'y a pas d'ordre à respecter pour faire les différents host ?
J'ai lu que ça matchait tout ce qui était matchable, mais que seul les premières occurences des paramètres comme "port" était utilisés.
 
Ok super !
Merci pour ces infos/conseils.

Tu me confirmes que le nom du fichier de configuration peut-être ssh_keys.conf à la fois sur le client et sur les serveurs ?

Coté serveurs : *.conf

serveur.png


Coté client : config
(Au passage : bien vérifier que les fichiers de clés ont un 'chmod 400'. Je vois que c'est pas le cas pour les dernières chez moi :rolleyes: )

client.png

Pour Bitwarden, je crois qu'il faut passer par bitwarden-cli, mais ça m'a l'air bien lourd à gérer... car pas de Touch-ID pour déverrouiller...

Tu utilises quoi du coup à la place de Bitwarden ?

J'utilise le client KeePassXC. Je fais des copies de la BD de temps en temps dans NextCloud pour les autres périphériques.

Et à propos du passphrase, que je vais probablement mettre.
Il faudra le taper ou en faire un copier/coller pour valider la connexion, c'est ça ?
La clé privée n'est pas à entrer, c'est ça ?

La pass phrase est aussi stocké dans le gestionnaire de mot de passe, donc l’échange avec le serveur est automatique; je n'ai rien a rentrer, juste l'alias SSH présent dans mon fichier config.

Du coup j'envisage de procéder ainsi :

Avec iTerm2, qui possède un gestionnaire de mot de passe que j'utilise actuellement :​

Voir la pièce jointe 11847

  • Je stocke les clés dedans en plus de les copier/coller dans Bitwarden (même si je pense que ça ne servira pas) :
  • Je stocke les mots de passe des différentes clés dedans, + dans Bitwarden ;
  • J'accède en SSH à mes serveurs via la connexion clé privée / publique + MDP de clé

Avec Tabby qui possède aussi un gestionnaire de mot de pass & Clé plus avancé que iTerm2 :​

Voir la pièce jointe 11848

Avec tabby que je n'utilise pas trop, car le gestionnaire de favoris de connexion n'est pas aussi bien selon moi que celui d'iTerm2, mais son gestionnaire de mot de passe est bien meilleur : il peut stocker les clés privées.

J'utilisais Tabby aussi avant pour gérer mes connexions SSH avec clés.

Me reste une dernière question : je me suis crée un script pour faire le tour des serveurs et de les mettres à jour (apt update && apt upgrade) via une connexion ssh pour laquelle je donne un mot de passe unique (oui c'est pas bien) pour root via une invite (pas mis en dur dans le script), et après je n'interagis plus.
Comment pourrais-je faire pour faire la même chose avec le système de clés ?

Reprend l'exemple de mon fichier config et remplace les clés publiques par des clés privées (qui seront donc stockés coté client dans ton répertoire .ssh). Par contre tu devra rentrer la passPhrase la première fois. Normalement l'agent SSH gardera l'info en mémoire tant que tu ne le tue pas.
L'avantage d'un gestionnaire de mot de passe avec agent ssh intégré, est que quand le coffre fort se verrouille, l'agent ssh est tué (ca limite le risque de vol de clés via un 'memory Dump', d'ou l'utilité de la PassPhrase).
 
Dernière édition:
Coté serveurs : *.conf

serveur.png


Coté client : config

client.png
Donc le fichier de configuration coté client doit s'appeler config. C'est ça ?
Si oui, pourrais-tu clarifier ton tuto à ce sujet, s'il te plait :)
J'utilise le client KeePassXC. Je fais des copies de la BD de temps en temps dans NextCloud pour les autres périphériques.
Ok, et donc KeePassXC possède un gestionnaire de clé ssh et un agent SSH.
Faut donc que j'investigue sur Bitwarden-CLI un de ces 4...

La pass phrase est aussi stocké dans le gestionnaire de mot de passe, donc l’échange avec le serveur est automatique; je n'ai rien a rentrer, juste l'alias SSH présent dans mon fichier config.
Ok, ça confirme ce que je pensais.
Il faudra que je rentre la clé SSH et aussi le mot de passe. Ce n'est pas ouf... Je gagne en sécurité, mais je perd en praticité...

J'utilisais Tabby aussi avant pour gérer mes connexions SSH avec clés.
Ok, et pourquoi n'utilises-tu plus Tabby ? Tu es passé sur quoi ?
Et avec Tabby, tu n'avais pas besoin de rentrer la clé privée, c'est ça ? Et le passphrase ? Il le stockait également ?

Reprend l'exemple de mon fichier config et remplace les clés publiques par des clés privées (qui seront donc stockés coté client dans ton répertoire .ssh).
Je n'ai pas tout saisi :ROFLMAO:


Par contre tu devra rentrer la passPhrase la première fois. Normalement l'agent SSH gardera l'info en mémoire tant que tu ne le tue pas.
L'avantage d'un gestionnaire de mot de passe avec agent ssh intégré, est que quand le coffre fort se verrouille, l'agent ssh est tué (ca limite le risque de vol de clés via un 'memory Dump', d'ou l'utilité de la PassPhrase).
Ok, ça rejoint mon idée de creuser BW CLI.
 
Encore une question :ROFLMAO:
La ligne de la configuration suivante du serveur :
Code:
AllowUsers yannick@192.168.xx.xx
Comment je peux ajouter une autre IP autorisée ? car mon mac est connecté soit en wifi soit en câble, et donc avec deux IP différentes.
 
Encore une question :ROFLMAO:
La ligne de la configuration suivante du serveur :
Code:
AllowUsers yannick@192.168.xx.xx
Comment je peux ajouter une autre IP autorisée ? car mon mac est connecté soit en wifi soit en câble, et donc avec deux IP différentes.

Dans mon fichier de config coté serveur, j'autorise 3 accès provenant de deux IP différentes : Mon PC de travail et le Syno.
Tu sépare chaque URL d'un espace qui sont sous la forme user@IP ou user@domaine

Code:
AllowUsers yannick@192.168.2.5 rsync@192.168.2.249 ssh_sudo@192.168.2.249
 
  • J'aime
Réactions: MilesTEG
Donc le fichier de configuration coté client doit s'appeler config. C'est ça ?
Si oui, pourrais-tu clarifier ton tuto à ce sujet, s'il te plait :)
Je ne peux plus le modifier...

Ok, et donc KeePassXC possède un gestionnaire de clé ssh et un agent SSH.
Faut donc que j'investigue sur Bitwarden-CLI un de ces 4...


Ok, ça confirme ce que je pensais.
Il faudra que je rentre la clé SSH et aussi le mot de passe. Ce n'est pas ouf... Je gagne en sécurité, mais je perd en praticité...


Ok, et pourquoi n'utilises-tu plus Tabby ? Tu es passé sur quoi ?
Et avec Tabby, tu n'avais pas besoin de rentrer la clé privée, c'est ça ? Et le passphrase ? Il le stockait également ?

De mémoire, je devais rentrer la Passphrase la 1ere fois.

Je n'ai pas tout saisi :ROFLMAO:

Le fichier config serait presque pareil, sauf la clé privée (sans le .pub) qui doit être indiquer dans la ligne 'IdentityFile' (puisque pas d’interaction avec un gestionnaire de mot de passe) à la place de la clé publique.

Dans une utilisation standard c'est une clé privée qui doit être indiquée dans le ligne 'IdentityFile'. Utilisez une clé publique avec un gestionnaire de mot de passe et agent ssh est juste une astuce (tu trouvera peu d’informations sur cette possibilité). Je crois qu'il n'en parle même pas dans man d'openssh...
Pour moi c'est plus qu'une astuce, c'est un gros plus au niveau de la sécurité (plus de clé privée stockée localement dans le répertoire .ssh coté client)


Code:
Host *
    HostName %h.yannick.lan
    User yannick
    Port 1122
    IdentityFile /home/yannick/.ssh/%h
    IdentitiesOnly yes
    StrictHostKeyChecking yes

Host ipfire
    HostName 192.168.2.250
    User root
    Port 222
    IdentityFile /home/yannick/.ssh/ipfire
    IdentitiesOnly yes
    StrictHostKeyChecking yes

Ok, ça rejoint mon idée de creuser BW CLI.
 
  • J'aime
Réactions: MilesTEG
@Bambusa29
Je me suis fait un petit script pour générer les clés privées et publique de mon client (mon mac).

Mais je me demande s'il est possible d'autoriser une plage d'IP dans la config du serveur car quand je ne suis pas chez moi, je me connecte via un serveur VPN (soit celui du RT2600AC qui me donne une IP soit dans la plage du DHCP de ce dernier pour SSL VPN, soit dans une autre plage pour le L2TP (192.168.10.xxx)), soit avec le Wireguard d'une MV Proxmox qui lui me donne une Ip en 192.168.12.xxx).
Et bien sûr pas moyen de savoir si je vais avoir la même IP que la précédente.

Du coup, comment puis-je faire pour autoriser ces réseaux ?
 
Bon à priori ça doit pouvoir se faire en mettant le masque de sous-réseau, comme ceci :
Code:
AllowUsers root@192.168.2.28 root@192.168.2.30 root@192.168.2.80 root@192.168.2.0/24 root@192.168.10.0/24 root@192.168.2.12/24
Ça te parait correct ?