Solution 1 :
J'adore l'idée d'accéder aux serveurs via des clés, de sorte que je n'ai pas à taper mon mot de passe à chaque fois que je ssh dans une boîte, je verrouille même le mot de passe de mon utilisateur (pas root) (passwd -l nom d'utilisateur) donc il est impossible de se connecter sans clé...Recommanderiez-vous/ne recommanderiez-vous pas de faire cela pour un compte utilisateur sur un serveur ?
Vous allez désactiver les connexions basées sur un mot de passe dans le mauvais sens. Au lieu de verrouiller le compte d'un utilisateur, définissez PasswordAuthentication no dans votre /etc/ssh/sshd_config .
Avec cet ensemble, l'authentification par mot de passe est désactivée pour ssh, mais vous pouvez toujours utiliser un mot de passe pour sudo.
Le seul fois, je recommande de définir NOPASSWD in sudo est destiné aux comptes de service, où les processus doivent pouvoir exécuter des commandes via sudo par programmation. Dans ces circonstances, assurez-vous de mettre explicitement en liste blanche uniquement les éléments spécifiques commandes que le compte doit exécuter. Pour les comptes interactifs, vous devez toujours laissez les mots de passe activés.
Réponses à vos questions complémentaires :
Mais je suppose que si je désactive l'authentification par mot de passe dans/etc/ssh/sshd_config pour que vous ayez toujours une clé pour vous connecter, je peux utiliser un mot de passe plus simple juste pour sudo qui est plus facile à saisir ? Est-ce une stratégie valable ?
Oui c'est correct. Je recommande toujours d'utiliser des mots de passe de compte local relativement forts, mais pas ridiculement forts. ~8 caractères, générés aléatoirement suffisent.
Si j'ai également une clé pour me connecter en tant que root via ssh, si quelqu'un accède à mon ordinateur et vole mes clés (elles sont toujours protégées par le mot de passe du trousseau de clés du système d'exploitation !), il pourrait tout aussi bien obtenir un accès direct au compte root, en contournant le chemin sudo.
L'accès root via ssh doit être désactivé. Période. Définir PermitRootLogin no dans votre sshd_config .
Quelle devrait être la politique d'accès au compte root alors ?
Vous devez toujours disposer d'un moyen d'obtenir un accès hors bande à la console de votre serveur. Plusieurs fournisseurs de VPS le proposent, tout comme les fournisseurs de matériel dédié. Si votre fournisseur n'accorde pas d'accès réel à la console (par exemple, EC2 par exemple), vous pouvez généralement toujours restaurer l'accès à l'aide d'un processus comme celui que je décris dans cette réponse.
Solution 2 :
Je limite généralement l'utilisation de NOPASSWORD aux commandes exécutées par un processus automatisé. Il est préférable d'avoir un compte de service pour ces commandes, et de restreindre l'utilisation de sudo aux commandes requises.
Autoriser NOPASSWORD pour les commandes générales, permet à toute personne ayant accès à votre ID utilisateur d'exécuter n'importe quelle commande. Cela pourrait résulter d'une compromission de vos informations d'identification, mais pourrait être aussi simple que quelqu'un assis à votre bureau lorsque vous vous éloignez une seconde.
Je trouve que je n'ai pas besoin d'entrer mon mot de passe souvent. Une fois que vous avez entré votre mot de passe, vous pouvez exécuter plusieurs commandes si vous n'attendez pas trop longtemps entre elles. Le délai d'attente est configurable.
Solution 3 :
Vous pouvez avoir le meilleur des deux mondes :l'authentification SSH pour la connexion et pour sudo. Si vous intégrez le module pam_ssh_agent_auth vous pouvez utiliser des clés SSH pour vous authentifier sans donner de mot de passe lorsque vous sudo.
Je l'utilise en production depuis plus de cinq ans.
Pour le configurer, installez le module PAM, puis ajoutez une ligne à /etc/pam.d/sudo ou l'équivalent de votre système :
auth sufficient pam_ssh_agent_auth.so file=~/.ssh/authorized_keys
Si vous faites cela, assurez-vous de protéger vos clés sur votre ordinateur avec une phrase de passe. De cette façon, quelqu'un devrait s'introduire dans votre ordinateur et voler les clés pour y entrer. Ils pourraient le faire en les extrayant de la mémoire pendant qu'ils étaient déverrouillés s'ils ont accès à votre compte, en déchiffrant votre phrase secrète ou en volant votre phrase secrète via un enregistreur de frappe ou le surfer sur l'épaule pendant que vous le tapez (regardez derrière vous !).
Vous pouvez utiliser la même clé SSH que pour vous connecter, ou vous pouvez configurer une clé distincte que vous n'ajoutez à votre agent que lorsque vous utilisez sudo. Donc, si vous voulez être très prudent, vous pouvez conserver un fichier authorized_keys séparé contenant une clé SSH distincte que vous n'ajoutez à votre agent que lorsque vous avez besoin de sudo :
auth sufficient pam_ssh_agent_auth.so file=~/.ssh/authorized_keys_sudo
Solution 4 :
Je ne l'utiliserais que dans deux circonstances :
- Quand c'est absolument requis pour un script automatisé qui s'exécute en tant qu'utilisateur spécifique
- Pour des tâches d'administration spécifiques (lisez uniquement les tâches d'administration, pas celles qui prennent des mesures pour modifier le système) et uniquement pour des utilisateurs spécifiques bien sûr
Par défaut, la plupart des sudo les configurations ne vous le demanderont plus pendant un certain temps dans la même session (si vous ouvrez un nouveau shell qui n'a aucun effet). Vous pouvez contrôler ce comportement dans une certaine mesure avec le timestamp_timeout réglage.
sudo sans mot de passe n'est pas aussi dangereux que le mot de passe ssh sans mot de passe clés, car un attaquant distant a besoin de vos informations d'identification pour entrer en premier lieu, mais s'ils sont entrés en compromettant d'une manière ou d'une autre votre clé privée (ou s'ils sont physiquement locaux et que vous vous êtes laissé connecté et déverrouillé pendant votre absence de la machine) alors la demande de mot de passe est une défense supplémentaire précieuse entre eux et l'accès privilégié.
Concernant le suivi 2 :
Si j'ai aussi une clé pour me connecter en tant que root via ssh
Il vaut mieux éviter cela aussi, exactement pour la raison que vous décrivez. Si une connexion distante doit avoir un accès privilégié, connectez-vous via un compte de service et donnez-lui juste assez de contrôle pour faire son travail via sudo. C'est plus faf à configurer bien sûr, donc beaucoup ne s'en soucient pas (ce qui joue en votre faveur si vous le faites, car il y a beaucoup de fruits plus bas que vous pour que les attaquants y passent du temps !), donc cela revient au vieux compromis entre sécurité et commodité (conseil de pro :choisissez la sécurité !).
Solution 5 :
Puisque vous avez demandé, voici mon conseil général sur la façon de traiter le sudo problème.
Sudo n'a pas été conçu pour fournir plus de sécurité (bien qu'il le puisse à certains égards)... mais plutôt pour fournir une bonne piste d'audit de qui fait quoi sur votre système avec quels privilèges.
Un Sudo correctement configuré n'utilisera pas le ALL=(ALL) ALL paramètre, mais plutôt quelque chose de plus limité à tout ce dont l'utilisateur a spécifiquement besoin. Par exemple, si vous avez besoin qu'un utilisateur puisse se connecter et redémarrer un service bloqué, il n'a probablement pas besoin de la possibilité d'installer un nouveau logiciel ou d'arrêter votre serveur, de modifier les règles du pare-feu, etc.
Il est parfois courant que les gens utilisent sudo pour s'élever au compte root, c'est-à-dire. sudo su - . Une fois qu'ils ont fait cela, vous ne voyez plus qui fait quoi depuis le compte root (root peut être connecté plusieurs fois simultanément). Donc, parfois, les gens veulent désactiver le sudo su - commande également. Mais, pour des raisons pratiques, si vous avez besoin d'un compte entièrement privilégié pour l'administration, demandez au moins à quelqu'un d'émettre le sudo su - la commande enregistrerait qui a été élevé à la racine et quand.
Comment je sécurise mes boîtes :
Changez le port SSH par autre chose que le port par défaut. C'est pour éviter les robots stupides qui recherchent les numéros de port puis s'éloignent jusqu'à ce qu'ils entrent (ou non).
Interdire la connexion root via SSH en utilisant le AllowRootLogin no paramètre dans votre sshd_config. Cela empêche quelqu'un de forcer brutalement votre compte root. Il est généralement recommandé de ne jamais autoriser quelqu'un à se connecter directement au compte root/administrateur pour des raisons d'audit ainsi que de sécurité. Si vous autorisez la connexion root directement, vous ne savez pas qui s'est connecté, de qui il a obtenu le mot de passe, etc. Mais, si quelqu'un se connecte au compte de Jimmy, puis élève ses autorisations à root, vous avez une meilleure idée par où commencer votre recherche d'audit (et qui est le compte à réinitialiser).
Autoriser uniquement les utilisateurs à se connecter en SSH qui en ont besoin Utilisez le AllowUsers paramètre et spécifiez explicitement quels comptes ont besoin d'un accès SSH. Cela bloquera par défaut tous les autres comptes de SSH.
Modifiez les Sudoers via visudo et n'autorisez que les commandes dont l'utilisateur a besoin. Il existe de nombreux guides détaillés sur la façon de procéder, je ne détaillerai donc pas ici. Voici un début :http://ubuntuforums.org/showthread.php?t=1132821
L'essentiel est d'empêcher un compte compromis de mettre en péril votre machine. c'est à dire. si le compte de Sally est piraté et que Sally ne peut utiliser que sudo pour redémarrer le serveur Web, l'attaquant peut s'amuser à redémarrer votre serveur Web en boucle, mais au moins il ne peut pas rm -rf /your/webserver/directory ou ouvrez tous vos ports de pare-feu, etc.
Configurez de bonnes règles de pare-feu qui n'autorisent que les ports nécessaires au fonctionnement de votre box. Généralement, vous voulez tout supprimer et n'autoriser explicitement que ce dont vous avez besoin. Il y a beaucoup d'iptables décents et d'autres démarrages de pare-feu en ligne, en voici un que j'utilise (c'est un démarreur de base) :
# Generated by iptables-save v1.4.7 on Mon Mar 3 17:55:02 2014
*filter
:INPUT DROP [4528:192078]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [39845:27914520]
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4254 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8080 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8443 -m state --state NEW -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
COMMIT
# Completed on Mon Mar 3 17:55:02 2014
Un mot de passe fort est également essentiel. Même si vous utilisez des clés SSH pour votre accès à distance, vous devez toujours exiger un mot de passe pour l'utilisation de Sudo. C'est un cas où sudo pourrait fournir plus de sécurité. Si quelqu'un devait voler vos clés ssh, il serait toujours empêché de faire quoi que ce soit d'important sur votre boîte s'il devait encore forcer brutalement le mot de passe de votre compte pour utiliser sudo. Les mots de passe ne doivent pas être un mot, mais plutôt une phrase de passe. Pensez à une phrase et utilisez-la. Cela vous donnera généralement quelque chose de plus de 8 caractères, fournissant beaucoup d'entropie, mais est également plus facile à retenir qu'un mot de passe aléatoire. Bien sûr, les bonnes pratiques en matière de mot de passe indiquent d'utiliser un mot de passe aléatoire généré par la machine pour tromper les outils de piratage comme John the Ripper, qui déchireront la plupart des phrases secrètes et des mots de passe. Non, changer E avec 3 ne fonctionne pas, John obtient également ces permutations.