> For the complete documentation index, see [llms.txt](https://docs.devolutions.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.devolutions.net/rdm/fr/knowledge-base/knowledge-base-articles/open-ssh-security-best-practices.md). # Bonnes pratiques de sécurité Open SSH Bien qu'Open SSH soit devenu la norme en matière d'accès à distance, son installation par défaut comporte tout de même quelques risques de sécurité. Ce guide propose des moyens d'augmenter considérablement le niveau de sécurité d'une installation Open SSH. ### Utiliser l'authentification par clés privée/publique L'utilisation de clés chiffrées pour l'authentification est utile, car elle élimine le besoin de saisir des mots de passe. Même les pirates les plus ingénieux ne pourront pas interférer avec une session ou s'y introduire, et les tentatives de forçage de mot de passe seront également éliminées. 1. Générez une paire de clés publique/privée à l'aide de cette commande : `$ ssh-keygen -t rsa`. Cela crée deux fichiers dans le répertoire (caché) `~/.ssh` ; la clé privée s'appelle `id_rsa` et la clé publique `id_rsa.pub`. 2. Choisissez un mot de passe qui sera utilisé pour déverrouiller la clé publique à chaque connexion. Il est également possible d'ajouter un chiffrement protégé par une phrase secrète lors de la création de la clé.

Appuyer sur Enter sans saisir de phrase secrète fonctionne également. Sachez cependant que la création d'une clé sans phrase secrète donne automatiquement un accès SSH au serveur distant à toute personne qui accède à votre machine locale.

3. Copiez la clé publique (`id_rsa.pub`) sur le serveur : ```` Scp –p id_rsa.pub remoteuser@remotehost: ```
Le `remoteuser` ne doit jamais être root. Sélectionnez plutôt l'utilisateur non root par défaut comme `remoteuser`.
```` 4. Connectez-vous avec SSH et copiez la clé publique au bon endroit : ``` ssh remoteuser@remotehost mkdir ~/.ssh chmod 700 ~/.ssh cat id_rsa.pub >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys mv id_rsa.pub ~/.ssh logout ``` 5. Supprimez ensuite la clé publique du serveur, sinon le client SSH n'autorise pas la connexion au serveur : ``` rm id_rsa.pub ``` 6. Définissez les autorisations sur les fichiers du serveur (ces deux éléments sont requis si « StrictModes » est défini sur ***yes***) : ``` $ chmod 700 ~/.ssh $ chmod 600 ~/.ssh/authorized_keys ``` 7. Une fois connecté à l'aide de la phrase secrète de la clé, l'authentification par mot de passe peut être entièrement désactivée. Pour ce faire, ouvrez le fichier `/etc/ssh/sshd_config` et ajoutez-y les lignes suivantes : ``` # Disable password authentication forcing use of keys PasswordAuthentication no ``` ### Désactiver l'authentification par nom d'utilisateur et mot de passe Pour éliminer complètement l'authentification par mot de passe et forcer l'utilisation de clés ou de certificats SSH, mettez à jour la configuration SSH en ajoutant les lignes suivantes dans le fichier `/etc/ssh/sshd_config` : ``` PasswordAuthentication no ChallengeResponseAuthentication no KbdInteractiveAuthentication no UsePAM no ``` Redémarrez ensuite le service SSHD en saisissant `/etc/init.d/sshd restart` ou `service sshd restart`. Une fois cette opération effectuée, le serveur doit rejeter toutes les connexions par nom d'utilisateur/mot de passe et n'accepter que l'authentification par clé ou par certificat. ### Configurer l'intervalle de délai d'inactivité Un intervalle de délai d'inactivité peut être défini pour éviter qu'une session SSH ne reste sans surveillance. Pour ce faire, ouvrez le fichier `/etc/ssh/sshd_config` et ajoutez la ligne suivante : ``` ClientAliveInterval 360 ClientAliveCountMax 0 ``` L'intervalle de délai d'inactivité est exprimé en secondes (360 secondes = 6 minutes). Une fois l'intervalle écoulé, les utilisateurs inactifs sont automatiquement déconnectés. ### Désactiver les mots de passe vides Pour une sécurité accrue, il est recommandé d'empêcher les connexions à distance depuis des comptes avec des mots de passe vides. Ouvrez le fichier `/etc/ssh/sshd_config` et mettez à jour la ligne suivante : ``` PermitEmptyPasswords no ``` ### Limiter l'accès SSH à quelques utilisateurs Dans les cas où l'authentification par nom d'utilisateur/mot de passe ne peut être évitée, il est recommandé de limiter la connexion SSH à certains utilisateurs seulement qui ont besoin d'un accès à distance, réduisant ainsi l'impact des utilisateurs ayant des mots de passe faibles. Pour limiter la connexion SSH, ouvrez le fichier `/etc/ssh/sshd_config` et ajoutez une ligne `AllowUsers`, suivie de la liste des noms d'utilisateurs séparés par des espaces : ``` AllowUsers user1 user2 ``` Redémarrez ensuite le service SSHD en saisissant `/etc/init.d/sshd restart` ou `service sshd restart`. ### Désactiver la connexion root Pour désactiver les connexions root, ouvrez le fichier `/etc/ssh/sshd_config` en étant connecté en tant que root et remplacez la ligne `#PermitRootLogin` par `PermitRootLogin no`. Assurez-vous de supprimer le symbole #, sinon cela ne fonctionnera pas. Redémarrez ensuite le service SSHD en saisissant `/etc/init.d/sshd restart` ou `service sshd restart`. ### Désactiver les chiffrements faibles Ouvrez le fichier `/etc/ssh/sshd_config` et ajoutez-y ces lignes : ``` # Ciphers moderns Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com # KEX robusts KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384 # MAC moderns MACs hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com # Disable weak algorithms PubkeyAcceptedKeyTypes ssh-ed25519,rsa-sha2-256,rsa-sha2-512 HostKeyAlgorithms ssh-ed25519,rsa-sha2-256,rsa-sha2-512 ``` Redémarrez ensuite le service SSHD en saisissant `/etc/init.d/sshd restart` ou `service sshd restart`. ### Utiliser un port non standard La grande majorité des pirates qui recherchent des serveurs SSH ouverts vont chercher le port 22, car par défaut, SSH écoute les connexions entrantes sur ce port. Pour exécuter SSH sur un port différent, ouvrez le fichier `/etc/ssh/sshd_config` et ajoutez les lignes suivantes : ``` #Run SSH on a non standard port Port 2025 #Change me ``` Redémarrez ensuite le service SSHD en saisissant `/etc/init.d/sshd restart` ou `service sshd restart`. Assurez-vous de modifier la redirection de port dans votre routeur et les règles de pare-feu nécessaires. Il est recommandé d'informer les clients de tout changement de port afin qu'ils sachent sur quel port se connecter, car SSH n'écoutera plus les connexions sur le port standard. ### Limiter l'exposition SSH avec des contrôles réseau Si le changement de port SSH n'est pas envisageable, le déploiement d'un serveur de rebond offre un point de contrôle Zero-Trust solide entre les clients et les systèmes internes. Il centralise l'authentification, applique des politiques d'accès uniformes et empêche l'exposition directe des ressources critiques. Consultez [Remote Desktop Manager Jump (feature)](https://docs.devolutions.net/fr/resources/devolutions-agent/jump-host/#configure-a-jump-host) pour les étapes de configuration. ### Activer l'authentification multifacteur L'authentification multifacteur est l'une des principales protections à ajouter aux serveurs SSH pour les protéger contre les accès non autorisés, car chaque connexion d'utilisateur doit être liée à un utilisateur MFA configuré. Même si un pirate parvient à obtenir un mot de passe ou à s'introduire dans le serveur SSH, il sera tout de même bloqué par le MFA. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.devolutions.net/rdm/fr/knowledge-base/knowledge-base-articles/open-ssh-security-best-practices.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.