J'aime la configuration suivante pour gérer l'accès SSH, que j'utilise au travail pour gérer un groupe d'utilisateurs sur une petite flotte de serveurs. La sécurité et la facilité de gestion figurent en tête de liste de mes priorités.
Ses fonctionnalités clés gèrent facilement les droits SSH via l'appartenance à un groupe Unix, disposent d'autorisations étroitement définies et sont sécurisées par défaut.
Mise en place
Installer le logiciel (facultatif mais utile):
yum install members # or apt install members
Ajouter des groupes:
addgroup --system allowssh
addgroup --system sftponly
Dans /etc/ssh/sshd_config, assurez-vous que les paramètres suivants sont No:
PermitRootLogin no
PubkeyAuthentication no
PasswordAuthentication no
Et à la fin de /etc/ssh/sshd_config, ajoutez ces deux strophes:
Match Group allowssh
PubkeyAuthentication yes
Match Group sftponly
ChrootDirectory %h
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
(n'oubliez pas de redémarrer SSH après avoir édité le fichier)
Explication
Alors, qu'est-ce que tout cela fait?
- Il désactive toujours les connexions root, comme mesure de sécurité supplémentaire.
- Il désactive toujours les connexions par mot de passe (les mots de passe faibles sont un gros risque pour les serveurs exécutant sshd).
- Il autorise uniquement la connexion (pubkey) pour les utilisateurs du
allowsshgroupe.
- Les utilisateurs du
sftponlygroupe ne peuvent pas obtenir un shell via SSH, uniquement SFTP.
La gestion des personnes autorisées se fait ensuite simplement en gérant l'appartenance au groupe (ces modifications prennent effet immédiatement, aucun redémarrage SSH requis):
# adduser marcelm allowssh
# members allowssh
marcelm
# deluser marcelm allowssh
# members allowssh
#
Notez que vos utilisateurs sftp doivent être membres à la fois sftponly(pour s'assurer qu'ils n'obtiendront pas de shell) et de allowssh(pour permettre la connexion en premier lieu).
Plus d'informations
Veuillez noter que cette configuration n'autorise pas les connexions par mot de passe ; tous les comptes doivent utiliser l'authentification par clé publique. C'est probablement la plus grande victoire en matière de sécurité que vous pouvez obtenir avec SSH, donc je pense que cela en vaut la peine, même si vous devez commencer maintenant.
Si vous ne voulez vraiment pas cela, ajoutez également PasswordAuthentication yesà la Match Group allowsshstrophe. Cela permettra à la fois l'authentification par clé publique et par mot de passe pour les allowsshutilisateurs.
Cette configuration limite tout sftponlyutilisateur à son répertoire personnel. Si vous ne le souhaitez pas, supprimez la ChrootDirectory %hdirective.
Si vous ne voulez le chroot au travail, il est important que le répertoire personnel de l' utilisateur (et un répertoire au- dessus) est la propriété root:rootet non modifiable par groupe / autre. Il est acceptable que les sous-répertoires du répertoire personnel appartiennent à l'utilisateur et / ou soient accessibles en écriture.
Oui, le répertoire personnel de l'utilisateur doit appartenir à root et ne pas être accessible à l'utilisateur. Malheureusement, il existe de bonnes raisons à cette limitation. Selon votre situation, cela ChrootDirectory /homepourrait être une bonne alternative.
La définition du shell des sftponlyutilisateurs sur /sbin/nologinn'est ni nécessaire ni nuisible pour cette solution, car SSH ForceCommand internal-sftpremplace le shell de l'utilisateur.
L'utilisation /sbin/nologinpeut être utile pour les empêcher de se connecter via d'autres moyens (console physique, samba, etc.).
Cette configuration ne permet pas les rootconnexions directes via SSH; cela forme une couche supplémentaire de sécurité. Si vous avez vraiment ne besoin les connexions root directes, changer la PermitRootLogindirective. Pensez à le régler sur forced-commands-only, prohibit-passwordet (en dernier recours) yes.
Pour les points bonus, essayez de restreindre qui peut su rooter; ajouter un groupe système appelé wheelet ajouter / activer auth required pam_wheel.sodans /etc/pam.d/su.