> 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). # Meilleures pratiques de sécurité Open SSH Bien qu'Open SSH soit devenu la norme en matière d'accès à distance, l'utilisation de son installation par défaut présente encore quelques risques de sécurité. Ce guide propose des façons 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 puisqu'elle élimine le besoin de saisir des mots de passe. Même les pirates les plus inventifs ne pourront pas interférer ou s'infiltrer dans une session, et il n'y aura plus de tentatives de perçage de mots de passe. 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 est nommée `id_rsa` et la clé publique `id_rsa.pub`. 2. Choisissez un mot de passe qui servira à déverrouiller la clé publique à chaque connexion. Optionnellement, un chiffrement protégé par une phrase de passe peut être ajouté lors de la création de la clé.

Appuyer sur Enter sans saisir de phrase de passe fonctionne aussi. Sachez toutefois que la création d'une clé sans phrase de passe donne automatiquement un accès SSH au serveur distant à quiconque obtient l'accès à votre machine locale.

3. Copiez la clé publique (`id_rsa.pub`) sur le serveur : ```` Scp –p id_rsa.pub remoteuser@remotehost: ```
The `remoteuser` should never be root. Select the default non-root user as `remoteuser` instead.
```` 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 ne permet pas de se connecter au serveur : ``` rm id_rsa.pub ``` 6. Définissez les permissions de fichier sur le serveur (ces deux permissions sont requises si « StrictModes » est réglé à ***yes***) : ``` $ chmod 700 ~/.ssh $ chmod 600 ~/.ssh/authorized_keys ``` 7. Une fois connecté à l'aide de la phrase de passe 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 ``` Ensuite, redémarrez le service SSHD en saisissant `/etc/init.d/sshd restart` ou `service sshd restart`. Une fois cela fait, le serveur devrait rejeter toutes les connexions par nom d'utilisateur/mot de passe et accepter uniquement 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 d'avoir une session SSH 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 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 plus de sécurité, il est recommandé d'empêcher les connexions à distance à partir de comptes ayant 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 à seulement certains utilisateurs qui ont besoin d'un accès à distance, minimisant 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'utilisateur 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 changez la ligne `#PermitRootLogin` pour `PermitRootLogin no`. Assurez-vous de retirer 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 le chiffrement faible 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 à la recherche de serveurs SSH ouverts chercheront le port 22, puisque 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 ainsi que toutes les règles de pare-feu nécessaires. Il est recommandé d'informer les clients de tout changement de port afin qu'ils sachent à quel port se connecter, puisque SSH n'écoutera plus les connexions sur le port standard. ### Limiter l'exposition de SSH avec des contrôles réseau S'il n'est pas possible de changer le port SSH, le déploiement d'un serveur Jump fournit 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 actifs critiques. Consultez [Remote Desktop Manager Jump (fonctionnalité)](https://docs.devolutions.net/resources/fr/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, puisque chaque connexion d'utilisateur doit être liée à un utilisateur AMF configuré. Même si un pirate réussit à obtenir un mot de passe ou à s'introduire dans le serveur SSH, il sera tout de même bloqué par l'AMF. --- # 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, and the optional `goal` query parameter: ``` GET https://docs.devolutions.net/rdm/fr/knowledge-base/knowledge-base-articles/open-ssh-security-best-practices.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.