L'exécution SSH
sur un autre port ne compte plus comme sécurité. Cela ajoute seulement un peu d'obscurité et une étape supplémentaire de complexité pour vos utilisateurs. Il ajoute zéro obstacle pour les personnes qui cherchent à briser votre réseau, qui utilisent des scanners de ports automatisés et ne se soucient pas du port sur lequel il fonctionne.
Si vous souhaitez renforcer la sécurité sur un système qui autorise la SSH entrante basée sur Internet à distance, contrôlez vos utilisateurs dans le sshd_config
@Anthon indiqué, puis implémentez également la sécurité directement dans PAM.
Créez deux groupes lusers
et rusers
. Ajoutez les utilisateurs mobiles distants au rusers
groupe. Utilisez le module PAM pam_succeed_if.so pour autoriser l'accès à ces utilisateurs. Ajoutez des lignes à votre configuration pam pour ssh:
account sufficient pam_succeed_if.so user ingroup lusers
account sufficient pam_succeed_if.so user ingroup rusers
Certains modules pam_succeed_if.so peuvent vous obliger à utiliser une syntaxe légèrement différente, comme group = lusers
.
Ensuite, non seulement sshd
limite les utilisateurs qui peuvent se connecter, mais en cas de bogue sshd
, vous avez toujours la protection offerte par les restrictions basées sur PAM.
Une étape supplémentaire pour les utilisateurs distants consiste à forcer l'utilisation de ssh_keys avec des phrases secrètes. Ainsi, les utilisateurs locaux peuvent se connecter avec des clés ou des mots de passe, mais les utilisateurs distants doivent avoir une clé, et si vous créez les clés pour eux, vous pouvez vous assurer que la clé a une phrase de passe associée. Limitant ainsi l'accès aux emplacements qui possèdent réellement la clé SSH et la phrase secrète. Et limiter les vecteurs d'attaque potentiels si le mot de passe d'un utilisateur est compomisé.
Dans sshd_config
:
changer 2 paramètres:
ChallengeResponseAuthentication yes
et
PasswordAuthentication yes
à:
ChallengeResponseAuthentication no
et
PasswordAuthentication no
Ainsi, la valeur par défaut est de n'autoriser désormais que l'authentification par clé. Ensuite, pour les utilisateurs locaux, vous pouvez utiliser le match
paramètre de configuration pour modifier la valeur par défaut pour les utilisateurs locaux. En supposant que votre réseau privé local est 192.168.1.0/24, ajoutez à sshd_config
:
Match Address 192.168.1.0/24
PasswordAuthentication yes
Désormais, les utilisateurs locaux peuvent se connecter avec des mots de passe ou des clés, et les utilisateurs distants seront obligés d'utiliser des clés. A vous de créer les clés avec des mots de passe.
Comme avantage supplémentaire, vous n'avez qu'à gérer un seul sshd_config
et vous n'avez qu'à exécuter ssh sur un seul port, ce qui facilite votre propre gestion.
modifier 2017-01-21 - Limiter l'utilisation des authorized_keys
fichiers.
Si vous voulez vous assurer que les utilisateurs ne peuvent pas simplement générer eux-mêmes une clé ssh et l'utiliser avec un authorized_keys
fichier pour se connecter, vous pouvez contrôler qu'en définissant un emplacement spécifique pour sshd, il recherchera les clés autorisées.
Dans /etc/ssh/sshd_config
, changez:
AuthorizedKeysFile %h/ssh/authorized_keys
à quelque chose comme:
AuthorizedKeysFile /etc/.ssh/authorized_keys/%u
Le fait de pointer vers un répertoire contrôlé sur lequel les utilisateurs ne sont pas autorisés à écrire signifie qu'ils ne peuvent pas générer leur propre clé et l'utiliser pour contourner les règles que vous avez mises en place.
lusers
groupe, mais pas durusers
groupe, génère une paire de clés et la met à jour~/.ssh/authorized_keys
, elle pourra se connecter à distance.