Quelques questions concernant l’accès via SSH à Yunohost
Contexte :
J’ai installé YunoHost sur un VPS il y a quelques semaines et j’en suis très content ! Concernant la sécurité, j’ai suivi en partie les recommandations de cette page de la documentation : https://yunohost.org/#/security_fr :
Activation de l’accès SSH avec la copie d’une clé publique sur le serveur
Changement du port SSH (et désactivation de l’ancien)
Désactivation de l’identification par mot de passe
Tout d’abord, une question de “vérification” :
Je suis allé jeter un coup d’oeil dans etc/ssh et mon côté parano s’inquiète d’y voir apparemment plusieurs clés publiques (si je comprends bien l’affichage…) alors que je n’utilise qu’une seule clé. Est-ce qu’une personne pourrait me détailler un peu plus le contenu de ce dossier (et s’il semble ok) ?
Ensuite, concernant les bonnes pratiques à avoir concernant SSH et la gestion des clés :
J’ai donc créé une clé ssh, dont j’ai copié la partie publique sur mon serveur YunHost. Au cas où j’aurais un problème avec mon PC, je l’ai exporté et copié sur une clé USB + importée sur mon Android (j’utilise ConnectBot).
Est-ce que je devrais plutôt avoir une clé par appareil ?
Merci d’avance aux personnes qui prendront le temps de me répondre
Oui, ça a l’air ok. Ce que tu vois listé ici corresponds :
au fichier de config (ssh_config et sshd_config) du client et serveur ssh de la machine. (Le moduli, je ne sais pas trop ce que c’est, mais peu importe)
Les fichier ssh_host_*_key sont les clefs privées/publiques que le serveur utilise comme identité. La première fois que tu te connectes à une machine en SSH, ton client te demande d’ailleurs de vérifier l’identité de la machine à laquelle tu te connectes. Par contre tu as raison : il y en a plusieurs type, et seulement un seul est utilisé typiquement. Mais c’est plutot standard. Si je ne me trompe pas, la raison c’est que des vieux clients supportent seulement DSA (une technique de chiffrement) mais la recommendation est d’utilisé ECDSA ou ED25519 (apres je ne suis pas expert en chiffrement )
Par contre il ne faut pas confontre “les identités du serveur” avec “les identités autorisées à se connecter au serveur”. (C’est un peu comme confondre la carte d’identité du proprio du bar vs. les noms des gens qui y travaille !). Ces identités sont listées dans /root/.ssh/authorized_keys (pour les gens autorisés à se connecter en root).
Hmben je ne sais pas si il y a une recommendation spécifique par rapport à ca. J’ai l’impression que c’est une question de religion. Tout dépends du contexte, de la menace et du confort que tu cherches à avoir (et de la confiance que tu accordes à chacun de tes dispositifs)… Tu peux choisir de garder les clefs sur chaque machine sur laquelle elles ont été générées, ou bien d’avoir une clef par “activité” (perso, asso n.1, asso n.2, activité pro, …) que tu partage entre tes machines.
Mais l’idée c’est que si une machine est compromise (par les temps qui courent, on va dire, par des CRS qui perquisitionnent ton siège social ) alors il faut considérer que toutes les clefs sur les dispositifs sont compromisent et qu’il faudrait les désactiver pour les changer. Dans ton cas avec ton Android, sachant que Google a potentiellement la main sur ton OS, et suivant ton niveau de chapeau-en-papier-dallu, il faut adapter (ou pas) tes pratiques en conséquence Mais on va dire que tant que tu n’as pas de données critiques, c’est pas très grave…
Ah ! C’était en fait ça que je cherchais !
Du coup je suis allé jeté un coup d’oeil dans le fichier et il n’y a bien qu’une seule clé (avec le nom que je lui avais donné) donc parfait !
Concernant la question sur le choix d’une clé ou plusieurs, c’était davantage pour des raisons techniques : est-ce qu’il peut arriver qu’une clé stockée sur le serveur puisse être corrompue (et du coup, s’il n’y en a qu’une renseignée, m’enfermer hors du VPS) ?
Mouarf, en théorie oui, n’importe quelle donnée peut être corrompue si, mettons, un rayon cosmique pas cool traverse ton disque un jour et corrompt cette donnée … En pratique, ça n’arrive pas trop (ou alors il y a des mécanismes automatiques pour s’en protéger)
Par contre, il se peut que pour une raison X ou Y, ton serveur SSH tombe (même si c’est encore un fois peu probable).
Dans tout les cas, si tu veux vraiment être safe, il te faut un moyen d’accès secondaire à ton serveur. Par exemple, les gros fournisseurs de VPS fournissent généralement des consoles serveur dans l’interface web de gestion de ton VPS.
Effectivement, je suis chez Hetzner, qui propose cela… sauf que par défaut le clavier est en allemand (pratique pour ne serait-ce que taper son mot de passe !)
)
) alors il faut considérer que toutes les clefs sur les dispositifs sont compromisent et qu’il faudrait les désactiver pour les changer. Dans ton cas avec ton Android, sachant que Google a potentiellement la main sur ton OS, et suivant ton niveau de chapeau-en-papier-dallu, il faut adapter (ou pas) tes pratiques en conséquence 
Mais on va dire que tant que tu n’as pas de données critiques, c’est pas très grave…