Pourquoi s'embêter à arrêter 'root' à partir de la connexion SSH?

La meilleure pratique consiste à supprimer la possibilité pour 'root' de se connecter via ssh. Toutefois, je dois exécuter certaines commandes Ansible et je me connecte actuellement via un utilisateur appelé "amdhske", puis je l'ai configuré pour qu'il ne soit pas nécessaire de saisir un mot de passe pour le faire. sudoSinon, Ansible doit conserver le mot de passe de l'utilisateur.

Alors, quel est l'intérêt de désactiver l'accès root dans ce cas? Tout attaquant qui accède au compte utilisateur "amdhske" via ssh peut alors sudole diable sortir du serveur. Je suppose que le seul avantage ici est qu’en choisissant un nom d’utilisateur long et aléatoire, il est très improbable qu’un attaquant le sache, alors que «root» est le nom d’utilisateur par défaut, eh bien, «root». Y a-t-il une autre raison?

linux security sudo

— Zuriar
source

Dans quel but? Vous avez vaincu le problème en ayant un utilisateur pouvant exécuter des commandes avec superuser/ sudosans mot de passe. Cela ne sert à rien pour votre cas d'utilisation si ce n'est de désactiver un autre vecteur d'attaque bien sûr, le vecteur d'attaque qui existe est encore pire alors que la racine est accessible via ssh.

— Ramhound

pourquoi est-ce pire? Si quelque chose, il est légèrement mieux que l'attaquant doit deviner le nom d'utilisateur?

— Zuriar

Si vous êtes au moment où un attaquant tente même d’attaquer votre serveur, il est probable que quelqu'un de l’ingénierie sociale connaisse le nom d’utilisateur.

— Ramhound

Je suis sûr que Sony ne pensait pas qu'ils seraient piratés et que 14 To de leurs données seraient non plus divulguées. Comment vous résolvez votre autre problème, je ne peux pas vous aider, je peux simplement vous dire que c'est quelque chose que vous devriez examiner.

— Ramhound

Quel nom de compte suis-je le plus susceptible de deviner? "root" ou "amdhske"?

— Hymie

Réponses:

Plutôt facile. Deux raisons:

Vous pouvez limiter ce que vous pouvez sudo sans mot de passe avec votre utilisateur. Vous entrez simplement la configuration appropriée dans les fichiers sudoers:
```
amdhske ALL=NOPASSWD: /usr/bin/somecommand
```

Si vous vous connectez avec root, vous disposez de toutes les autorisations nécessaires.

Chaque script sur terre sait que votre nom de compte superutilisateur est root. Alors, quel nom d'utilisateur pensez-vous qu'ils vont essayer d'appliquer de force brute, etc. à votre système? Oui, root.

C’est la raison pour laquelle il est recommandé de désactiver le login root ssh.

— Matías
source

... ajoutons également que certaines distributions Linux désactivent l'utilisateur root par défaut (par exemple Ubuntu ...).

— Hastur

Ces arguments ne sont pas applicables au cas d'utilisation Ansible.

— Alexander Shcheblikin

Afin de résoudre votre problème avec "Ansible" sans désactiver la question de mot de passe pour sudo, vous pouvez utiliser une commande trivial comme sudo ls, puis continuer avec sudo Ansible. Ceci est juste un travail autour et si vous sudoexpirez après un certain temps, cela ne résoudra peut-être pas complètement le problème.

PS Je comprends que cela n’aborde pas la question directe du PO mais j’essaie de régler son problème fondamental (jeu de mots).

— Mahdi
source

Il y a plusieurs choses qui se passent ici, et certaines peuvent me manquer, mais voilà.

Sécurité par obscurité: vérifiez votre journal d'authentification à un moment donné. Il y a probablement des centaines de tentatives de connexion à la racine par des scripts automatisés chaque jour, et le fait de ne pas autoriser la connexion de cet utilisateur bloque certains résultats simples.
Stratégies héritées: l'authentification basée sur une clé n'est pas aussi complexe, mais avec les modèles d'authentification plus anciens, il était extrêmement déconseillé de laisser la connexion root ouverte. Ces meilleures pratiques n'ont pas changé car il n'y a pas d'avantage réel à se connecter en tant qu'utilisateur root.
Journalisation: Si chaque utilisateur a son propre compte, vous pouvez plus facilement dire qui a fait quoi sur votre système.

De plus, sudo sans mot de passe aurait été considéré comme une très mauvaise pratique il n'y a pas si longtemps. Ce n'est qu'à l'ère de l'authentification par clé que cela est devenu utile et sécurisé. Souvent, les utilisateurs ne connaissent même pas leurs mots de passe et ne peuvent donc pas les fournir, même s'ils le demandent.

— MillerGeek
source