Sécurisation protocole ssh

Support Debian
#1

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) .

#2

le mieux:
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.

#3

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 ?

#4

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

#5

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 .

1 J'aime
#6

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 :

mm@Xfce:~$ sudo systemctl status sshd
Unit sshd.service could not be found.

puis

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 .

#7

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é.

#8

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 .

#9

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.

#10

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 .

#11

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.

#12

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 .

#13

Pas tant que ça: un serveur web sert des pages web, un serveur ssh sert des shells.

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).

#14

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 .

#15

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 :wink:

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 :

Bon courage.

On dit le « protocole de communication/transmission » (c’est mieux que véhicule :wink: ) 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

:wink:

PS : Et les commandes iptables et ip6tables c’est en complément de çà :slight_smile: Ce sont des commandes pour gérer ton pare-feu / firewall.

Salutations,
Romain

#16

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

#17

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 .

#18

cette notion de client serveur est GENERALE, elle n’est pas limité à SSH ou un site web.

#19

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 :

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 ?

#20

c’est parce qu’elle est laissé à ton apréciation, je kles ai mise san sprobleme de mon coté