Différences

Ci-dessous, les différences entre deux révisions de la page.

--- ssh [2025/01/15 10:20] – [Restriction d'accès] serge.guerinet
+++ ssh [2025/01/18 11:49] (Version actuelle) – [Comptes et groupes autorisés] serge.guerinet
@@ Ligne 1: / Ligne 1: @@
 ====== SSH : Administration distante sécurisée ======
-SSH (secured shell) est un protocole et le service permettant une connexion distante vers un équipement en vue de son administration.
+SSH (secured shell) est un protocole et le service permettant une <wrap em>connexion distante</wrap> vers un équipement en vue de son <wrap em>administration système</wrap> (gestion des services, installations, modification du paramétrage matériel, etc).
 **__Caractéristiques__**
@@ Ligne 10: / Ligne 10: @@
     * par clé privée/certificat pour le client
-Pour des raisons de sécurité, l'établissement d'une connexion en SSH avec un **compte super-utilisateur n'est plus autorisée** (il existe des commandes pour lever cette interdiction, au risque d'ouvrir une faille de sécurité dans le système ; voir ci-après).
+Pour des **raisons de sécurité**, l'établissement d'une **connexion** en SSH avec un **compte super-utilisateur n'est plus autorisée** (il existe des commandes pour lever cette interdiction, au risque d'ouvrir une faille de sécurité dans le système ; voir ci-après).
 Il est donc nécessaire de suivre la procédure suivante :
@@ Ligne 38: / Ligne 38: @@
 ===== Sécurisation =====
-==== Restriction d'accès ====
+==== Accès root ====
-=== Accès root ===
+<WRAP right round alert 40%>
-Pour autoriser l'accès distant avec un compte //root// (<wrap em>déconseillé</wrap>, à réserver à des cas précis et obligatoires), on éditera le fichier **// /etc/ssh/sshd_config //**, pour y ajouter ou décommenter la ligne :
+<wrap em>L'accès distant en root est interdit par défaut</wrap>.
-<code apache>PermitRootLogin yes</code>
-=== Limitation de la navigation ===
+ On n'autorisera que pour des raisons très spécifiques en mesurant les risques qu'on encoure.
+</WRAP>
+Pour définir l'accès distant avec un compte //root//, on éditera le fichier **// /etc/ssh/sshd_config //**, pour adapter la ligne :
+<code apache>PermitRootLogin {yes|no}</code>
+Suite au paramétrage, on redémarre le service : <code lscript>systemctl restart ssh</code>
+==== Comptes et groupes autorisés ====
+Le fichier de configuration de SSH est /etc/ssh/sshd_config :
+<code lscript>nano /etc/ssh/sshd_config</code>
+Il est possible de limiter les individus autorisés à se connecter en SSH :
+  * pour des comptes individuels : <code apache2>AllowUsers <nom1> <nom2> <...> </code>
+  * pour des groupes : <code apache2>AllowGroups <groupe1> <groupe2> <...> </code>
+Tous les comptes n'appartenant pas aux éléments listés (utilisateurs ou groupe) seront empêchés de se connecter. On établit ainsi une <wrap em>liste blanche</wrap>.
+On peut aussi choisir de travailler en <wrap em>liste noire</wrap>  en indiquant les comptes interdits (et tous les autres seront autorisés :
+  * pour des comptes individuels : <code apache2>DenyUsers <nom1> <nom2> <...> </code>
+  * pour des groupes : <code apache2>DenyGroups <groupe1> <groupe2> <...> </code>
+après modification, on rechargera le service : <code lscript>systemctl reload ssh</code>
+==== Limitation de la navigation ====
 Par défaut, un utilisateur autorisé à se connecter en SSH est positionné dans son dossier **///home//**, mais il peut** naviguer sur l'intégralité de la machine** distante.
 Cela pose de sérieux<wrap em> problèmes de sécurité</wrap> :
-  * accès illicite à des contenus privés,
+  * **accès illicite** à des contenus privés,
-  * destruction de données,
+  * **destruction de données**,
-  * installation de logiciels malveillants,
+  * installation de **logiciels malveillants**,
-  * modification ou altération de contenus (pages d'un site, paramètres d'un service, mots de passe, données d'une base, etc).
+  * modification ou **altération de contenus** (pages d'un site, paramètres d'un service, mots de passe, données d'une base, etc).
-=== Détection et blocage du brute force ===
+=== Blocage dans un dossier (chroot) ===
+Dans le fichier de configuration de SSH (**/etc/ssh/sshd_config**), on peut ajouter des paramétrages pour un utilisateur (**Match User <nomUser>**) ou pour un groupe (**Match Group <nomgroupe>**).
+Notamment, on **limitera** l'utilisateur :
+  - à l'**accès à un dossier** avec le <wrap em>paramètre ChrootDirectory</wrap>
+  - à une **fonction précise** (échange de données en SFTP ou **scp**) avec le <wrap em>paramètre ForceCommand</wrap>
+Exemple pour un** groupe webDepot** dédié aux développeurs autorisés à **déposer des fichiers** dans le **dossier de Apache** :
+<WRAP right round important 30%>
+__**Remarque**__
+Le dossier attribué à ChrootDirectory doit être en écriture uniquement pour le compte **root**
+</WRAP>
+<code lscript>
+Match Group webDepot
+        ChrootDirectory /var/www/html/
+        ForceCommand internal-sftp
+        AllowTcpForwarding no
+        GatewayPorts no
+        X11Forwarding no
+</code>
+==== Détection et blocage du brute force ====
 SSH est une porte d'entrée très prisée des hackers : une fois entrés sur la machine, il ne leur reste plus qu'à exploiter les failles locales.
@@ Ligne 63: / Ligne 109: @@
   * **ddos** : ajoute la prise en compte des demandes de connexions non abouties (les machines pirates lancent des demandes de connexion puis les interrompent pour saturer le service)
   * **aggressive** : normal + ddos + extra
+==== Connexion par clé privée / certificat ====
+L'**authentification par compte / mot de passe** devient de plus en plus une <wrap em>fragilité des systèmes</wrap>, avec des risques multiples :
+  * mots de passe faibles
+  * phishing
+  * attaques par dictionnaire ou brut force
+  * données volées
+Pour SSH en particulier, le risque est d'autant plus important qu'il s'agit de permettre l'accès à une machine pour y opérer des actions sensibles : alimenter le contenu d'un site, paramétrer l'ordinateur, etc.
+Une solution<wrap em> plus robuste</wrap> consiste à garantir la connexion par un<wrap em> système fort de clé privée/clé publique</wrap>.
+<WRAP center round info 60%>
+  - l'utilisateur génère sa clé privée
+  - on génère ensuite sa clé publique (soit lui-même, soit en passant par une autorité)
+  - on fourni la clé publique de l'utilisateur à la machine à laquelle on accèdera en SSH
+  - on paramètre la connexion (par exemple avec [[putty|Putty]]) pour utiliser la clé privée du client lors de la connextion
+</WRAP>
+Une démarche complète et bien expliquée est présentée ici : https://www.tutos-informatique.com/comment-activer-lauthentification-par-cle-ssh-sur-votre-serveur/.