SSH : administrer à distance
Configuration de SSH
SSH, est un outil génial 🙋. Il vous permettra de vous connecter au serveur à partir d'un autre ordinateur. Vous pourrez alors l'administrer à distance sans devoir y brancher un clavier et un écran. À vrai dire, sauf exception, tous les serveurs sont administrés ainsi, mais vous êtes chez vous après tout, donc vous pouvez faire comme vous voulez.
De plus, SSH est un protocole permettant bien plus : créer des tunnels chiffrés vers votre serveur, avoir un espace de stockage de fichiers en SFTP...
Quoi qu'il en soit, si vous n'avez pas activé SSH lors de l'installation d'OpenBSD, vous pouvez l'activer avec la commande suivante :
# rcctl enable sshd
Bien que ce protocole soit fiable, il faut le garder ainsi et éventuellement éditer la configuration de SSH dans le fichier "/etc/ssh/sshd_config".
- Vous pouvez changer le port utilisé par défaut, par exemple: Port 222. dans tous les cas, pensez à ouvrir ce port dans le parefeu et le rediriger dans le routeur. Ce n'est pas forcément indispensable.
- Très important, retirez à root la possibilité de se connecter en SSH avec cette ligne, ceci afin d'éviter des attaques par bruteforce directement sur l'identifiant "root" :
PermitRootLogin no
Pour vous connecter à la machine, il faudra créer un utilisateur simple avec la commande "adduser".
Une fois les modifications réalisées, relancez le démon SSH :
# rcctl reload sshd
Par la suite, pour vous connecter au serveur, vous utiliserez la commande suivante à partir de votre ordinateur (dans un terminal, ou avec un client comme putty sous windows) :
$ ssh toto@chezmoi.tld
Et si vous avez changé le port par défaut :
$ ssh -p 222 toto@chezmoi.tld
Ça demandera le mot de passe de l'utilisateur toto, puis vous pourrez administrer le serveur à distance.
Connexion par clés (sans mot de passe)
Il est tout à fait possible de se connecter en SSH sans utiliser de mot de passe. À la place, on se sert de paire de clés. C'est une bonne idée au moins pour les raisons suivantes :
- C'est nettement plus sécurisé.
- Ça évite d'écrire un mot de passe à chaque fois 😎.
- C'est pratique car pour lancer des commandes ssh dans des scripts.
Toutefois, cela vous impose d'avoir la clé privée sur la machine servant à se connecter, ce qui n'est pas toujours le cas.
Voici la marche à suivre :
Sur le serveur, modifiez le fichier "/etc/ssh/sshd_config" pour qu'il contienne cette ligne :
PubkeyAuthentication yes
Maintenant, sur l'ordinateur qui veut accéder au serveur, nous allons générer la paire de clés avec la commande suivante :
ssh-keygen -t ed25519 -f ~/.ssh/clessh -a 100
Vous trouverez deux nouveaux fichiers :
- ~/.ssh/clessh : c'est votre clé privée, ne la divulguez JAMAIS à personne.
- ~/.ssh/clessh.pub : la clé publique. Contrairement à son nom, c'est comme une serrure dans laquelle seule la clé privée peut entrer.
L'algorithme ed25519 est utilisé, car très fiable à l'heure actuelle.
Ne mettez pas de mot de passe puis patientez le temps que les clés soient générées.
Sur un système OpenBSD ou Linux, vous prendrez soin d'éditer le fichier "~/.ssh/config" de votre utilisateur pour le remplir ainsi :
Host votreserveur HostName nomtreslong.vraimenttroplong.long User jeanbaptiste.professeurdanseur Port 222 PasswordAuthentication no IdentityFile ~/.ssh/clessh
Bien sûr, vous modifierez le nom de domaine de votre serveur ainsi que le nom de l'utilisateur qui doit se connecter. Ensuite, lancez la commande suivante pour copier la clé publique sur le serveur.
ssh-copy-id -p xxx -i ~/.ssh/clessh.pub "jeanbaptiste.professeurdanseur@nomtreslong.vraimenttroplong.long"
Ici, remplacez "xxx" par le port utilisé par SSH.
Dans le cas où l'outil ssh-copy-id ne serait pas disponible, il faut copier la clé publique manuellement. Pour l'afficher, entrez :
$ cat ~/.ssh/clessh.pub
Connectez-vous sur le serveur en SSH, puis ajoutez dans le fichier "~/.ssh/authorized_keys" le contenu du fichier affiché précédemment.
Une fois ceci fait, vous pouvez vous connecter sans devoir entrer de mot de passe avec simplement la commande :
$ ssh votreserveur
Pratique non?
Si ça fonctionne comme prévu, vous pouvez si vous le souhaitez désactiver l'identification par mot de passe pour de bon afin de ne garder que le jeu de clés comme possibilités. Modifiez le fichier "/etc/ssh/sshd_config" pour qu'il contienne cette ligne :
PasswordAuthentication no
⚠ ATTENTION à ne pas perdre votre jeu de clés !
Transférer un fichier
Vous aurez certainement besoin d'envoyer des fichiers sur votre serveur de temps en temps. Une fois que SSH est configuré, vous pourrez utiliser la commande scp depuis n'importe quel ordinateur afin de copier un fichier vers votre serveur. Par exemple :
$ scp -P <port ssh> utilisateur@chezmoi.tld:/emplacement/de/destination fichier-a-copier
C'est très pratique.
Si vous souhaitez toutefois transférer de nombreux fichiers, sauvegarder ou stocker des documents, tournez-vous plutôt vers le protocole SFTP, disposant de davantage de fonctionnalités comme la reprise d'un transfert partiel.
Si les fichiers sont trop gros, vous pouvez les découper pour réaliser les transferts en plusieurs fois.
Enregistrements DNS SSHFP
Lors de la premières connexion à votre serveur via SSH, un client va récupérer l'empreinte de votre serveur. Cependant, comment être sûr qu'il s'agit bien de la bonne? Au lieu d'accepter la première fois puis vérifier ensuite si l'empreinte a changé (il y a certainement dans ce cas un problème), vous pouvez publier dans votre zone DNS les informations permettant de vérifier que tout va bien.
Pour cela, depuis votre serveur, entrez la commande "ssh-keygen -r chezmoi.tld" puis copiez le résultat dans votre zone (sans oublier d'adapter au besoin en ajoutant un "." final après votre domaine ou en le modifiant pour un "@").
Par exemple :
@ IN SSHFP 1 1 97f5a9479fd16fbee1381c425297f7b2773a67a4 @ IN SSHFP 1 2 bd50a3c271e83dc769ea7c249a5c07aea1a817c62910129de56eba2763f93607 @ IN SSHFP 2 1 05fb8516842fc270ea5abda38d1c32b41e75da8a @ IN SSHFP 2 2 491489437e137d7d27959a4de3ba7660185ef98cbd3abc2287c82f82e8f032ab @ IN SSHFP 3 1 b7305417b0e981c4513642020a1f57ee03915af5 @ IN SSHFP 3 2 f15d33852df5f4043c77b6bf1c6134a5e11de0a513c1ec127fcbb8fae733b178 @ IN SSHFP 4 1 a1120fe90e69c0f534fece3dc837db6a262c3371 @ IN SSHFP 4 2 a36e418b517d95a74f1e0be1228d46e7aeaa8ed310359e91162d8c40b373eb55
Rassurez-vous, on parle des zones DNS un peu plus loin 😉.
Afin que ces enregistrements soient comparés à l'empreinte du serveur, les utilisateurs devront avoir activé l'option "VerifyHostKeyDNS" lorsqu'ils utiliseront ssh. Cela peut s'activer en ajoutant dans leur fichier "~/.ssh/config" :
Host * VerifyHostKeyDNS yes