SSHproxy, c'est une passerelle pour se connecter simplement à des sites distants sans avoir besoin de connaître le mot de passe ou de jongler avec un millier de clefs.
C'est un proxy, écrit en python et connecté à une base MySQL, dans laquelle seront stockées toutes les informations d'authentification des site distants. La partie serveur du proxy accepte des connexions en ssh et, selon ce que l'utilisateur veut faire, établit des connexions avec les sites distants ou transfère des fichiers vers ceux-ci.
Ce développement a pu être fait grâce à la merveilleuse bibliothèque qu'est paramiko.
Les fonctionnalités principales de SSHproxy :
- multiples connexions simultanées vers différents sites
- trois "modes" ssh supportés : session shell, scp, exécution de commandes à distance
- journalisation des événements par syslog en udp
- cryptage des mots de passe en base de données selon l'algorithme blowfish
- pas de dépendance sur le poste client : un simple client openssh suffit, des wrappers shell sont fournis
- enregistrement des sessions (flicage)
- ebuild gentoo disponible dans le tarball
Les fonctionnalités futures :
- authentification par clé aux sites distants (prévu dès la version 0.5)
- greffon pour exécuter des scripts à distance de façon automatique (à la expect)
- développement d'autres back-ends que mysql
- interface web pour la gestion et le monitorage des sessions
- implémentation des "modes" port-forwarding et sftp
Voir les scénarios et exemples d'utilisation sur http://penguin.fr/sshproxy/ (en anglais uniquement pour le moment).
Changelog depuis la version 0.3.3 :
* clean installation with setup.py
* plugins can be enabled and disabled from the config file.
* the plugin path (defaults to /usr/lib/sshproxy) is configurable in the config file
* backends are now standard plugins, allowing the package splitting for distribution packagers.
* there is now a simple file backend, eliminating the hard requirement of mysql dependency, although this file backend is not secure at all for the moment.
* sshproxy daemon has been renamed sshproxyd, and SSHproxy module has been renamed sshproxy
* sshproxyd accepts three more options: --daemon, --pid and --user for better init.d integration.
* Gentoo package integration has been started with an ebuild containing an init.d script.
* the database is now more coherent (renamed columns and tables).
* installdb has been replaced with an option of sshproxyd (--wizard).
* managedb has been replaced with an option of sshproxyd (--backend).
* cipherdb has been replaced with an option of sshproxyd (change passphrase / cipher type) (--cipher).
Aller plus loin
- La homepage (83 clics)
- sshproxy-0.4.tar.gz (36 clics)
- La documentation (37 clics)
- Le site de paramiko (34 clics)
# faute
Posté par madko (site web personnel) . Évalué à 4.
# Un soft qui manquait
Posté par Romain (site web personnel) . Évalué à 3.
Si tout est centralise, il est possible d'imaginer des modules pour monitorer un peu qui est ou et qui fait quoi ou effectuer des mises a jours sur plusieurs machines en meme temps...
Beau travail !
# Ça ne changera pas grand chose, en fait ;-)
Posté par Raphaël SurcouF (site web personnel) . Évalué à 1.
Donc, quand les premiers "chimpanzés"[1] seront tous partis, les suivants utiliseront SSHProxy sans comprendre pourquoi (ou plutôt parce qu'ils n'auront dès lors plus aucun moyen de retrouver les mots de passe en question). Si l'entreprise en question a une incompatibilité entre le "turn-over" de ses employés et sa politique de sécurité, elle aura toujours un gros problème de gestion de ses ressources humaines à résoudre.
Pour finir, je préfère quand même l'utilisation des clés SSH pour identifier les utiliser voire si possible, de certificats SSL (en patchant OpenSSH, évidemment). Il est en effet plus facile de virer la clé (qu'on peut aussi stocker dans une base LDAP avec un autre patch pour OpenSSH) de l'employé qui nous quitte plutôt que devoir changer tous les mots de passe parce qu'on s'est quitté en mauvais termes.
Bref, juste mon avis ;-) J'admet qu'il n'est pas toujours évident ni aisé de modifier les habitudes déjà en place au sein des entreprises...
[1] La transmission du savoir ou comment créer une « culture » d'entreprise : http://www.lavienumerique.com/DECALE,Comment-nait-_a5.html
[^] # Re: Ça ne changera pas grand chose, en fait ;-)
Posté par David Guerizec . Évalué à 1.
En fait quand je dis "si votre entreprise a une politique de sécurité incompatible avec le turn-over...", c'est à prendre au sens large, à savoir, pour être plus précis: "si votre entreprise a des clients en infogérence qui vous impose des contraintes de sécurité forte, notement en terme de turn-over...".
Et ça fonctionne aussi pour l'entreprise cliente qui désire externaliser la gestion de son parc, tout en gardant au maximum la main sur le contrôle des accès. Il lui suffit d'installer sshproxy pour offrir un accès unique et jounalisé à son fournisseur de service.
En bref, ce n'est pas forcément l'entreprise elle-même qui a un problème de ressources humaines, mais les différentes interactions entre entreprises ne sont pas toujours basées sur une confiance aveugle, surtout dans le domaine de la sécurité.
Le problème des mots de passe, nous serons d'accord sur ce point, est qu'il faut modifier les machines distantes dont les mots de passe sont potentiellement compromis (par le turn-over pour la version paranoïaque).
Le problème des clés est presque pire que celui des mots de passe: non seulement il faut modifier la machine distante pour supprimer l'accès, mais en plus si on gère un gros parc, une clé compromise permet de se connecter sur l'ensemble des sites. À moins d'utiliser une clé différente pour chaque site, multiplié par le nombre d'utilisateurs, ça devient vite le cauchemard à gérer...
Le projet sshproxy essaie de proposer une solution élégante à ce casse-tête, tout en offrant d'autres fonctionnalités (futures) comme une base de données de scripts d'administration à distance, pour limiter encore plus les accès utilisateurs aux sites.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.