Discussion :

[Engiwip]

Bonjour à tous

Contexte : Gestion de l'authentification au serveur hote par paire de cle ssh sans fournir de password
attribut AuthenticationMethods publickey dans sshd_config en autre...

pas de reseau local d'entreprise et un serveur sur OVH qui se fait brutaliser toutes les minutes par des vilains scans brutes forces

apres avoir fourni un couple de clé ssh-keygen , et bien renseignés les autorized_keys , know_hosts...
il s'agit maintenqnt de gérer la connexion au serveur par clé ssh uniquement et non login-mot de passe tout en minimisant les saisies de passphrases et la manipulation de clé privée

Question : Comment gérer vous votre magasin de clés privées pour vos sessions ssh ?

Il existe plusieurs moyens de gérer les clés et les sessions ssh au serveur avec les techniques suivantes:

-> ssh-agent
->gpg-agent
-> keychain
-> ssh-ident
->vault
->keybase.io
autre?

je souhaiterais gérer intelligemment les sessions ssh et pouvoir recuperer mes clés privées dans un endroits unique, sécurisé et portable sans monter une usine à gaz et avec un peu de professionalisme

En ce moment j'utilise keychain pour gérer les sessions du ssh-agent , mais ça ne me satisfait que moyennement car la solution n'est pas tres portable d'une machine à l'autre ou peut y a il un moyen d'utiliser keychain de maniere futée je suis preneur.

bref
Quelles sont vos habitudes ou suggestions ?

[Flodelarab]

Bonjour

La valeur d'un billet de banque est disponible pour le porteur dudit billet de banque.
Il en est de même pour ton trousseau.

sécurisé et portable

Donc il suffit de voler la partie portable pour te dépouiller.
Tout système de sécurité a la résistance du maillon le plus faible.
Donc, en l'espèce, toute la sécurité tient dans ta passphrase protectrice de ton trousseau privé.
Une information que l'on peut récupérer en regardant par dessus ton épaule ou par un keylogger.

recuperer mes clés privées

C'est cette expression qui coince. Car en théorie, les clés privées ne doivent jamais voyager.
Si les systèmes de clés résolvaient tous les problèmes, les banques les auraient déjà adoptés.
Mais il y a toujours une faille quelque part.

sans monter une usine à gaz et avec un peu de professionalisme

Compromis difficile.
Pour le professionnalisme, il faudrait renforcer ton identification pour utiliser le trousseau.
Généralement, on utilise une identification par 2 ou 3 moyens (Téléphone portable, code temporaire, etc... ) pour régler cette question. (Multi Factor Authentication, MFA, 2FA, 3FA)
Car il faudrait que quelqu'un vole, simultanément, ton trousseau, ton portable, ta passphrase, et pirate ta messagerie électronique, pour pouvoir te nuire
Bon ben là, le vilain t'en veut vraiment

La mise en œuvre concrète ?
Je ne sais pas. Il faut chercher qui propose quoi.

[Engiwip]

Salut,

Bonjour

C'est cette expression qui coince. Car en théorie, les clés privées ne doivent jamais voyager.
Si les systèmes de clés résolvaient tous les problèmes, les banques les auraient déjà adoptés.
Mais il y a toujours une faille quelque part.

En theorie on doit surtout ne pas les partager...apres pour ce qui est de les transporter et de les consigner qq part , je ne dois pas etre le seul à poser cette problématique
je voyage bien avec mes clés de maison , je ne les laisse pas sous le paillasson.
il doit y avoir les meme attentes dans le monde numerique.
je ne vais pas creer une paire de clé à chaque fois que je change de poste client pour me connecter au serveur .

Compromis difficile.
Pour le professionnalisme, il faudrait renforcer ton identification pour utiliser le trousseau.
Généralement, on utilise une identification par 2 ou 3 moyens (Téléphone portable, code temporaire, etc... ) pour régler cette question. (Multi Factor Authentication, MFA, 2FA, 3FA)
Car il faudrait que quelqu'un vole, simultanément, ton trousseau, ton portable, ta passphrase, et pirate ta messagerie électronique, pour pouvoir te nuire
Bon ben là, le vilain t'en veut vraiment

Oui le 2FA et la longueur de la passphrase . ces conseils sont remplis de bon sens! merci

La mise en œuvre concrète ?
Je ne sais pas. Il faut chercher qui propose quoi.

c'est dommage car c'est bien le sens de ma question !
et j'ai listé queques pistes , j'esperais que l'un d'entre vous ait exploré plusieures manieres de faire....

[BufferBob]

salut,

gérer la connexion au serveur par clé ssh uniquement (...) tout en minimisant les saisies de passphrases et la manipulation de clé privée
(...)
je souhaiterais gérer intelligemment les sessions ssh et pouvoir recuperer mes clés privées dans un endroits unique, sécurisé et portable sans monter une usine à gaz et avec un peu de professionalisme

OpenSSH c'est bien.

ça permet de générer les clés, les stocker dans ~/.ssh/, c'est très light, y'a ssh-agent livré avec, et pour peu qu'on custom son ~/.ssh/config y'a souvent moyen de trouver son bonheur.
typiquement dans le fichier de config on va pouvoir demander le codage (ou pas) explicite des known-hosts, multiplexer les sessions ssh sur la même connexion et créer des entrées pour chaque machine où on se connecte en renseignant à l'avance quelle clé doit être utilisée, quel user etc.

seul bémol, le stockage n'est pas sécurisé, si un intrus met les pieds sur ton ordi il récupère ton répertoire ~/.ssh/ c'est fini, mais c'est le cas pour tous les softs en réalité, si on veut pallier à ça on doit pouvoir se tourner vers du chiffrement de répertoire par exemple avec eCryptFS

perso j'ai géré des dizaines de serveurs pendant plusieurs années en entreprise rien qu'avec ce package et une config un peu travaillée.

[Engiwip]

salut !

salut,

créer des entrées pour chaque machine où on se connecte en renseignant à l'avance quelle clé doit être utilisée, quel user etc.

et du coup à la fin tu ne te retrouves pas avec un spaghetti de clés publiques à maintenir dans ton fichier ./ssh/autorized_keys ? avec les spécifications de renouvellement de clé que çà implique , des machines obsolétes qui ont été oubliées et qui contiennent toujours une entrée dans le fichier , etc .?

j'ai pas l'impression d'une solution maintenable à la longue .

salut,
seul bémol, le stockage n'est pas sécurisé, si un intrus met les pieds sur ton ordi il récupère ton répertoire ~/.ssh/ c'est fini, mais c'est le cas pour tous les softs en réalité, si on veut pallier à ça on doit pouvoir se tourner vers du chiffrement de répertoire par exemple avec eCryptFS

Ok c'est noté.

[BufferBob]

le authorized_key il est uniquement coté serveur, si il contient pleins de lignes c'est qu'il doit y avoir pleins d'utilisateurs qui se connectent dessus ou que l'admin ne pense pas à effacer l'ancienne clé quand celle-ci est révoquée, dans tous les cas ça n'est pas automatique on est d'accord, y'a des tas d'admins qui le font, à moins d'avoir des besoins spécifiques (un grand nombre d'utilisateurs, une politique de révocation automatisée etc.)

coté client si on se connecte à beaucoup de machines différentes c'est plutôt le fichier known_hosts qui tend à se remplir, mais ça n'a qu'un impact mineur, et comme il est assez cryptique par défaut, on peut éventuellement vouloir le forcer dans la config (HashKnownHosts no) à afficher des noms de machines explicites au sein du fichier, ce qui permet de l'éditer plus facilement.

[Engiwip]

Ok merci bob.

Donc j imagine que tu geres la session cliente ssh avec un appel a ssh-agent que tu auras scripté dans le ~.profile De l utilisiteur c est bien ça ?

Au final l utilisateur a autant de paire cles que de poste client.... je suis triste

[BufferBob]

Donc j imagine que tu geres la session cliente ssh avec un appel a ssh-agent que tu auras scripté dans le ~.profile De l utilisiteur c est bien ça ?

oui voilà

Au final l utilisateur a autant de paire cles que de poste client.... je suis triste

je suis pas certain de comprendre ce que tu veux... si ton ~/.ssh/ fait partie d'un profil itinérant ou est synchronisé dans le cloud etc. ça solutionne ton problème ?

[Engiwip]

je suis pas certain de comprendre ce que tu veux... si ton ~/.ssh/ fait partie d'un profil itinérant ou est synchronisé dans le cloud etc. ça solutionne ton problème ?

Voila donc les cles privees sur le cloud ?
Chiffrées et signees avec pgp ok.

[BufferBob]

Voila donc les cles privees sur le cloud ?
Chiffrées et signees avec pgp ok.

oui, chacun voit midi à sa porte, perso je ne suis pas agent secret donc je ne me tracasse pas outre mesure (tout est relatif) avec ces questions au profit d'un mise en œuvre simplifiée, s'il était question d'une archi pro et/ou critique j'aurais des critères d'exigences adaptés.
backuper dans un cloud (ou sur un NAS local, ou une clé USB chiffrée, ou simplement dans un password manager etc.) les clés d'accès à mon serveur OVH perso, pour moi ça a du sens.

l'idée c'était surtout de dire peut-être qu'une solution toute faite existe mais j'en connais pas là comme ça, sinon au pire ça ne représente pas énormément de boulot non plus de faire un montage raisonnablement propre par soi-même.

[Engiwip]

bon écoute je me sers de keychain en façade du ssh-agent , avec un alias dans le bash profile.
le dossier .ssh est chiffré et signé en pgp stocké dans Keybase.
on va rester ^Kiss.^
https://www.funtoo.org/Keychain

a+ merci.