====== SSH ======
La façon la plus pratique de se connecter à un serveur pour l'administrer est de passer par ssh (sous linux ; sous les autres OS je vous laisse chercher). Il est possible de passer par des logiciels tiers (tel qu'[[fr:ansible|Ansible]]) mais la connexion elle-même utilise le protocole SSH.

Cet article a plusieurs objectifs :
  * Configurer SSH sur son ordinateur personnel afin de se connecter à ses serveurs de façon sécurisée et confortable
  * Configurer SSH sur les serveurs administrés afin d'atteindre un niveau de sécurité aussi haut que possible((Du moins pour SSH. La sécurité d'un serveur ne passe pas //que// par ça.)).


===== Configurer SSH sur son ordinateur personnel =====
Pour se connecter à un serveur, on peut s'authentifier avec un mot de passe, ou bien avec une authentificatuon par clé SSH. Le mot de passe **n'est pas** sécurisé : une attaque par dictionnaire permet de le trouver, en particulier sur l'utilisateur "root". C'est pourquoi il est nécessaire de générer une clé SSH.

Générer une clé a un autre avantage : vous n'aurez plus qu'un mot de passe à retenir pour vous connecter  de nombreux serveurs, celui qui déverouille la clé elle-même.

==== Générer une clé ====
Ouvrez une console et générez une paire de clefs :
  ssh-keygen -t ed25519
Ou
  ssh-keygen -o -t rsa -b 4096
Vous devriez avoir le texte suivant qui s'affiche :
<code>Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/user/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/user/.ssh/id_ed25519.
Your public key has been saved in /home/user/.ssh/id_ed25519.pub.
The key fingerprint is:
SHA256:Gm8P/ecLCNXPKPUEMZO7LV8vNjTjTfdZ8K2DPx7NPws user@hostname
The key's randomart image is:
+--[ED25519 256]--+
|            =o   |
|           ..+   |
|          . o..  |
|         . ..*.  |
|      . S . .o+o.|
|       + o oo =oB|
|      . + o .E.BO|
|       . o ...%+=|
|          . .*=B+|
+----[SHA256]-----+</code>

Si vous n'entrez rien pour le fichier où sauver la clef (donc tapez sur "entrée"), cela laissera dans le répertoire par défaut, c'est à dire ''/home/user/.ssh/id_rsa'', ce qui est très bien.

Pour la "passphrase", trouvez [[fr:consignes_securite_people#mots_de_passe|un mot de passe efficace]]. 


Une clef publique/privée est générée, spécifiquement pour les connexions ssh, en utilisant l’algorithme Ed25519 dans la première commande ou RSA dans la seconde.

L'ajout du paramètre ''-b (chiffre)'' permet de fixer la taille de la clé, augmentant sa sécurité. Ed25519 utilisant une taille fixe, le paramètre ''-b'' n'est pas applicable dans ce cas.

L'ajout du paramètre ''-o'' permet d'utiliser le nouveau mode de chiffrement de la clé, contrairement à celui par défaut qui [[https://latacora.singles/2018/08/03/the-default-openssh.html|n'est plus considéré comme sûr]]. Ed25519 utilisant ce nouveau mode par défaut, il est inutile de le préciser. Si vous aviez préalablement généré des clés RSA, DSA ou ECDSA sans préciser le paramètre ''-o'', vous pouvez les convertir en changeant le mot de passe avec la commande suivante :
  ssh-keygen -p -o -f chemin/vers/la/clé/privée
=== RSA, ECDSA ou Ed25519 ? ===
Il existe différents protocoles pour générer une clé, en suivant la syntaxe ''ssh-keygen -t type'', ''type'' étant à remplacer par ''dsa'', ''rsa'', ''ecdsa'' ou ''ed25519''.

  * DSA n'est plus accepté partout car considéré comme insuffisamment sûr.
  * RSA est la référence par défaut, acceptée sur tous les serveurs. Cependant, afin de rester sûr il est nécessaire de générer des clés très grandes et sa conception fait que nous atteignons actuellement une limite de taille, [[https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096|des clés plus grandes n'ajoutant pas significativement plus de sécurité]].
  * ECDSA est une variante de DSA qui, contrairement à ce dernier, repose sur l'utilisation des [[https://fr.wikipedia.org/wiki/Cryptographie_sur_les_courbes_elliptiques|courbes elliptiques]]. À niveau de sécurité égal avec RSA, ECDSA utilise des clés d'une taille bien plus petite et est bien plus rapide.
  * Ed25519, aussi appelé EDDSA, est, tout comme ECDSA, une variante de DSA utilisant les courbes elliptiques. La différence avec ECDSA est l'utilisation de la courbe [[https://fr.wikipedia.org/wiki/Curve25519|Curve25519]] qui offre certains avantages supplémentaires, en particulier une plus grande rapidité. Étant plus récente, elle n'est pas encore supportée partout.

Actuellement (octobre 2018) les seules clés considérées comme fiables sont les clés Ed25519, ECDSA ou RSA d'une taille au moins égale à 2048 bits (4096 ou plus étant mieux mais pas significativement).

Sur les serveurs de Khaganat, nous n'acceptons que les clés Ed25519.
==== Le fichier /home/user/.ssh/config ====
Ce fichier permet de personnaliser ses accès à ssh de façon extrêmement pratique. 

=== Alias ssh ===
Pour se connecter à un serveur, il faut taper une commande de la forme suivante :
  ssh user@ip:port/chemin_des_dossiers

Il en est de même pour les divers logiciels utilisants la connexion SSH. Il est possible de faire un alias, dans la configuration de ssh, qui va associer un nom à l'ensemble des paramètres, ce qui transforme la commande de façon bien plus courte.

Il faut alors créer un fichier ''config'' dans son répertoire ''.ssh'' dans son /home. Il contiendra pour chaque serveur un identifiant, son nom (ou adresse IP directe), le fichier rsa à utiliser et l'identifiant qui y est lié :

Voici ce qu'il faut mettre dans le fichier ''/home/user/.ssh/config''
<code>
host serveur1
	HostName serveur1.fr
	IdentityFile ~/.ssh/cle1
	User totor
	Port 2369
  
host serveur2
	HostName 202.127.12.13
	IdentityFile ~/.ssh/cle1
	User roxxor
</code>

  * ''host'' est suivi du "raccourci" que vous souhaitez associer aux paramètres
  * ''HostName'' indique l'adresse du serveur ; cela peut être une adresse ip, un nom de domaine ou même un des noms renseigné dans votre fichier ''/etc/hosts''.
  * ''IdentityFile'' indique la clé ssh associée à ce serveur (voir le chapitre suivant pour plus de détails).
  * ''User'' indique l'utilisateur avec lequel se connecter au serveur.
  * ''Port'' permet d'indiquer le port sur lequel se connecter si ce n'est pas celui par défaut.

Ici, la commande ''ssh serveur1'' vous connectera à "serveur1.fr" avec l'utilisateur "totor" et la clé "cle1" (celle par défaut), via le port 2369. Les trois commandes ci-dessous sont équivalentes :

  ssh serveur1
  ssh totor@serveur1.fr:2369
  ssh -p 2369 totor@serveur1.fr:2369

=== Et si on veut une clef par site ? ===

Il est possible d'indiquer automatiquement à SSH d'utiliser telle ou telle clef selon le site auquel on se connecte.

<WRAP center round tip 90%>
Cela n'a généralement aucun intérêt : la même clé peut vous permettre de vous connectez sur tous les serveurs que vous souhaitez. Les clés asymétriques ne sont pas comme les mots de passe ; la sécurité n'augmente pas en utilisant une différente à chaque endroit, d'autant que ce qui est envoyé est la clé //publique// qui par définition peut être publique sans rien compromettre.

Cependant, c'est parfois une manipulation nécessaire. Par exemple, il fut un temps où Bitbucket ne supportait pas ECDSA, il fallait donc une clé RSA pour ce service et quelques autres serveurs en retard.
</WRAP>


Imaginons qu'on ait généré deux clefs RSA comme indiqué au-dessus. Il suffit d'indiquer pour cela un autre nom à la question "Enter file in which to save the key (/home/user/.ssh/id_rsa)" : ''/home/user/.ssh/cle1'' et ''/home/user/.ssh/cle2''. On a donc décidé d'utiliser les clefs privées comme suit:

  * clepriv1 pour aller sur le serveur 1
  * clepriv2 pour aller sur le serveur 2

<code txt config>
host serveur1
	HostName serveur1.fr
	IdentityFile ~/.ssh/clepriv1
	User totor
  
host serveur2
	HostName 202.127.12.13
	IdentityFile ~/.ssh/clepriv2
	User roxxor
</code>

Ensuite quand on se connectera avec SSH, le système saura que pour aller sur serveur1.fr, il faut qu'il utilise la clef ~/.ssh/clepriv1 et l'identifiant totor. Il ne restera qu'à entrer la passphrase qui y est liée. Il n'y a plus besoin de donner la clef nécessaire ou l'identifiant.

===== Se connecter à un serveur avec sa clé =====

==== Copier la clef publique sur le compte du serveur distant ====

  ssh-copy-id -i ~/.ssh/id_rsa.pub yyy@xxxxx.org
ou
  ssh-copy-id -i ~/.ssh/id_rsa.pub alias_ssh

Remplacez ''yyy@xxxxx.org'' par le nom de votre serveur et son utilisateur, par exemple ''root@monserveur.org''. Ceci dit, si vous avez paramétré correctement votre fichier ''/home/user/.ssh/config'', la seconde commande fonctionne très bien, en remplaçant "alias_ssh" par l'un des "hosts" renseigné dans ce fichier.

Si vous avez généré une clé avec autre chose que RSA, ou lui avez donné un autre nom, modifiez bien le chemin ''~/.ssh/id_rsa.pub''.

Entrez le mot de passe du serveur lorsqu'il vous est demandé (donc pas votre passphrase de clef, il faut d’abord que le serveur sache que c’est bien vous !).

Et maintenant, c’est bon, vous pouvez vous connecter au serveur en ssh avec votre clef :
  ssh yyy@xxxxx.org
ou
  ssh user@monserveur.org
ou encore
  ssh alias_ssh

Sur le serveur, allez dans le dossier .ssh de /home/user et faites
  more authorized_keys
Une ligne doit se terminer par votre nom d’utilisateur et le nom de votre machine, il s’agit des clefs publiques autorisées à se connecter.


==== Se connecter sans retaper trop souvent son mot de passe (méthode sécurisée) : l'agent ssh ====
Il suffit d'utiliser un "agent ssh" qui va se souvenir de votre clé. En théorie, votre mot de passe ne devrait être demandé qu'une fois par session, la première fois que vous déverrouillez la clé.

  eval "$(ssh-agent -s)"
  ssh-add -t 1h ~/.ssh/id_ed25519

Vous devrez retaper cette commande à chaque redémarrage de votre session, avant de vous connecter en ssh pour la première fois lors de la session.

Pour vous simplifier la vie, vous pouvez créer un petit alias (dans /home/user/.aliases si vous utilisez bashrc et que vous avez bien activé cette option) :

  alias mykey='eval "$(ssh-agent -s)" && ssh-add -t 1h ~/.ssh/id_ed25519'

Il n'y aura plus qu'à taper ''mykey'' dans votre console lors de votre première connexion ssh de la journée et ce sera déverouillé pour la session.

Concernant ssh-agent, quelques infos utiles :
  * ''-t 1h'' déclare que la déclaration est valable 1h. On peut adapter plus long, mais c'est bien de ne pas laisser ouvert sans limite. Accessoirement fermer la session shell suffira à annuler la session lié à ssh-agent. Sans donner d'indication, le temp est en seconde (''-t 3600'' = 1h = 60m). Il y a aussi ''d'' pour //days// (jours) et w pour //weeks// (semaines), mais qui déclarerait si long ? Les unités de temps (s/m/h/d/w) peuvent aussi être en majuscules, ça se vaut (S/M/H/D/W). Par défaut, sans rien préciser, c'est "forever" (enfin jusqu'à ce que la session se termine...). Et on peut très bien écrire ''-t 1h30m40s'' si on aime se complique les choses.
  * ''ssh-add -l'' liste les clés actuellement renseignés, si on a un doute.
  * ''ssh-add -D'' les vide (sans avoir besoin de fermer la session).
  * On peut ajouter plusieurs clés en une fois, avec une commande du type ''ssh-add ~/.ssh/id_ed25519 ~/.ssh/id_ed25519_bis ~/.ssh/id_ed25519_ter''. 

Le [[https://linux.die.net/man/1/ssh-agent|manuel]] liste quelques autres options.
==== Se connecter sans mot de passe (méthode non sécurisée) ====
<WRAP center round important 60%>
Se connecter sans mot de passe ouvre potentiellement une faille de sécurité. À réserver à des cas très particuliers !

**NE SURTOUT PAS LE FAIRE PAR DÉFAUT OU PAR FLEMME !**
</WRAP>
Un de ces cas est la possibilité pour un serveur A de se connecter à un serveur B, pour effectuer une sauvegarde des données par exemple. Le serveur A doit lui-même être bien protégé.

Il suffit de créer une clé sur le serveur A, comme indiqué plus haut (''ssh-keygen -t rsa -b 4096'') mais de ne pas rentrer de mot de passe. Cette clé pourra donc être utilisée pour se connecter sans mot de passe.

Ensuite on ajoute cette clé sur le serveur B (''ssh-copy-id -i ~/.ssh/id_rsa.pub yyy@xxxxx.org''). 

Comme les fichiers id_rsa et id_rsa.pub peuvent facilement être copiés d'un ordinateur à l'autre, on peut sécuriser un peu en faisant en sorte que le serveur B n'accepte la clé du serveur A que si cette clé est utilisé depuis l'adresse IP du serveur A. 

Il faut alors ajouter "from=IP1,IP2" dans le fichier ''~/.ssh/authorized_keys'', au début de la clé en question.

Exemple :
  from="192.02.300.01" ssh-rsa XXXYYYZZZ(clé) user@server


===== Configurer SSH sur ses serveurs =====

La connexion par mot de passe doit être désactivée partout. La seule façon de se connecter est d'utiliser une clé SSH. 

<WRAP center round info 90%>
Il peut arriver que le fichier stockant les clés ssh soit corrompu (c'est rare mais comme c'est déjà arrivé sur Khaganat, autant en parler). Ce n'est pas bloquant :
  * soit il s'agit d'une VM, dans ce cas, il est possible d'accéder à la VM depuis l'hyperviseur, et de réparer le fichier,
  * soit il s'agit de l'hyperviseur, dans ce cas, il suffit de rebooter en mode rescue depuis l'interface de gestion des serveurs et de monter les partitions, puis réparer le fichier. 

Cela demande à chaque fois les privilèges au dessus, mais ce n'est pas bloquant (sauf si la supersyadmin s'est sauvée loin du net). Enfin, au pire... c'est à ça que servent les backup : relancer un serveur, ailleurs. D'autant que si un fichier de ce genre est corrompu, il faut s'inquiéter de ce qui a pu se corrompre par ailleurs.
</WRAP>

Chaque utilisateur doit avoir son propre compte sur les serveurs où il a un accès. Par exemple, un compte "zatalyz" sur jukni, avec les privilèges sudo.

La connexion via root est désactivée.

<WRAP center round info 90%>
Cela permet deux choses :
  * chaque utilisateur peut paramétrer sa session suivant ses préférences : terminal, alias, etc.
  * l'historique de chacun est différencié. En cas de souci, il est possible de retrouver qui a fait quoi et donc de mieux comprendre l'enchainement des opérations.  
</WRAP>

S'il y a plusieurs administratrices sur une même machine, les bonnes pratiques recommandent de les mettre dans un même groupe (historiquement "wheel") et de n'autoriser que ce groupe à utiliser sudo et à se connecter en SSH (voir plus bas dans la configuration de sshd_config). 

<WRAP center round tip 60%>
Astuce : si vous avez plusieurs machines où les mêmes sysadmins ont les mêmes privilèges, vous pouvez utiliser ce [[fr:addsysadmin|petit script bash]] pour créer le groupe wheel, créer vos utilisateurs, copier leurs clés... bref tout faire en un script. 
</WRAP>


==== Paramétrer sshd_config ====

Ssh doit donc être configuré pour être bien sécurisé et ne pas permettre qu'un attaquant se connecte par ce biais.

<WRAP center round important 90%>
Cette partie a été mise à jour le 7 mai 2025. La sécurité étant un domaine en perpétuelle évolution, tenez-vous au courant, n'appliquez pas bêtement et veillez à utiliser des informations récentes.
</WRAP>

<WRAP center round info 90%>
D'autres options peuvent être intéressantes à activer/désactiver suivant votre usage. Ce qui est décrit ici permet une installation de base, couvrant les besoins les plus classiques et apportant un niveau de sécurité acceptable.
</WRAP>

La configuration de base sur Debian est relativement correcte ; il y a quelques options qui gagnent à être expliquées et d'autres qui gagnent à être modifiées. Certaines options sont déjà configurées par défaut sur la bonne valeur, même quand elles sont commentées, mais ça va toujours mieux en le disant explicitement. <wrap info>Certaines informations précisées sont donc déjà les valeurs par défaut ; en les déclarant, on assume qu'on en maitrisera mieux les détails que les mainteneurs du paquet.</wrap>


Le fichier à modifier est dans ''/etc/ssh/sshd_config.d/''. Il est préférable de laisser le ''/etc/ssh/sshd_config'' de base, qui doit inclure tous les fichiers situés dans ''/etc/ssh/sshd_config.d/''. Vérifiez que /etc/ssh/sshd_config inclue bien les fichiers de ''sshd_config.d'', puis créez par exemple ''/etc/ssh/sshd_config.d/myssh''

=== Protocole de base ===
  Protocol 2
SSh a évolué et nous utilisons à présent la seconde version du protocole. Pour des raisons de compatibilité, le protocole 1 n'est pas désactivé (et n'est utile que si vous n'avez pas mis à jour votre installation, hein), sauf si votre version d'OpenSSH est ≥7.6. En renseignant cette option, vous vous assurez d'utiliser uniquement la dernière version.

  Port 22
Cette option peut être modifiée pour qu'un attaquant automatique soit bloqué : par contre il faudra préciser le port ssh pour se connecter. La commande ne sera donc plus ''ssh identifiant@serveur.com'' mais ''ssh identifiant@serveur.com -p monport''. Suivant votre installation((Votre serveur est directement relié à internet ? Changez son port pour la connexion SSH. Il est au sein d'un réseau interne, derrière un pare-feu ? Ce n'est pas forcément utile, de toute façon on ne s'y connectera pas depuis l'extérieur grâce au port 22.)), il peut être intéressant de mettre autre chose que 22 (port par défaut, ciblé par pas mal de bots), tout en sachant que changer de port ne suffit pas à protéger votre serveur. 

  StrictModes yes
Cela garantit que le serveur vérifie les modes et droits des fichiers de l'utilisateur avant de se connecter. 

=== Chiffrement et algorithmes ===
  HostKey /etc/ssh/ssh_host_ed25519_key
  HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com
Cela force à ce que seules les clés ed25519 soient présentées, valides et utilisables. Il s'agit de la clé que le **serveur** présente aux clients (aucun rapport avec le fait que les clients utilisent leur clé ed25519 pour se connecter). 


<WRAP center round info 100%>
> Les protocoles d'échange de clés sont basés sur les travaux post-quantiques, disponibles uniquement à partir d'une certaine version d'OpenSSH.

Si vous avez Openssh avec une version supérieure à 9.9 :
<code>KexAlgorithms mlkem768x25519-sha256
</code>

Pour les versions plus anciennes, comme Bookworm (version openssh 1:9.2p1-2+deb12u5), on peut utiliser d'autres versions.
<code>KexAlgorithms sntrup761x25519-sha512,sntrup761x25519-sha512@openssh.com
</code>

À terme, il faudrait mieux n'avoir que ''mlkem768x25519-sha256''. Cependant, en période de transition, vous pouvez autoriser les trois algorithmes (certain des sysadmins se connectent peut-être depuis une version stable/oldstable de debian !

<code>KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,sntrup761x25519-sha512@openssh.com</code>

Plus d'informations sur [[https://rodolphe.breard.tf/article/ma-config-ssh/]].
</WRAP>

Pour le reste des protocoles d'échanges : 
<code>Ciphers chacha20-poly1305@openssh.com,aes128-gcm@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com
</code>

Ajoutez ces lignes pour préciser les algorithmes acceptés et leur ordre de préférence lors de l'utilisation de SSH. Pour les protocoles, c'est assez compliqué, mais on a la chance d'avoir un mordu de chiffrement dans nos rangs alors : suivez les recommandations de Tycho, sauf si vous êtes en mesure de lui démontrer qu'il y a mieux.



  PubkeyAcceptedAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com
Notez que ''PubkeyAcceptedAlgorithms'' tel que paramétré va forcer les utilisatrices à se connecter avec des clés ed25519 : les RSA et autres, c'est fini !

=== Authentification ===

  PermitRootLogin no
ou 
  PermitRootLogin prohibit-password

La première option interdit de se connecter en root directement via ssh. C'est l'option la plus sécurisée. Il faudra donc se connecter en ssh avec un nom d'utilisateur basique, puis passer en root si nécessaire.

La seconde option permet de se connecter en root **uniquement** si [[fr:ssh#se_connecter_a_un_serveur_avec_sa_cle|la clé ssh a été envoyée au serveur]]. C'est relativement sécurisé, tant que votre propre clé est elle-même en sécurité. Mais préférez l'utilisation d'un compte utilisateur non-root pour vous connecter !


  AllowUsers Pseudo1 Moi Toiaussi
  # OU
  AllowGroups wheel

''AllowUsers'' n'est pas dans le fichier de base de la plupart des fichier de config sous Linux, et ça vaut le coup de l'ajouter. Seuls les utilisateurs listés pourront se connecter en ssh. Cela évite qu'on puisse se connecter avec un des utilisateurs automatiquement créés par le système ou un des paquets. Bien que faire ''ssh www-data@serveur.com'' ne soit pas censé marcher, quoi qu'il arrive ; mais si vous installez des paquets via des dépôts externes à votre distribution, vous n'êtes pas forcément sûr (à moins de bien lire le code) qu'une faille de ce genre n'existe pas. ''AllowUsers'' sécurise de ce point de vue : seuls les utilisateurs listés peuvent se connecter. 

L'alternative ''AllowGroups'' est intéressante pour gérer directement tous les utilisateurs d'un groupe (ici, le groupe "wheel", nom souvent attribué aux sysadmins). 

À noter que vous pouvez aussi spécifier l'accès à une plage d'ip : ''AllowUsers admin@192.168.14/24'' ; se référer à la doc de SSH pour plus d'infos. 

Par contre, n'essayez pas de mixer : c'est soit "AllowGroups" soit "AllowUsers" ; mettre les deux paramètres (même si votre user est dans wheel) est une bonne façon de ne plus pouvoir se connecter du tout. 

  PasswordAuthentication no
Interdit purement et simplement à tous les utilisateurs de se connecter via ssh avec un mot de passe : il faut forcément une clé ssh enregistrée sur le serveur.

  PermitEmptyPasswords no
Cela interdit de se connecter sans mot de passe. C'est sans doute superflu vu que de toute façon on oblige à se connecter avec sa clé SSH, mais dans le doute, on le renseigne. 

  KbdInteractiveAuthentication no
Cela va avec le paramètre précédent et le complète. La meilleure explication (en anglais) est [[https://superuser.com/questions/161609/can-someone-explain-the-passwordauthentication-in-the-etc-ssh-sshd-config-fil/374234#374234|ici]]. Autrefois ''ChallengeResponseAuthentication'', devenu ''KbdInteractiveAuthentication''

  PubkeyAuthentication yes
Autorisé par défaut, comme toujours c'est aussi bien en le déclarant... Permet simplement d'utiliser les clés SSH pour se connecter au serveur !

  UsePAM yes
En complément de ''PasswordAuthentication no'' et ''KbdInteractiveAuthentication no'' ; l'option est nécessaire pour que les utilisateurs UNIX puissent s'identifier.

=== Paramètres de session et de connexion ===
  MaxAuthTries 6
Spécifie le nombre de tentatives d'authentification par connexion. L'ANSSI préconise 2 (6 étant la valeur par défaut) ; personnellement, entre ma capacité à me planter en tapant la passphrase de ma clé SSH et le fait que j'ouvre parfois 3 connexions au même serveur en même temps, j'ai préféré mettre un chiffre un peu plus grand afin de ne pas me faire éjecter de mes propres serveurs, tout en étant assez petit pour limiter une attaque par bruteforce.

  LoginGraceTime 30
Temps en secondes pour saisir son mot de passe. En fait, 30 secondes, c'est plutôt long, même avec une passphrase un peu conséquente. D'autant plus qu'il est possible d'utiliser l'agent ssh si on s'authentifie par clef, donc c'est encore plus rapide, à moins d'avoir d'autres facteurs de ralentissement, comme par exemple un réseau congestionné.

  ClientAliveInterval 3m
Toutes les 3 minutes, la session ssh enverra un "ping" au client pour vérifier s'il est toujours présent.

  ClientAliveCountMax 5
Après 5 "ping" sans réponse, la session sera fermée. Donc potentiellement au bout de 15 minutes. 

Cela évite de laisser ouverte des sessions fantômes. Cela peut être paramétré plus court ou plus long, mais ce genre de délai évite d'éjecter s'il y a juste quelques pertes de paquets dans la connexion, tout en étant plutôt très sécurisé. Par ailleurs, d'autres mécanismes vont déconnecter les sessions ssh inactives (dont les pare-feu). Ces paramètres sont à adapter suivant le type de serveur : 
  * Serveur destiné à recevoir des gros fichiers (rsync, scp), avec des tunnels, ou des scripts : prévoir plus long, par exemple ''ClientAliveInterval 15m'' et ''ClientAliveCountMax 3'' (45 minutes au total).
  * Serveur sensibles, et quand on a tendance à oublier qu'on est co et laisser la session ouverte : ''ClientAliveInterval 3m'' et ''ClientAliveCountMax 5'' est correct.
  * Notez que lors des grosses maj (où il se passe du temps sans que le sysadmin n'agisse), nous conseillons de réaliser les opérations avec tmux/screen, ce qui permet de se reconnecter à la session même si on a été déconnecté de ssh. 

=== Comportement à la connexion, environnement ===
  PrintLastLog yes
Cette option permet surtout de faire un contrôle "humain" des incohérences. Lors de votre connexion ssh, un message vous indiquera les informations de la dernière connexion, ce qui peut permettre de s'inquiéter si ça ne ressemble pas à ce que vous savez des connexions au serveur... 

  PrintMotd no
Précise si sshd affiche le contenu du fichier /etc/motd quand un utilisateur se connecte en mode interactif et par défaut à "yes". Comme c'est généralement le shell qui gère ça, on peut passer à "no", ce qui permet aux utilisateurs que ça gonfle de tout simplement le désactiver, tout en laissant les autres le garder, le tout sur le même serveur. 

  PermitUserEnvironment no
Ce paramètre contrôle si l’utilisatrice a le droit de définir des variables d’environnement personnalisées au moment de la connexion SSH. Permettre cela offre la possibilité d'élevations de privilèges. Cela n'empêche pas, par ailleurs, que l'utilisatrice personnalise son environnement via les ''.bashrc'' et ''.profile'' (par exemple. 

  AcceptEnv LANG LC_*
Cela permet à l'utilisateur de passer avec ses propres variables d'environnement mais uniquement pour la langue. ''AcceptEnv'' est à manier avec précaution, mais appliqué ici uniquement à la question linguistique, cela ne devrait pas être un problème.

=== Redirections et accès à distance ===
  AllowTcpForwarding no
Il est possible, via SSH, de faire des trucs fun avec TCP, mais mal maitrisé, cela peut ouvrir des failles à un attaquant. On ne va pas faire compliqué, sauf besoin spécifique, vous devez désactiver ceci et le mettre à ''no''.

  X11Forwarding no
''X11Forwarding'' sert à afficher graphiquement sur sa machine locale ce qui se passe sur le serveur distant. En dehors de quelques cas particuliers, ça n'a aucun intérêt puisque vous allez agir via la console. De plus, les interfaces graphiques viennent avec leurs propres failles (forcément un logiciel de plus c'est plus de risque de failles, et avec X11 il y a de quoi s'amuser), donc... on désactive. Dans le cas où ce serait nécessaire, il faudra ajouter l'option ''ForwardX11Trusted no'' qui en limitera les privilèges.

  GatewayPorts no
C'est l'option par défaut, mais comme souvent la déclarer explicitement évite de se faire surprendre. Cela évite qu'une machine distante puisse se connecter sur un port redirigé par le client. Vous avez peut-être un service sur le port 8800, mais vous demandez l'accès "public" depuis le port 80 (avec proxy etc) ; mieux vaut éviter que les bots le teste sur son port interne. 

  PermitTunnel no
Là aussi l'option par défaut est en théorie suffisante, mais autant la renforcer. Dans de rares cas, on a besoin de faire des tunnels, mais alors mieux vaut les permettre explicitement avec un ''Match Group''/''Match User''.

=== SFTP ===
SFTP est un cas particulier. Ce protocole est très utile pour transférer des fichiers dans un environnement plus simple à sécuriser. La plupart des serveurs n'en ont cependant pas besoin : on utilise rsync, pas besoin de plus. 

Donc, cette partie est totalement facultative ! 

Dans le cas où vous voulez permettre à des utilisatrices de manipuler des fichiers et dossiers dans leur home, il faudra les déclarer dans le groupe "sftpuser", puis ajouter ceci à ''sshd_config.d/sftp.config'' : 
<code>
Subsystem sftp internal-sftp -l INFO -f AUTH

Match Group wheel
    ChrootDirectory none
    ForceCommand none
    PermitTTY yes
    PermitUserRC yes
    
Match Group sftpusers
    ChrootDirectory /home/%u
    ForceCommand internal-sftp -d /sftp
    PermitTTY no
    PermitUserRC no
    # Autoriser une connexion plus longue pour permettre de transférer des fichiers 
    ClientAliveInterval 15m
    ClientAliveCountMax 3
</code>
  * ''Subsystem sftp internal-sftp'' permet d'utiliser sftp via le module interne (directement fourni par SSH). Il faut cependant explicitement demander les logs lors de son usage (ici ''-l INFO -f AUTH'', comme les logs par défaut de SSH). 
  * L'ordre des "Match Group" est primordial. Ici, on s'assure que les sysadmins (wheel) continueront à avoir accès à un vrai shell en se connectant, même si elles font aussi partie du groupe ''sftpusers''. 
  * ''ChrootDirectory'' indique "où" le sous-sytème sftp est chrooté. Cela permet d'isoler les utilisatrices lors de leur connexion, et de leur éviter de bidouiller chez la voisine.
  * ''ForceCommand internal-sftp'' : lors de la connexion, la seule chose autorisée est l'usage de sftp. Et c'est pourquoi on précise "none" pour les sysadmin !
    * J'ajoute la commande ''-d /sftp'' qui force en plus l'utilisatrice à atterrir dans le sous-dossier ''sftp''. Voir le détail de pourquoi plus bas !
  * ''PermitTTY'' s'assurer explicitement de l'accès (ou non) au shell. Bien qu'il y aie peu de risque de contourner sftp, mais je suis parano. On ne donne pas d'accès au shell complet "comme ça", c'est ce qui permet par mal d'escalade de privilèges, dès qu'il y a une faille dans un logiciel.
  * ''PermitUserRC'' : à ''no'' pour nos sftpusers ; cela permet d'utiliser ''~/.ssh/rc'', lequel permet de lancer des commandes automatiques à la connexion. Une faille évidente si on le laisse libre d'accès.
  * On permet enfin une connexion plus longues avec ''ClientAliveInterval'' et ''ClientAliveCountMax'' sinon les gens se feront déconnecter en essayant d'envoyer leurs photos depuis une vieille connexion 2G pourrie. 

À noter : le dossier paramétré par ChrootDirectory doit être possédé par root pour que tout fonctionne. L'utilisatrice n'auras pas la possibilité d'ajouter des dossiers/fichiers à la racine de son home (pas de ''/home/gudule/modossier'' par exemple) mais le pourra dans les sous-dossiers (''/home/gudule/web/monsite'' et ''/home/gudule/modossier''. Comme cela peut être un peu déstabilisant, on peut aussi directement forcer l'utilisatrice à être dans un sous-dossier (''/home/gudule/sftp/'', dont en théorie elle ne pourra pas sortir. Et elle ne pourra pas non plus bidouiller les fichiers cachés du home que Linux aime lire et interpréter. En soit, c'est donc aussi simple de forcer Gudule à rester dans ce dossier "sftp". 

Un autre point important : ajoutez sftpusers à la directive ''AllowGroups'' sinon... ça ne marchera pas. 
  AllowGroups wheel sftpusers


Voir aussi [[https://man.openbsd.org/sshd_config.5#Subsystem]].

=== Exemple de fichier sshd_config ===


Voici à quoi peut ressembler votre fichier ''/etc/ssh/sshd_config.d/myssh''. Adaptez les quelques points à personnaliser.

<code txt /etc/ssh/sshd_config.d/myssh>
# Protocole et sécurité de base
Protocol 2
StrictModes yes
# Port 22, si besoin de le changer

# Chiffrement et algorithmes
HostKey /etc/ssh/ssh_host_ed25519_key
HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,sntrup761x25519-sha512@openssh.com
Ciphers chacha20-poly1305@openssh.com,aes128-gcm@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com
PubkeyAcceptedAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com

# Authentification
PermitRootLogin no
# AllowUsers zatalyz
# OU
AllowGroups wheel

PasswordAuthentication no
PermitEmptyPasswords no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
UsePAM yes

# Paramètres de session et de connexion
MaxAuthTries 6
LoginGraceTime 30
ClientAliveInterval 3m
ClientAliveCountMax 5

# Comportement à la connexion, environnement
PrintLastLog yes
PrintMotd no
PermitUserEnvironment no
AcceptEnv LANG LC_*

# Redirections et accès à distance
AllowTcpForwarding no
X11Forwarding no
GatewayPorts no
PermitTunnel no

# Uniquement si on permet sftp !
Subsystem sftp internal-sftp -l INFO -f AUTH

Match Group wheel
    ChrootDirectory none
    ForceCommand none
    PermitTTY yes
    PermitUserRC yes
    
Match Group sftpusers
    ChrootDirectory /home/%u
    ForceCommand internal-sftp -d /sftp
    PermitTTY no
    PermitUserRC no
    # Autoriser une connexion plus longue pour permettre de transférer des fichiers 
    ClientAliveInterval 15m
    ClientAliveCountMax 3
</code>

N'oubliez pas de relancer le daemon ssh après avoir modifié ce fichier.

  service ssh restart 

====  Autres bonnes pratiques ====
=== Gérer les droits des dossiers ===

Si vous ouvrez un accès SSH à plusieurs personnes sur un serveur, cela ne veux pas dire qu'elles ont le droit de tout faire forcément. Ni de tout voir.

<WRAP center round info 90%>
Rappel vite fait pour créer une utilisatrice avec son groupe associé, un home et un shell fonctionnel (remplacer ''USER'') :
  sudo useradd USER -m -U -s /bin/bash

Et penser à lui mettre un mot de passe :
  sudo passwd USER
</WRAP>

Debian crée par défaut des répertoires "home" avec droit de lecture pour tout le monde (other). Enlever ces droits permet déjà d'isoler un peu :

  sudo chmod o-rx /home/*

Ça n'empêchera pas quelqu'un qui peut passer en root de tout voir au besoin.

Si l'objectif est d'ouvrir un accès web, il me semble plus facile de gérer en créant un dossier "web" dans le dossier de l'utilisatrice, puis faire un lien symbolique depuis /var/www, et donner les droits à www-data d'agir dessus :

<code>
sudo mkdir /home/USER/web
sudo chmod ln -s /home/USER/web /var/www/SITE_USER/
sudo chown -R USER:www-data  /home/USER/web
</code>

=== Tester un fichier ssh ===
Pour vérifier si votre fichier de configuration va tout faire planter : 
  sudo sshd -t -f /etc/ssh/sshd_config.d/myssh
  
===== Pour aller plus loin =====
  * [[http://doc.fedora-fr.org/wiki/SSH_:_Authentification_par_cl%C3%A9|Une explication plus complète sur les clés ssh, en français.]]
  * [[https://man.openbsd.org/sshd_config.5|Toutes les possibilités de sshd_config]], doc officielle en anglais.

{{tag>Serveur Sysadmin Sécurité}}