Différences

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

--- ssh [2025/01/16 09:14] – [Accès root] 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 <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/.