Bélier permet l’ouverture automatisée d’un terminal ou l’exécution de commandes sur un ordinateur distant via une connexion ssh. L’intérêt principal de Bélier réside dans sa capacité à traverser plusieurs machines intermédiaires avant d’accomplir la tâche assignée :
- Bélier rend transparent pour l’utilisateur la traversée par la connexion ssh d'éventuels ordinateurs intermédiaires sur le chemin de l’ordinateur distant.
- Vous pouvez définir des commandes qui seront exécutées sur l’ordinateur distant.
- Les éventuels changements de compte sur les ordinateurs intermédiaires ou sur la machine finale peuvent être définis.
- Bélier génère 1 script par chemin nécessaire pour atteindre une machine finale.
Bélier est un programme en ligne de commande sous licence GNU GPL v3. Bélier est écrit en Python. Bélier génère des scripts Expect prêts à l'emploi (voir l'article de GLMF sur Expect dans l'édition du mois de février).
Des paquets debian (Etch, Lenny et Sid) ainsi qu'un auto-installeur Python et la possibilité d'installer Bélier par le script easy_install sont à votre disposition. Un dépôt git est également disponible.
Aller plus loin
- Site web du projet (650 clics)
- Exemples d'utilisation (439 clics)
# Mais... ça existe déjà ?!
Posté par Ellendhel (site web personnel) . Évalué à 10.
Oui.
Vous devez vous connecter en ssh plusieurs fois par jour en root sur différentes machines avec PermitRootLogin No dans le sshd_config ?
Également.
Vous souhaitez lancer une commande via ssh sur plusieurs serveurs difficiles à atteindre ?
Je le fais déjà via ssh_agent et des clés publiques (le passage d'un compte utilisateur vers le compte root se fait "à la main" neanmoins, j'en limite l'usage).
(voir http://formation-debian.via.ecp.fr/ssh.html#id286908 par exemple pour ceux qui ne connaîtraient pas la chose)
Je conçois bien l'utilisation de Bélier, mais le fait d'avoir des scripts comportant des mots de passe en clair me paraît assez peu attrayant... Il faudrait prévoir une évolution basée sur des connexions par clé publique.
[^] # Re: Mais... ça existe déjà ?!
Posté par Carl Chenet (site web personnel) . Évalué à 3.
Et tu fais comment pour te connecter successivement à ton serveur C qui est derrière A et B ? Tu chaînes les connexions ssh à la main. Puis encore une fois tu changes de compte à la main avec ton 500ème 'su -' de la journée. Bélier répond exactement à ton besoin.
le fait d'avoir des scripts comportant des mots de passe en clair me paraît assez peu attrayant...
De toute façon si ton poste est compromis, que les mots de passe soient en clair sur ton poste ou avec un keylogger, tu n'y échappes pas.
Mais Bélier gère tout à fait le fait que tu aies échangé les clés sur le trajet à accomplir jusqu'à ta machine destination, ce qui réduira l'utilisation des mots de passe en clair sur ton poste client.
[^] # Re: Mais... ça existe déjà ?!
Posté par Dabowl_92 . Évalué à 10.
[^] # Re: Mais... ça existe déjà ?!
Posté par Aurélien Jarno (site web personnel) . Évalué à 10.
Tu utilises ProxyCommand et netcat dans ton ~/.ssh/config
[^] # Re: Mais... ça existe déjà ?!
Posté par Carl Chenet (site web personnel) . Évalué à 5.
[^] # Re: Mais... ça existe déjà ?!
Posté par Raphaël SurcouF (site web personnel) . Évalué à 4.
L'agent forwarding nécessite l'échange de clés, étape qui n'est pas toujours possible de faire sur certains parcs.Parce que c'est interdit par certaines directives ou pour d'autres raisons ?
Il faut prendre en compte que certains administrateurs n'ont pas toujours la maîtrise totale du parc et doivent pourtant travailler.Dans ce cas, c'est du masochisme.
[^] # Re: Mais... ça existe déjà ?!
Posté par Carl Chenet (site web personnel) . Évalué à 3.
L'avantage de Bélier est de regrouper tout ce qu'il faut au niveau de ton seul poste de travail, après tant que les serveurs ont la commande ssh de base, tu te connecteras n'importe où.
[^] # Re: Mais... ça existe déjà ?!
Posté par Raphaël SurcouF (site web personnel) . Évalué à 1.
En principe, tu ne devrais pas y toucher tous les jours : mises à jour d'AV ?
[^] # Re: Mais... ça existe déjà ?!
Posté par mathic . Évalué à 0.
C'est donc ça...
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Mais... ça existe déjà ?!
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Mais... ça existe déjà ?!
Posté par Carl Chenet (site web personnel) . Évalué à 4.
[^] # Re: Mais... ça existe déjà ?!
Posté par Raphaël SurcouF (site web personnel) . Évalué à 6.
Puppet ?
[^] # Re: Mais... ça existe déjà ?!
Posté par Carl Chenet (site web personnel) . Évalué à 3.
[^] # Re: Mais... ça existe déjà ?!
Posté par Raphaël SurcouF (site web personnel) . Évalué à 7.
Et tu fais comment pour te connecter successivement à ton serveur C qui est derrière A et B ? Tu chaînes les connexions ssh à la main. Puis encore une fois tu changes de compte à la main avec ton 500ème 'su -' de la journée. Bélier répond exactement à ton besoin.Si tu as si souvent besoin d'être root pour certains commandes bien définies, tu peux aussi t'appuyer sur sudo (ça existe sous Solaris aussi).
De toute façon si ton poste est compromis, que les mots de passe soient en clair sur ton poste ou avec un keylogger, tu n'y échappes pas.Ce n'est pas une raison pour laisser traîner des mots de passe en clair dans des fichiers non plus (l'attaque par keylogger est quand même moins facile que lire un bête fichier).
Tu peux aussi séparer *physiquement* les postes d'administration des postes de travail « classiques » et à plus forte raison s'ils sont reliés à Internet. Sans oublier des les équiper d'AV, même s'ils sont sous Linux (oui, les logiciels malveillants existent aussi sous Linux, même s'ils sont moins nombreux que sous Windows pour l'instant).
Bref, ton projet peut être intéressant pour certains mais il y a néanmoins certains préjugés face à certains outils qu'il faut casser (les clés SSH, notamment).
[^] # heu ...
Posté par Carl Chenet (site web personnel) . Évalué à 1.
Sans parler de l'admin qui part le midi sans bloquer son poste avec le terminal ouvert, niveau sécu ça peut être desastreux l'échange de clés si on considère le poste client.
[^] # Re: heu ...
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
En fait, il y a pas mal de petit détail comme cela dans ssh pour divulger le moins d'information possible.
Historiquement, il faut un script du type expect pour donner son mot de passe a ssh car celui-ci a été conçu pour justement éviter de d'écrire son mot de passe dans un fichier ou sur la ligne de commande. Cela dis, rien n'interdit de faire un script expect. Je dois dire qu'expect dépanne bien dans certaines situations autre que ssh (installation automatique de logiciel propriétaire...)
[^] # Re: heu ...
Posté par Carl Chenet (site web personnel) . Évalué à 3.
C'est le rôle même d'expect d'intervenir dans des situations alambiquées. D'où l'intérêt de Bélier pour générer des connexions ssh complexes qui permet à l'utilisateur de ne lancer que le script et d'arriver trois bastions plus loin connecté en root à la machine sur laquelle il doit travailler, sans avoir dû chaîner trois connexions ssh manuellement et saisir son mot de passe root à l'arrivée.
[^] # Re: heu ...
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
On peut toujours ignorer certaines entrées dans l'historique de bash à l'aide de la variable HISTIGNORE :
http://ashterix.blogspot.com/2006/07/bash-history-ignore-dup(...)
D'autre part, si l'admin doit taper ses mots de passe assez souvent, ça permet de les retenir assez facilement et cela lui évite de devoir les noter quelque part (comme ça arrive quand ils sont inutilement complexes).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: heu ...
Posté par Carl Chenet (site web personnel) . Évalué à 2.
Ben le volume chiffré, une fois démonté, interdit une personne qui a accès à ta machine d'accéder aux données sur ce disque. Donc là t'es protégé. Évidemment faut démonter le volume quand tu t'absentes. Mais ça ne doit pas faire peur à un vrai admin parano.
Alors que l'échange de clés lui est toujours là.
[^] # Re: heu ...
Posté par Philippe F (site web personnel) . Évalué à 4.
[^] # Re: heu ...
Posté par Raphaël SurcouF (site web personnel) . Évalué à 4.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: heu ...
Posté par Raphaël SurcouF (site web personnel) . Évalué à 5.
Quant à l'admin qui oublie de bloquer sa session, c'est une faute de sa part. Sinon, il y a toujours une configuration automatique pour la bloquer après un délai d'inactivité, pour les distraits maladifs. Et ces personnes-là ne préservent pas plus la sécurité avec l'ensemble de leurs scripts expect sur leur poste de travail que leurs clés privées, hein.
Faut arrêter de prendre de tels exemples à double tranchant.
# Bad design
Posté par Julien Danjou (site web personnel) . Évalué à 6.
De plus, tout le code est en francais, donc perso, j'ai aussitôt refermé. Ce genre de chose abouti en général à un projet mort-né vu que cela restreint la compréhension et les contributions au code aux seuls francophones, donc à peu de gens.
[^] # Re: Bad design
Posté par Carl Chenet (site web personnel) . Évalué à 5.
Heureux que tu aies déjà des vues internationales pour Bélier, mais pour l'instant mon audience est francophone, je suis moi-même français et Python permet une telle clareté dans l'expression que je n'allais sûrement pas me mettre à écrire dans un anglais risible, toutu ça pour d'éventuels contributeurs anglais qui n'existent pas à ce jour.
Python 3000 arrive avec la gestion des noms de variables en utf-8, c'est bon mangez-en.
[^] # Re: Bad design
Posté par Raphaël SurcouF (site web personnel) . Évalué à 4.
[^] # Re: Bad design
Posté par Carl Chenet (site web personnel) . Évalué à 3.
[^] # Re: Bad design
Posté par Philippe F (site web personnel) . Évalué à 2.
Python 2.4 a un très bon module subprocess pour lancer des programmes et gérer des pipes.
[^] # Re: Bad design
Posté par Raphaël SurcouF (site web personnel) . Évalué à 3.
[^] # Re: Bad design
Posté par CrEv (site web personnel) . Évalué à 6.
En même temps, si on lit le code on a des trucs comme :
if self.options[0].nomfichier is not Noneelif not isfile(fichierentree):Et là, c'est ni beau ni élégant, ni clair, qu'on le regarde en français ou en anglais
[^] # Re: Bad design
Posté par Carl Chenet (site web personnel) . Évalué à 6.
Mais je t'assure que j'étudie toute contribution :)
[^] # Re: Bad design
Posté par CrEv (site web personnel) . Évalué à 2.
Mais lire du code avec certains mots dans une langue, d'autres dans une autre c'est pas cohérent du tout.
isfile(fichierentree) c'est pas beau ;)
isfile(input) est un peu plus logique comme écriture...
> j'étudie toute contribution
Ben juste comme dit plus haut, code en anglais ;)
C'est juste une habitude assez pratique et surtout le code est plus cohérent, avec un bon et vrai langage ça se lit presque comme si on lisait des phrases.
[^] # Re: Bad design
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 1.
C'est sûr que tu n'a pas de contributeurs anglais (et tu auras peu de chances d'en avoir), vu que c'est en français. C'est un peu comme faire un site qui a un script qui check le navigateur et n'accepte que IE, et dire ensuite que ce n'est pas la peine de faire un site compatible avec les autres navigateurs vu que dans les stats, ils sont totalement insignifiants. (c'est du vecu :-) )
Ensuite, en parlant de "contributeurs anglais": Le monde est vaste, les contributeurs peuvent venir de tout pays, pas seulement des états unis ou Angleterre. Et l'anglais est probablement la langue la plus "universelle" (surtout en informatique). Donc c'est pas seulement des contributeurs "anglais" que tu pourrais avoir ;-)
Bonne continuation dans ce projet tout de même :-)
[^] # Re: Bad design
Posté par Carl Chenet (site web personnel) . Évalué à 5.
La langue n'est pas un pur outil. Si elle sert à se faire comprendre, elle véhicule avant tout un mode de pensée et une culture, en informatique ou ailleurs. L'informatique est dominée par l'anglais ? Ben je suis au courant mais je m'y plie le moins possible. Et apparemment d'autres non plus vu les efforts qui sont faits pour permettre une plus grande utilisation des langues autres que l'anglais (je pense à la systématisation de l'utf-8).
# Et ben...
Posté par aurel . Évalué à 7.
Pour être un francophone habitué des connexions SSH, et même sans avoir essayé Bélier pour l'instant, je trouve l'idée sympa :)
Merci beaucoup :)
Aurel.
[^] # Re: Et ben...
Posté par tuxsmouf . Évalué à 5.
Je vais l'essayer et je pense qu'en ce qui me conerne cela pourrait m'être utile.
[^] # Re: Et ben...
Posté par Carl Chenet (site web personnel) . Évalué à 9.
[^] # Re: Et ben...
Posté par B16F4RV4RD1N . Évalué à 10.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Et ben...
Posté par Pierre Jarillon (site web personnel) . Évalué à 7.
Et puis tout le monde sait que c'est à cause de leur fainéantise que les informaticiens les plus doués se sont crevé le cul pour faire des programmes qui leur faisaient gagner du temps. Ou peut en citer des quantités, par exemple "file completion", history... et maintenant bélier !
# Remarques diverses
Posté par Victor STINNER (site web personnel) . Évalué à 7.
$ git co ssh://jbdenis.net:9999/beliergit: 'co' is not a git-command
$ git checkout ssh://jbdenis.net:9999/belier
fatal: Not a git repository
$ svn co ssh://jbdenis.net:9999/belier
svn: Schéma d'URL non reconnu pour 'ssh://jbdenis.net:9999/belier'
Bon, pas compris. Tiens, un fichier exécutable qui s'appelle bel, essayons ça :
$ ./belSALUT
help
??
^D
Euh, qu'est-ce qui s'est passé ? Il n'y a pas d'invite, il ne me dit pas ce qu'il fait, j'ai rien compris. En lisant, les sources je découvre que « bel » (bel... belier ?) prend des arguments !
$ ./bel --help
Usage: bel [options]
Options:
--version show program's version number and exit
-h, --help show this help message and exit
-e FICHIER, --entree=FICHIER
contient les ordres pour générer le ou les scripts
-s RÉPERTOIRE, --repertoire-sortie=RÉPERTOIRE
répertoire où entreposer les fichiers générés
-d DÉLAI, --delai=DÉLAI
en secondes pour exécuter une commande du script
$ ./bel --version
bel 0.1
Décidément, j'ai vraiment pas la bonne version :-)
Pourquoi le projet génère des scripts shell plutôt que des scripts Python ? Python est plus portable que shell (moins de conflits entre sh, bash, zsh, etc.) ;-)
Je cherchais la référence à Fusil dans le code source, mais je n'ai rien vu. Le site web parle de tests, je ne les vois pas non plus dans le tarball.
Bélier semble stocker les mots de passe en clair. C'est pas terrible. Si un pirate vole un fichier .sh, il connaît les nom des machines, les logins et mots de passe associés. Perso je bloque l'authentification par mot de passe et force l'authentification par certificat (fichiers ~/.ssh/id_rsa et ~/.ssh/id_rsa.pub). Ma clé SSH est protégée par une longue passphrase. Même si un pirate me vole la clé, il lui faudra la passphrase pour l'utiliser.
[^] # Re: Remarques diverses
Posté par Carl Chenet (site web personnel) . Évalué à 4.
Pour le script fusil que j'utilise, il n'a pas été rendu public, mais si tu as un besoin, je peux tout à fait le rajouter au dépôt git. Je ne voyais pas trop les gens se mettre à tester Bélier avec mon script fusil et à me remonter les bugs, ce serait trop beau :)
La discussion sur les mots de passe en clair a eu lieu quelques commentaires plus haut. De toute façon il est très difficile de se protéger totalement en environnement hostile, et échanger les clés peut être contré si un attaquant prend possession de ton poste de travail. En environnement de sécurité critique, il faut trouver un compromis entre l'automatisation des tâches et la sécurité.
[^] # Re: Remarques diverses
Posté par Carl Chenet (site web personnel) . Évalué à 3.
[^] # Re: Remarques diverses
Posté par oat5hd . Évalué à 4.
AuthorizedKeysFile %h/.ssh/.RANDOMNAME
Cela permet d'éviter les injections en aveugle de clé ssh.
# Cool !
Posté par gallenza . Évalué à 0.
En plus c'est du Python c'est bon mangez-en :-)
Je crois que bien des admins sys vont devenir accros... bientôt un standard !!
# amelioration
Posté par RB . Évalué à 3.
Par contre je trouve l'idée bonne, mais je me demandais si tu pouvais pas interfacer ça proprement avec un chiffrement gnupg systématique lors de la création du "script" (ou du payload du script) avec l'appel a gnupg pour le déchiffrement au moment de l'exécution (donc un header dans le script qui appelle gnupg pour déchiffrer l'intérieur, puis nettoyage si nécessaire, ainsi le script est tjs tout en un). Ensuite chacun peu utiliser un gpg-agent pour avoir à taper ce mot de passe une seule fois.
[^] # Re: amelioration
Posté par Grunt . Évalué à 3.
NOOON!
Optionnel?
Oui, bien sûr..
Rien n'est plus chiant qu'un soft qui réclame systématiquement l'utilisation d'un gpg-agent, sans pouvoir s'affranchir de cette contrainte.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
# Une vraie solution: cryptographie, organisation, connexion automatique..
Posté par wackysalut . Évalué à 1.
Ça s'appelle SFLvault. Ça possède une architecture client-serveur, une robuste cryptographie pour les mots de passes des services, et même dans la distribution des permissions (groupes, etc..)
Il classe les services en clients (Customers), possédant des machines, et chaque machine peut se voir attribué un ou plusieurs services (ssh, mysql, http, postgresql, sudo, etc..). Les services peuvent être hiérarchisés, et le client SFLvault permet une connexion automatique, à des services en cascades, des ssh via des ssh, et même l'accès au client mysql distant, avec authentification automatique.
En développement sont le port forward sur une machine distante (à plusieurs sauts), l'implémentation du protocol FISH pour télécharger des fichiers à travers le terminal une fois connecté via plusieurs machines, le montage de disques réseaux SSHFS remote (multi-hop), le tout en utilisant la même voûte sécurisée.
La cryptographie utilisée est très semblable à celle de GnuPG. Des algorithmes à clé partagées et des algorithmes symmétriques sont combinés pour donner la flexibilité dans l'attribution des permissions, et une vraie sécurité.
Allez, jetez-y un coup d'oeil. Le développeur de Bélier sera ravi, parce que SFLvault est écrit en Python (le serveur basé sur Pylons), hébergé sous Linux, dans un système Trac, et versionné avec Git :)
http://www.sflvault.org
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.