# Sécurisation protocole ssh **URL:** \ **Category:** Support Debian\ **Created:** [Septembre 9, 2022, 10:10 UTC](https://www.debian-fr.org/t/securisation-protocole-ssh/87117 "2022-09-09T10:10:46Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![zao](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/z/ce7236/32.png) [@zao](https://www.debian-fr.org/u/zao)\ **Post date:** [Septembre 9, 2022, 10:10 UTC](https://www.debian-fr.org/t/securisation-protocole-ssh/87117/1 "2022-09-09T10:10:46Z")
bonjour , debian11/Xfce avant de me lancer dans une utilisation à distance du protocole _ssh_ je voudrais tenter de sécuriser un peu plus son accès en : 1- listant les utilisateurs , côté serveur , pouvant y accéder 2- bloquant la possibilité d’utiliser _ssh_ , côté client , lorsque je ne l’utilise pas J’ai trouvé 2 solutions que je soumets : 1- pour la liste des utilisateurs demandant une connexion : ajouter dans le fichier /etc/ssh/sshd\_config la ligne **AllowUsers nom\_des\_utilisateurs** 2- pour empêcher une connexion à partir de mon portable du fait d’une prise de contrôle par un quidam éloigné ( je suppose que ça doit être possible) je voudrais arrêter le service _ssh_ immédiatement , or je n’ai trouvé que ceci **systemctl disable ssh --now** qui empêche le départ automatique du service au prochain démarrage mais pas pour la session en cours ( si j’ai bien compris) . ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Septembre 9, 2022, 10:15 UTC](https://www.debian-fr.org/t/securisation-protocole-ssh/87117/2 "2022-09-09T10:15:55Z")
le mieux: [https://workbench.cisecurity.org/benchmarks/10431/sections/1431439](https://workbench.cisecurity.org/benchmarks/10431/sections/1431439) Coté client: utiliser un authentification par clef. si le serveur SSh est sur ton portable il faut le desactiver quand l’utilité ne se fait pas sentir. ---
**Author:** ![zao](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/z/ce7236/32.png) [@zao](https://www.debian-fr.org/u/zao)\ **Post date:** [Septembre 9, 2022, 10:19 UTC](https://www.debian-fr.org/t/securisation-protocole-ssh/87117/3 "2022-09-09T10:19:06Z")
> [@Zargos](#): > > Coté client: utiliser un authentification par clef. c’est déjà le cas > @Zargos si le serveur SSh est sur ton portable il faut le desactiver quand l’utilité ne se fait pas sentir. c’est ce que je voudrais faire mais je n’ai trouvé que la commande citée plus haut qui n’a pas d’effet immédiat ( je l’ai vérifié ) . je vais voir du côté du lien cité . ps : la ligne **Allow etc ..** est-elle une bonne solution sachant que je connais tous les utilisateurs éventuels ? ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Septembre 9, 2022, 10:26 UTC](https://www.debian-fr.org/t/securisation-protocole-ssh/87117/4 "2022-09-09T10:26:38Z")
`systemctl disable sshd` =\> desactive le démarrage automatique au démarrage du système. `systemctl stop sshd` =\< arrête le daemon SSH en cours. Bien que possible, je ne trouve pas pertinent d’utiliser une configuration de ce type par User. Mieux vaut utiliser par groupe. Car cela permet d’ajouter ou retirer un utilisateur sans avoir à redémarrer le service. utilise un groupe: [https://workbench.cisecurity.org/sections/1431439/recommendations/2296983](https://workbench.cisecurity.org/sections/1431439/recommendations/2296983) ---
**Author:** ![zao](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/z/ce7236/32.png) [@zao](https://www.debian-fr.org/u/zao)\ **Post date:** [Septembre 9, 2022, 10:32 UTC](https://www.debian-fr.org/t/securisation-protocole-ssh/87117/5 "2022-09-09T10:32:52Z")
> [@Zargos](#): > > `systemctl stop sshd` =\< arrête le daemon SSH en cours. ok ! voilà ce que je cherchais sans trouver . Je vais modifier l’alias en conséquence . > @Zargos > Car cela permet d’ajouter ou retirer un utilisateur sans avoir à redémarrer le service. n’ayant jamais utilisé cette notion de _groupe_ je n’y pense pas ; à tort . merci pour ces explications . ---
**Author:** ![zao](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/z/ce7236/32.png) [@zao](https://www.debian-fr.org/u/zao)\ **Post date:** [Septembre 9, 2022, 1:32 UTC](https://www.debian-fr.org/t/securisation-protocole-ssh/87117/6 "2022-09-09T13:32:14Z")
je reviens sur le sujet car j’ai toujours un souci . Depuis mon portable P1 , le client donc , qui initie la connexion _ssh_ avec un autre portable P2 je fais : ```auto mm@Xfce:~$ sudo systemctl status sshd Unit sshd.service could not be found. ``` puis ```auto mm@Xfce:~$ sudo systemctl stop ssh mm@Xfce:~$ sudo systemctl status ssh ● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; disabled; vendor preset: enabled) Active: inactive (dead) ........... ``` donc la connexion à P2 ne devrait plus être possible , du moins il me semble , mais je peux toujours accéder à une console opérationnelle de P2 à partir de P1 malgré l’indication **Active:inactive(dead)**. De toute évidence quelque chose m’échappe . ---
**Author:** ![Sputnik93](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/35a633/32.png) [@Sputnik93](https://www.debian-fr.org/u/Sputnik93)\ **Post date:** [Septembre 9, 2022, 1:47 UTC](https://www.debian-fr.org/t/securisation-protocole-ssh/87117/7 "2022-09-09T13:47:52Z")
> [@zao](#): > > De toute évidence quelque chose m’échappe Le service `ssh.service` (ou `sshd.service`, c’est pareil), fourni par le paquet `openssh-server`, est un **service** : c’est un processus qui écoute les demandes de connexion sur un port donné. Tu peux couper/désactiver ce service pour ne plus accepter les demandes de connexion. La **commande** `ssh`, fournie par le paquet `openssh-client`, permet d’initier des demandes de connexion. Il ne s’agit pas d’un service (on dit aussi _daemon_ parfois) qui s’exécute en arrière-plan et que tu peux couper, tu ne peux pas enlever la possibilités aux utilisateurs d’initier des demandes de connexion (enfin, si, on peut, mais pas de cette façon). Si tu veux que personne ne puisse se connecter en SSH à la machine P2, depuis P2 tu peux exécuter `systemctl stop ssh` et le tour est joué. ---
**Author:** ![zao](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/z/ce7236/32.png) [@zao](https://www.debian-fr.org/u/zao)\ **Post date:** [Septembre 9, 2022, 1:51 UTC](https://www.debian-fr.org/t/securisation-protocole-ssh/87117/8 "2022-09-09T13:51:51Z")
> [@Sputnik93](#): > > Si tu veux que personne ne puisse se connecter en SSH à la machine P2, depuis P2 tu peux exécuter `systemctl stop ssh` et le tour est joué. ce que je voudrais c’est couper la possibilité d’initier une connexion à partir de P1 et donc je pensais que la commande **sudo systemctl stop ssh** faite à partir de P1 ferait l’affaire . Mais ça ne marche pas . ---
**Author:** ![Sputnik93](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/35a633/32.png) [@Sputnik93](https://www.debian-fr.org/u/Sputnik93)\ **Post date:** [Septembre 9, 2022, 2:00 UTC](https://www.debian-fr.org/t/securisation-protocole-ssh/87117/9 "2022-09-09T14:00:32Z")
> [@zao](#): > > e pensais que la commande **sudo systemctl stop ssh** faite à partir de P1 ferait l’affaire . Mais ça ne marche pas Ben non puisque, comme je viens d’écrire, `systemctl stop ssh` coupe le service d’ **écoute** de conenxion SSH. Donc tu as coupé le **service** ssh sur P1 =\> plus personne ne peut se connecter en SSH à P1. Mais ça n’empêche absolument pas P1 d’initier des demandes de connexion SSH. Le **client** SSH et le **serveur** SSH sont complètement indépendants. Si tu veux couper la possibilité d’ **initier** une connexion SSH depuis P1, il y a plusieurs possibilités, dont: - désinstaller `openssh-client` de P1, mais c’est un peu extrême - modifier les permissions sur le binaire `/usr/bin/ssh`, mais il faudra le refaire à chaque mise à jour de openssh-client - faire passer le trafic sortant de P1 par un proxy (comme squid) qui bloquerait les connexions sortantes sur le port utilisé par SSH - configurer un parefeu local (iptables, nftables…) pour bloquer les connexions sortantes qui se dirigent vers un port SSH Mais de mon point de vue, ça n’a que très peu d’intérêt, de bloquer les demandes de connexion SSH, c’est pas comme ça qu’on sécurise une infra. C’est le serveur SSH (P2, en l’occurrence) que tu veux sécuriser, pas bidouiller les configs client (sinon, quid des nouveaux appareils, sur lesquels tu n’as pas forcément la main, en plus ?) EDIT: à la limite, si tu veux simplement empêcher que quelqu’un se connecte **sur P2 depuis P1** , c’est plus simple. Tu peux configurer un parefeu sur P2 pour bloquer les connexions SSH émanant de P1. ---
**Author:** ![zao](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/z/ce7236/32.png) [@zao](https://www.debian-fr.org/u/zao)\ **Post date:** [Septembre 9, 2022, 2:06 UTC](https://www.debian-fr.org/t/securisation-protocole-ssh/87117/10 "2022-09-09T14:06:42Z")
> [@Sputnik93](#): > > Ben non puisque, comme je viens d’écrire, `systemctl stop ssh` coupe le service d’ **écoute** de conenxion SSH > … > Si tu veux couper la possibilité d’ **initier** une connexion SSH depuis P1, il y a plusieurs possibilités, dont: > > - désinstaller `openssh-client` de P1, mais c’est un peu extrême > … donc en fait je n’avais pas saisi les bases du fonctionnement de ce système . Je vais revoir tout ça et essayer de digérer le tout . merci pour les explications . > Tu peux configurer un parefeu sur P2 pour bloquer les connexions SSH émanant de P1. les fameux (fameuses?) _iptables_ que je n’ai pas encore abordé(e)s . Chaque chose en son temps . ---
**Author:** ![Sputnik93](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/35a633/32.png) [@Sputnik93](https://www.debian-fr.org/u/Sputnik93)\ **Post date:** [Septembre 9, 2022, 2:12 UTC](https://www.debian-fr.org/t/securisation-protocole-ssh/87117/11 "2022-09-09T14:12:59Z")
> [@zao](#): > > donc en fait je n’avais pas saisi les bases de fonctionnement de ce système . Je vais revoir tout ça et essayer de digérer le tout . C’est un modèle d’architecture appelé « client - serveur », qu’on retrouve un peu partout. Le plus connu est probablement le serveur web, dans sa configuration basique: - tu as un serveur web (apache, nginx ou autre) qui héberge un site web (des fichiers html), et qui écoute les demandes de connexion sur le port 80 - et tu as des clients (les navigateurs web) qui se connectent au port 80 du serveur web pour afficher les pages du site Pour SSH c’est _grosso modo_ la même chose: `openssh-server` (le service ssh, géré par `systemctl blabla ssh`) c’est comme le serveur web, et la commande ssh (du paquet `openssh-client`), c’est comme un navigateur web. ---
**Author:** ![zao](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/z/ce7236/32.png) [@zao](https://www.debian-fr.org/u/zao)\ **Post date:** [Septembre 9, 2022, 2:47 UTC](https://www.debian-fr.org/t/securisation-protocole-ssh/87117/12 "2022-09-09T14:47:30Z")
s’agissant d’internet la notion de client-serveur est intuitive : en tant que demandeur d’une connexion je suis un client , en tant que fournisseur d’informations le site est un serveur , mais pour le protocole _ssh_ c’est une autre affaire . Par exemple dans le protocole _scp_ , qui utilise le protocole _ssh_ , je transfère à partir de P1 un fichier sur P2 et bien que client pour _ssh_ sur P1 je sers le fichier à P2 (serveur pour _ssh_ ) sans être serveur !! Là j’avoue avoir un peu de mal à comprendre . Mais bon je crois avoir compris ce que faisait la commande **sudo systemctl stop ssh** et c’est déjà un bon point . ---
**Author:** ![Sputnik93](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/35a633/32.png) [@Sputnik93](https://www.debian-fr.org/u/Sputnik93)\ **Post date:** [Septembre 9, 2022, 2:51 UTC](https://www.debian-fr.org/t/securisation-protocole-ssh/87117/13 "2022-09-09T14:51:16Z")
> [@zao](#): > > pour le protocole _ssh_ c’est une autre affaire Pas tant que ça: un serveur web sert des pages web, un serveur ssh sert des shells. > [@zao](#): > > je transfère à partir de P1 un fichier sur P2 et bien que client pour _ssh_ sur P1 je sers le fichier à P2 (serveur pour _ssh_ ) sans être serveur P1 se connecte au serveur ssh de P2 pour lui transférer un fichier par scp (ou à l’inverse pour récupérer des fichiers de P2). P1 n’a pas besoin d’être serveur ssh pour ce faire (un serveur SSH ne sert pas des fichiers, il sert des shells. P1 se sert du shell ouvert sur P2 pour lui transférer / récupérer des choses). ---
**Author:** ![zao](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/z/ce7236/32.png) [@zao](https://www.debian-fr.org/u/zao)\ **Post date:** [Septembre 9, 2022, 3:00 UTC](https://www.debian-fr.org/t/securisation-protocole-ssh/87117/14 "2022-09-09T15:00:34Z")
> [@Sputnik93](#): > > Pas tant que ça: un serveur web sert des pages web, un serveur ssh sert des shells. effectivement vu comme ça ça se tient : à partir de P1 je demande une connexion à P2 qui me l’octroie . Quant à _scp_ je pense que je lui colle une étiquette qui n’est pas faite pour lui qui ne fait qu’utiliser le véhicule _ssh_ sans avoir rien d’autre de commun . Bon , on avance . ---
**Author:** ![anon36725218](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/8e8cbc/32.png) [@anon36725218](https://www.debian-fr.org/u/anon36725218)\ **Post date:** [Septembre 9, 2022, 3:21 UTC](https://www.debian-fr.org/t/securisation-protocole-ssh/87117/15 "2022-09-09T15:21:53Z")
Bonjour, Le protocole (façon de communication/de faire quelque chose) SSH et le protocole HTTP - exemple : * * * Pour le protocole de communication HTTP (le web) - port de communication par default 80 : Sur une machine dite « serveur physique » tu as : 1. un serveur logiciel (service) HTTP : un serveur web (Apache, NGIX…) Sur une machine dite « client physique » tu as : 1. un client logiciel HTTP : un navigateur web (Firefox, Opera, links…) * * * C’est pareil pour le protocole de communication SSH - port de communication par default 22 : Sur une machine dite « serveur physique » tu as : 1. un serveur logiciel (service) SSH : un serveur Secure SHell Sur une machine dite « client physique » tu as : 1. un client logiciel SSH : les commandes SSH et SCP 😉 * * * Les linux ont un serveur logiciel SSH (et la commande cliente ssh/scp) « par default » pour que tu puisses accéder et gérer ta/une machine depuis une autre. Sinon pour ne pas autoriser à se connecter à une machine en SSH/SCP - sur la machine physique serveur tu peut configurer comme cela : dans le fichier de configuration du serveur physique (machine) **/etc/hosts.allow** tu ajoutes ton service et tes adresses IP autorisées à se connecter à cette machine. `sshd: 192.168.2.1` `192.168.2.1` est l’IP d’un ordinateur (machine physique) qui peut accéder à ta machine serveur SSH. Et pour tes utilisateurs qui ont le droit de s’y connecter - comme tu l’as dit toi même : dans le fichier de configuration du serveur (service) SSH/SCP **/etc/ssh/sshd\_config** `AllowUsers user1 user2 user3` Ci-dessous un lien qui explique : > **[HOWTO: Restrict ssh access by IP Address and/or username](https://www.recitalsoftware.com/blogs/177-howto-restrict-ssh-access-by-ip-address-and-or-username)** > > Opening SSH to the outside world is a security risk. Here is how to restrict SSH access to certain IP addresses on a machine. Edit the /etc/hosts.allo... Bon courage. * * * > [@zao](#): > > _scp_ ne fait qu’utiliser le véhicule _ssh_ On dit le « protocole de communication/transmission » (c’est mieux que véhicule 😉 ) SSH (Secure SHell) qui est protocole de communication encrypté/sécurisé contrairement à la commande `telnet` (dans windows). SCP (Secure Copy) : c’est comme la commande cp (copier) mais de façon sécurisé entre des machines (entre autre). ex : `cp file.source file.destination` Sinon la commande SCP peut être utiliser - de 2 manières - dans les 2 sens (pour envoyer ou pour récupérer) : Ici j’envoie un fichier (`mon_fichier)` dans la MACHINE\_XX : ``` scp mon_fichier MACHINE_XX:mon_fichier ``` Ici je récupère (je vais chercher) dans la machine MACHINE\_XX un fichier `mon_fichier` que je stocke dans ma machine - celle où j’exécute la commande SCP : ``` scp MACHINE_XX:mon_fichier mon_fichier ``` 😉 * * * PS : Et les commandes `iptables` et `ip6tables` c’est en complément de çà 🙂 Ce sont des commandes pour gérer ton pare-feu / firewall. Salutations, Romain ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Septembre 9, 2022, 3:57 UTC](https://www.debian-fr.org/t/securisation-protocole-ssh/87117/16 "2022-09-09T15:57:25Z")
et cote SSHD on revient sur le lien CIS Workshpop que j’ai posté car il présente la quasi totalité des points sécurisé d’une machine ---
**Author:** ![zao](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/z/ce7236/32.png) [@zao](https://www.debian-fr.org/u/zao)\ **Post date:** [Septembre 9, 2022, 4:15 UTC](https://www.debian-fr.org/t/securisation-protocole-ssh/87117/17 "2022-09-09T16:15:39Z")
> [@anon36725218](#): > > Sinon la commande SCP peut être utiliser - de 2 manière - dans les 2 sens (pour envoyer ou pour récupérer) : bonjour et merci pour tous ces détails , j’ai vu cette possibilité et il m’arrive de l’utiliser . > @Zargos > et cote SSHD on revient sur le lien CIS Workshpop que j’ai posté car il présente la quasi totalité des points sécurisé d’une machine je laisse ça pour ce weekend le temps que cette notion de client-serveur dans l’optique _ssh_ se décante vraiment . ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Septembre 9, 2022, 7:54 UTC](https://www.debian-fr.org/t/securisation-protocole-ssh/87117/18 "2022-09-09T19:54:50Z")
> [@zao](#): > > de client-serveur dans l’optique _ssh_ se cette notion de client serveur est GENERALE, elle n’est pas limité à SSH ou un site web. ---
**Author:** ![zao](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/z/ce7236/32.png) [@zao](https://www.debian-fr.org/u/zao)\ **Post date:** [Septembre 9, 2022, 8:09 UTC](https://www.debian-fr.org/t/securisation-protocole-ssh/87117/19 "2022-09-09T20:09:26Z")
> [@Zargos](#): > > et cote SSHD on revient sur le lien CIS Workshpop que j’ai posté car il présente la quasi totalité des points sécurisé d’une machine en me limitant à /etc/ssh/sshd\_config j’ai dû changer des permissions et des valeurs numériques que j’ai adaptées aux valeurs recommandées dans **CIS\_Distribution\_Independent\_Linux\_Benchmark\_v2.0.0.pdf** : ```auto mm@Xfce:~$ stat /etc/ssh/sshd_config Accès : (0644/-rw-r--r--) UID : ( 0/ root) GID : ( 0/ root) ``` changé en **Accès:(0600/-rw--------** Par contre je pense que la recommendation à propos du chiffrement recommandé doit être obsolète car dans /etc/ssh/sshd\_config aucun chiffrement n’est indiqué et seule la ligne **# Ciphers and keying** existe .Idem pour MAC qui ne figure pas dans le fichier **sshd\_config**. Faut-il créer une ligne spécifique et mettre les chiffrements ou MAC recommandés ? ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Septembre 9, 2022, 8:11 UTC](https://www.debian-fr.org/t/securisation-protocole-ssh/87117/20 "2022-09-09T20:11:08Z")
c’est parce qu’elle est laissé à ton apréciation, je kles ai mise san sprobleme de mon coté [Page suivante](https://www.debian-fr.org/t/securisation-protocole-ssh/87117.md?page=2)