Discussion :

[Cedric Chevalier]

« SSH un désordre mal géré »
pour le père du protocole de communication sécurisé qui propose une nouvelle version

Dans une RFC présentant les risques potentiels liés à la mauvaise gestion des clés utilisateurs ayant accès aux systèmes d’information par le protocole SSH (Secure Shell), Tatu Ylonen et ses collaborateurs proposent une série de recommandations pour minimiser l’impact de ces risques potentiels pour la sécurité des organismes et entreprises.

Le créateur du protocole SSH (Tatu Ylonen) part d’un constat simple : les organismes fournissent nettement plus de clés SSH que nécessaire. En effet, leur nombre est largement supérieur à celui des utilisateurs du réseau. Le surplus des clés généré pour l’accès automatisé n’attire généralement pas l’attention des administrateurs, alors que celui-ci est un réel problème de sécurité. Les clés inutilisées peuvent accorder aux utilisateurs des privilèges insoupçonnés. C’est ainsi que certaines de ces clés donnent un accès administrateur pour des serveurs d’une entreprise.

Ces clés SSH inutilisées sont davantage exploitées par les malwares modernes comme vecteur d’attaque pour les serveurs d’entreprises.

Par ailleurs, les politiques de sécurité courante mentionnent que les mots de passe utilisateurs et les clés de chiffrement doivent être régulièrement changés. Cependant, ces politiques ne mentionnent pas de façon explicite que doivent aussi être changées fréquemment les clés utilisées pour l’authentification et l’autorisation des utilisateurs.

M. Ylonen attire vivement l’attention de son lectorat sur un fait : les clés privées ne doivent pas être uploadées sur des serveurs distants. En effet, en janvier, une centaine de clés privées et mots de passe furent trouvés dans les répertoires de GitHub. Et certaines d’entre elles utilisées pour réaliser des attaques.

Le créateur recommande donc d’éliminer toutes les clés SSH superflues, de déplacer les clés SSH valides pour l'authentification des utilisateurs dans un emplacement sécurisé, définir correctement les rôles à attribuer aux clés valides et changer constamment de clés.


Source : IETF


Et vous ?

Qu'en pensez-vous ? Trouvez-vous que SSH est actuellement mal géré ?

[gangsoleil]

Qu'en pensez-vous ? Trouvez-vous que SSH est actuellement mal géré ?

Bien sur !

Les clefs circulent a tort et a travers, et il n'est pas rare (mais pas frequent non plus) de se retrouver avec des clefs alors qu'il n'y a aucune raison. Mais comme la plupart des gens ne savent pas s'en servir, heureusement, c'est moins grave qu'il n'y parait.

J'ai bien vu des gens echanger des clefs privees par mail, sans les crypter... Avec bien sur les adresses IP des machines cibles...

[dahtah]

C'est un enorme probleme en entreprise, qui me vaut un gros casse tete. Je comprends vraiment pas que openSSH (par exemple) ne permette pas d'utiliser une infrastructure PKI de base.
Avoir une structure de PKI resoud tout le probleme de la gestion des cles, et ce de maniere externe a SSH. Ca adresse egalement la question de duree des cles, la revocation... A ma connaissance, on est oblige de patcher OpenSSH avec le patch de Rouman Petrov pour qu'OpenSSH soit capable de gerer x509. Et qui compile openSSH en entreprise...?

[Elepole]

*Disclaimer: Noob en SSH here*

Quoi ? la gestion des clés est laisse au utilisateur ? C'est suicidaire ça !

[_skip]

Ben le moyen de communication actuel entre collaborateur souvent c'est le mail.

Donc un tiers me demande de fournir une clé publique pour accéder à son serveur. Moi je la génère, je garde la clé privée privée pour moi ok niquel. Mais si tout à coup mon collègue réclame dans l'urgence une connexion au serveur, je vais sûrement lui écrire un mail avec la clé privée dedans.
En ce sens c'est pas beaucoup mieux qu'un password, si on commence à le balader ou à l'écrire par mail, c'est mort.

Faudrait effectivement les renouveler, mais souvent c'est un peu ennuyant parce qu'on aime pas trop changer et retester des choses qui marchent. Surtout que souvent on utilise ces clés pour automatiser.

[jdevbe]

Le problème n'est pas spécifique à ssh.
Pour beaucoup le simple fait qu'il y a un 's' dans le protocole comme pour sftp/https/smime/... , c'est automatiquement sécurisé sans effort !
Il plus facile de comprendre qu'un mot de passe est personnel. Une clef privée c'est considéré comme un élément technique qu'il faut pour que 'cela marche' !
Par exemple pour éviter d'utiliser les rtools dans les scripts, des sysadmin, pourtant expérimentés, copient la clef privée attribuée à root sur un ensemble de machines y compris sur des machines non sûr 'pour que celà marche'. Une fois en possession de la clef, l'accès depuis un sous-réseau exclu de la config des rtools devient possible ! Càd que ssh peut être moins sûr sur que les rtools ! Un comble !

[dahtah]

Le problème n'est pas spécifique à ssh.

Si, le probleme est bien specifique a SSH, car il n'utilise pas x509/PKI.

Pour beaucoup le simple fait qu'il y a un 's' dans le protocole comme pour sftp/https/smime/... , c'est automatiquement sécurisé sans effort !

Dans https/smime et tout le reste, le certificats clients sont issus par une PKI. C'est a dire que le serveur fait confiance a cette PKI et n'a pas besoin d'avoir une copie de la cle publique de l'utilisateur. De plus, ces services utilisent CRL/OCSP pour maintenir a jour les listes de revocation. Tu revoques la cle sur un serveur, et le login est refuse partout. C'est le comportement classique.
SSH ne permet pas cela (sans patch). Toute cle publique doit etre copiee sur le serveur en question. La maitenance des cles est manuelle (ou via puppet/cobbler) et ne parlons pas de la revocation. Si une cle est compromise, il faut la supprimer sur le x nombre de serveur ou la partie publique a ete copiee.

Il plus facile de comprendre qu'un mot de passe est personnel. Une clef privée c'est considéré comme un élément technique qu'il faut pour que 'cela marche' !
Par exemple pour éviter d'utiliser les rtools dans les scripts, des sysadmin, pourtant expérimentés, copient la clef privée attribuée à root sur un ensemble de machines y compris sur des machines non sûr 'pour que celà marche'. Une fois en possession de la clef, l'accès depuis un sous-réseau exclu de la config des rtools devient possible ! Càd que ssh peut être moins sûr sur que les rtools ! Un comble !

Oui, je suis d'accord que les gens ne comprennent pas forcement l'importance d'une cle privee. Et eduquer les gens a l'utilisation des cles est complique (mais n'excuse pas le login root via SSH ou sudo sans password). Mais la PKI permet de reduire un peu ce risque (attribuer des cles avec des EKU restreignant l'usage, periode de validite des cles...).

[Pelote2012]

C'est comme d'habitude toujours la même situation qui revient.

On sort un truc bien, avec des règles de bases à respecter.
Mais l'utilisateur lambda veut pas se casser la tête, les admin sont obligé de faire des véroles de sécurité pour que X n'ai pas à trop réfléchir (Pire parfois c'est l'admin qui le fait pour ne pas se casser la tête) ...

Règle N°1 : la sécurité absolue n'existe pas
Règle N°2 : Plus de 50% des problème de sécu sont lié au personnel de l'entreprise ...

quand est-ce qu'on va apprendre à se servir correctement de l'informatique.
Pour une voiture, on passe bien un permis ... Ah oui ,'ai oublié les voiture sans permis ... toujours le même problème

bon restons philosophe, ça me fera toujours du travail

[ITCsoft54]

+1 Browny
+1 jdevbe

Les clef privées doivent restés privées.

La plupart du temps les serveurs (même directement exposé sur le net) autorisent le login en root avec ssh, et n'ont pas de mécanisme de Fail2ban.

Une clef ne doit pas servir pour plusieurs utilisateurs. Pour un suivi de la sécurités, 1 login administrateur par administrateur. Ce qui permet de contrôler l'accès lorsqu'un utilisateur n'a plus a être "administrateur" de la machine (compte conpromis, a quitté l'organisation). Si on est dans une grande infrastructure : un annuaire (openLdap par exemple) permet de centraliser ses informations l'administration...

De plus les clefs, c'est comme les mots de passes, il faudrait les changés souvent, et pas utiliser les mêmes partout.

En général, pour se simplifier la vie on ne change pas les mots de passe, comme on ne change jamais les clefs en préventif, mais plutôt en curatif quand c'est déjà trop tard.

Quand à utiliser une autorité pour validé les clef, c'est une piste, mais je pense qu'on peut s'en passé dans la plupart des cas par des moyens tous aussi sécurisé.

On trouve beaucoup de site qui font des tutoriels pour "s'authentifier avec une clef ssh", avec souvent peu de considération en manière de sécurité.

Pour illustrer mes propos : https://www.google.fr/search?q=Conne...s+mot+de+passe