Question Meilleures pratiques pour .ssh? Dois-je désactiver tous les identifiants root et les mots de passe utilisateur, période?


Je suis nouveau à ce sujet alors s'il vous plaît baissez un peu pour moi.

J'utilise OSX localement, serveur Ubuntu pour mon hôte distant sur Linode. Et à ma compréhension, je peux utiliser ssh-keygen -b 4096 localement, pour générer deux fichiers:

~/.ssh/id_rsa et ~/.ssh/id_rsa.pub

Et puis sur mon serveur je cours mkdir -p ~/.ssh && sudo chmod -R 700 ~/.ssh/ créer le dossier .ssh et lui donner des privilèges récursifs de lecture / écriture / exécution pour le "propriétaire du fichier" (peu importe ce que c'est, selon le wiki chmod).

Alors j'appelle

scp ~/.ssh/id_rsa.pub example_user@123.4.567.89:~/.ssh/authorized_keys

Ce que je suppose utilise le protocole ssh pour télécharger la clé publique sur le serveur dans un nouveau-créé authorized_key fichier dans le serveur .ssh dossier que je viens de créer.

Je suppose donc que cela signifie que le fichier public va sur le serveur, alors que le fichier public et le fichier privé résident sur mon ordinateur local.

Maintenant, disons que je modifie mon /etc/ssh/sshd_config fichier où je peux gâcher avec PermitRootLogin, PasswordAuthentication, et ChallengeResponseAuthentication.

Mes questions:

  1. Dois-je désactiver la connexion root? Devrais-je régler PermitRootLogin à no ou pour without-password? Dois-je désactiver tous les mots de passe et utiliser uniquement les clés, point? Qu'en est-il de PasswordAuthentication et ChallengeResponseAuthentication?

  2. Est-il sécuritaire d’avoir les fichiers de clé privée et publique sur mon ordinateur local? Dois-je supprimer le public et ne conserver que le privé?

  3. Si je me fie uniquement à la clé, cela ne signifie-t-il pas que je suis maintenant exposé à une nouvelle faiblesse: quelqu'un entre dans ma machine et accède donc à mon fichier de clés?


0
2017-07-14 01:25


origine




Réponses:


La "meilleure pratique" avec ssh, ou n'importe quel serveur d'ailleurs, consiste à:

  1. Évaluez la valeur de votre actif et des données sur votre serveur où vous installez et configurez ssh. Est-ce un ordinateur à la maison derrière un lan? Ou une adresse IP publique sur un serveur avec des données sensibles, des informations privées, des informations financières? etc.

  2. Lisez TOUTES les options de sécurité.

  3. Ensuite, décidez de la manière dont vous souhaitez équilibrer la sécurité avec la facilité d'accès, la facilité de configuration et la valeur de vos actifs.

Pour mes considérations sur ssh voir - http://bodhizazen.com/Tutorials/SSH_security


1
2017-07-14 01:59



Mais j'essaie de comprendre les implications aussi. Par exemple, qu'est-ce qui empêche quelqu'un de créer une nouvelle paire de clés et de le faire? scp ~/.ssh/id_rsa.pub example_user@123.4.567.89:~/.ssh/authorized_keys écraser les clés autorisées? Est-ce que cela ne fonctionne plus si les mots de passe ne sont pas autorisés? - user712268
Y a-t-il d'autres identifiants que je devrais désactiver? - user712268
Un utilisateur ne peut pas copier la clé avec scp ou d'autres méthodes s'il ne peut pas se connecter. - Panther


Est-il sécuritaire d’avoir les fichiers de clé privée et publique sur mon ordinateur local? Dois-je supprimer le public et ne conserver que le privé?

La clé publique peut être dérivée de la clé privée (mais pas l'inverse). Comment puis-je récupérer la clé publique à partir d'une clé privée SSH? La clé publique est fournie uniquement par souci de commodité afin que vous n'ayez pas à la générer chaque fois que vous devez ajouter votre clé à un nouveau serveur.

Si je me fie uniquement à la clé, cela ne signifie-t-il pas que je suis maintenant exposé à une nouvelle faiblesse: quelqu'un entre dans ma machine et accède donc à mon fichier de clés?

C'est pourquoi vous n'appuyez pas aveuglément Entrer en cours d'exécution ssh-keygen utilisez plutôt un mot de passe fort (bien sûr différent du mot de passe de votre utilisateur) pour chiffrer votre clé.

Dois-je désactiver la connexion root?

Il est désactivé par défaut car les paramètres par défaut autorisent uniquement la connexion par clé et la racine n’a pas authorized_keys par défaut.

Devrais-je régler PermitRootLogin à no ou pour without-password?

Il est réglé sur without-password parce que c'est un défaut sûr. Vous pouvez le définir sur no si vous le souhaitez. Cependant, si vous avez besoin de rsync/scp en tant que root, vous rencontrerez des problèmes.

Dois-je désactiver tous les mots de passe et utiliser uniquement les clés, point? Qu'en est-il de PasswordAuthentication et ChallengeResponseAuthentication?

Si vous parvenez à respecter cette politique, utilisez certainement les touches uniquement et désactivez les deux.


0
2017-07-14 01:43



Lorsque vous mentionnez des valeurs par défaut, elles ne sont pas vraies pour moi (du moins lorsque vous utilisez linode). Je ne sais pas comment appliquer uniquement la connexion par clé ou ce que je devrais définir pour ces champs. - user712268
Ensuite, vous devriez vous plaindre à Linode. PermitRooLogin without-password est la valeur par défaut dans Ubuntu (basée sur des clés). Lire aussi man sshd_config. - muru
Si je le définissais sans mot de passe, que définirais-je alors PasswordAuthentication et ChallengeResponseAuthentication à la sécurité? Les deux à no? - user712268