Différences

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

--- ssh [2025/01/16 09:36] – [Connexion par clé privée / certificat] serge.guerinet
+++ ssh [2025/01/18 11:49] (Version actuelle) – [Comptes et groupes autorisés] serge.guerinet
@@ Ligne 50: / Ligne 50: @@
 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 ====
@@ Ligne 95: / Ligne 111: @@
 ==== Connexion par clé privée / certificat ====
-L'authentification par compte / mot de passe devient de plus en plus une fragilité des systèmes, avec des risques multiples :
+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
@@ Ligne 103: / Ligne 119: @@
 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 plus robuste consiste à garantir la connexion par un système fort de clé privée/clé publique.
+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 box 60%>
+<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) pour utiliser la clé privée du client lors de la connextion
+  - on paramètre la connexion (par exemple avec [[putty|Putty]]) pour utiliser la clé privée du client lors de la connextion
 </WRAP>