La plupart des guides de configuration d'OpenSSH conseillent de désactiver l'authentification par mot de passe en faveur de l'authentification par clé. Mais à mon avis, l'authentification par mot de passe a un avantage significatif : la possibilité de se connecter d'absolument n'importe où sans clé. Si elle est toujours utilisée avec un mot de passe fort, cela ne devrait pas être un risque pour la sécurité. Mais n'est-ce pas ?
Réponses
Trop de publicités?L'utilisation des clés ssh présente une caractéristique unique par rapport à la connexion par mot de passe : vous pouvez spécifier les commandes autorisées. Ceci peut être fait en modifiant ~/.ssh/authorized_keys
sur le serveur.
Par exemple,
command="/usr/local/bin/your_backup_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...
n'autoriserait que la commande `/usr/local/bin/your_backup_script.sh' avec cette clé particulière.
Vous pouvez également spécifier les hôtes autorisés pour la clé :
from="yourclient,yourotherclient", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...
Ou combinez les deux :
from="yourbackupserver", command="/usr/local/bin/your_backup_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...
Avec les clés, vous pouvez également accorder un accès temporaire à un utilisateur (par exemple, un consultant) à un serveur sans révéler le mot de passe de ce compte particulier. Une fois que le consultant a terminé son travail, la clé temporaire peut être retirée.
Il y a des avantages et des inconvénients à l'authentification par mot de passe ou par clé.
Dans certains cas, par exemple, l'authentification basée sur une clé est moins plus sûre que l'authentification par mot de passe. Dans d'autres cas, c'est l'authentification par mot de passe qui est moins sûre. Dans certains cas, l'un est plus pratique, dans d'autres, moins.
Tout se résume à ça : Quand vous faites une authentification par clé, vous debe sécuriser votre clé avec une phrase de passe. À moins que vous ne disposiez de ssh-agent (ssh-agent vous évite de saisir votre phrase de passe à chaque fois), vous n'avez rien gagné en termes de commodité. La sécurité est discutable : le vecteur d'attaque s'est déplacé du serveur vers VOUS, ou votre compte, ou votre machine personnelle, (...) - qui peuvent ou non être plus faciles à casser.
Sortez des sentiers battus pour prendre cette décision. Les gains ou les pertes en termes de sécurité dépendent du reste de votre environnement et d'autres mesures.
edit : Oh, je viens de voir que vous parlez d'un serveur domestique. J'étais dans la même situation, "mot de passe" ou "clé USB avec la clé dessus" toujours avec moi ? J'ai opté pour le premier mais changé le port d'écoute SSH en quelque chose de différent de 22. Cela permet d'arrêter tous les script boiteux qui forcent brutalement des plages entières de réseau.
Lorsque vous vous connectez avec un mot de passe, vous transmettez votre mot de passe au serveur. Cela signifie que l'opérateur du serveur peut modifier le SSHD pour avoir accès à votre mot de passe. Avec l'authentification par clé publique, ils ne peuvent pas obtenir votre clé privée car seule votre clé publique est transmise au serveur.
Les clés ssh empêchent les attaques de type "man in the middle" sur votre mot de passe.
lorsque vous tentez de vous connecter avec une clé, le serveur construit un challenge basé sur votre clé publique et l'envoie à votre client. qui le décryptera et construira une réponse appropriée à envoyer.
Votre clé privée n'est jamais envoyée au serveur et toute personne qui vous écoute ne peut rien faire d'autre qu'intercepter cette unique session.
avec un mot de passe, ils auraient vos informations d'identification.
Ma solution est d'avoir une clé ssh portable dans des formats appropriés sur une partition cryptée sur une clé usb. cela me permet de :
de rétracter facilement cette clé en cas de perte.
restreindre les serveurs auxquels il me permet d'accéder
et je l'ai toujours sur moi
bien que l'installation du logiciel de montage soit pénible (truecrypt)
- Réponses précédentes
- Plus de réponses