Bélier 0.6 : Outil d'automatisation de connexions ssh complexes

Posté par  (site web personnel) . Modéré par baud123.
Étiquettes :
16
16
fév.
2009
Linux
Vous passez 50% de vos journées à joindre en ssh des machines à travers plusieurs serveurs rebonds successifs ? Vous devez vous connecter en ssh plusieurs fois par jour en root sur différentes machines avec PermitRootLogin No dans le sshd_config ? Vous souhaitez lancer une commande via ssh sur plusieurs serveurs difficiles à atteindre ?

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

  • # Mais... ça existe déjà ?!

    Posté par  (site web personnel) . Évalué à 10.

    Vous passez 50% de vos journées à joindre en ssh des machines à travers plusieurs serveurs rebonds successifs ?

    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  (site web personnel) . Évalué à 3.

      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).

      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  . Évalué à 10.

        tu es au courant pour l'agent forwarding ?

      • [^] # Re: Mais... ça existe déjà ?!

        Posté par  (site web personnel) . Évalué à 10.

        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.

        Tu utilises ProxyCommand et netcat dans ton ~/.ssh/config

        • [^] # Re: Mais... ça existe déjà ?!

          Posté par  (site web personnel) . Évalué à 5.

          L'agent forwarding nécessite l'échange de clés, étape qui n'est pas toujours possible de faire sur certains parcs. D'où Bélier et la description des différentes étapes dans son fichier de configuration. Il faut prendre en compte que certains administrateurs n'ont pas toujours la maîtrise totale du parc et doivent pourtant travailler.

          • [^] # Re: Mais... ça existe déjà ?!

            Posté par  (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  (site web personnel) . Évalué à 3.

              C'est sûr que certains admins sont masos, mais faut plutôt les chercher parmi ceux qui tapent 200 fois par jour leur mot de passe. Pour l'échange de clés impossible, on peut prendre le cas d'un bastion d'accès très limitatif (pas de création de fichiers dans ton home autorisé, je parle d'expérience).

              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  . Évalué à 0.

              Dans ce cas, c'est du masochisme.

              C'est donc ça...

            • [^] # Commentaire supprimé

              Posté par  . Évalué à 2.

              Ce commentaire a été supprimé par l’équipe de modération.

              • [^] # Re: Mais... ça existe déjà ?!

                Posté par  (site web personnel) . Évalué à 2.

                Effectivement, quand les équipements le permettent (mais généralement, s'ils ont déjà la pile SSL, c'est le cas), autant utiliser SNMPv3 pour les administrer plutôt qu'un support partiel du protocole SSH.

                • [^] # Commentaire supprimé

                  Posté par  . Évalué à 3.

                  Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Mais... ça existe déjà ?!

          Posté par  (site web personnel) . Évalué à 4.

          Sur 500 machines de prod ? :)

      • [^] # Re: Mais... ça existe déjà ?!

        Posté par  (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  (site web personnel) . Évalué à 1.

          Si t'as échangé les clés et qu'un pirate accède à ton compte, il a accès à tous tes serveurs. Si tu sens la possibilité d'un risque, tu planques les scripts générés par Belier dans un volume chiffré, c'est la seule solution que je vois, ça reste bien plus fiable que l'échange de clés ssh.

          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  (site web personnel) . Évalué à 2.

            Justement, ssh enregistre les noms des machines dans le fichier known_host sous forme de hash dans les dernières versions (en fait, depuis quelques temps maintenant) justement pour ne pas donner à l'attaquant la possibilité de voir sur quelles machines la personne s'était connectée.

            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  (site web personnel) . Évalué à 3.

              Tout à fait, dommage que l'historique du bash vienne facilement trahir l'utilisateur sur les machines auxquelles il se connecte.

              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  (site web personnel) . Évalué à 2.

                Ce qui n'empêche pas de remplir l'historique de bash avec les commandes exécutées via expect...
                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  . Évalué à 5.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Commentaire supprimé

              Posté par  . Évalué à 2.

              Ce commentaire a été supprimé par l’équipe de modération.

              • [^] # Re: heu ...

                Posté par  (site web personnel) . Évalué à 2.

                Tss tss :D

                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  (site web personnel) . Évalué à 4.

                  Quand même, je pense que globalement, les exemples et le logiciel même feraient plus professionnels si tu incluais la sécurisation des clés locales de façon automatique. Rajouter les quelques commandes pour gérer un fichier crypté truecrypt pour stocker tes « ordres » et les exécuter, c'est un poil plus compliqué certes, mais ça fait tellement plus sérieux.

                • [^] # Re: heu ...

                  Posté par  (site web personnel) . Évalué à 4.

                  L'admin parano utilise une carte à puce contenant ses clés privées pour se connecter ;-)

                • [^] # Commentaire supprimé

                  Posté par  . Évalué à 5.

                  Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: heu ...

            Posté par  (site web personnel) . Évalué à 5.

            Pour protéger les clés privées, on peut également les placer sur des partitions chiffrées, des périphériques amovibles, voire une carte à puce.

            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  (site web personnel) . Évalué à 6.

    Dommage, je trouvais l'idée sympatique, mais générer des scripts expect me paraît être un très mauvais choix de design. Pourquoi ne pas utiliser directement python-pexpect ?

    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  (site web personnel) . Évalué à 5.

      Mon choix d'utiliser directement la commande expect et de générer des scripts s'est fait après des premiers tests infructueux avec python-expect, en particulier des retours très bizarre dès qu'on passait sur des unix un peu plus inhabituels que linux, à savoir solaris. La commande expect qui est assez ancienne et éprouvée m'est apparue comme le meilleur choix.

      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  (site web personnel) . Évalué à 4.

        Python... Ce n'est pas non plus le langage de prédilection sous Solaris.

        • [^] # Re: Bad design

          Posté par  (site web personnel) . Évalué à 3.

          Alors que l'interpréteur Expect est embarqué dans bon nombres d'os dans leur version serveurs. Voir à ce sujet l'article d'introduction à Expect dans GLMF de ce mois-ci.

      • [^] # Re: Bad design

        Posté par  (site web personnel) . Évalué à 6.

        > rançais et Python permet une telle clareté dans l'expression que je n'allais sûrement pas me mettre à écrire dans un anglais risible

        En même temps, si on lit le code on a des trucs comme :
        if self.options[0].nomfichier is not None
        elif 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  (site web personnel) . Évalué à 6.

          Ah je trouve ça très clair moi, faut dire il est difficile d'etre objectif avec son code puis un bout de code hors contexte, ça peut sembler toujours très peu clair, un peu comme une phrase sortie de son contexte.

          Mais je t'assure que j'étudie toute contribution :)

          • [^] # Re: Bad design

            Posté par  (site web personnel) . Évalué à 2.

            C'est pas une histoire de contexte ou autre

            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  (site web personnel, Mastodon) . Évalué à 1.

        >Tout ça pour d'éventuels contributeurs anglais qui n'existent pas à ce jour.

        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  (site web personnel) . Évalué à 5.

          Avec cette logique, toute personne qui écrit un livre dans le monde devrait l'écrire en anglais pour s'assurer le plus grand lectorat dès le début.

          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  (site web personnel, Mastodon) . Évalué à 7.

    Et ben, les premiers commentaires ne sont pas très sympas :(

    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  . Évalué à 5.

      J'ai envie de dire pareil.
      Je vais l'essayer et je pense qu'en ce qui me conerne cela pourrait m'être utile.

    • [^] # Re: Et ben...

      Posté par  (site web personnel) . Évalué à 9.

      C'est toujours une épreuve pour les petits projets de passer sur Linuxfr ;)

      • [^] # Re: Et ben...

        Posté par  . Évalué à 10.

        c'est dommage, parce que tout le temps que tu as gagné grâce à Bélier a été rapidement re-perdu depuis à devoir justifier l'intérêt de ton logiciel sur linuxfr ;)

        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  (site web personnel) . Évalué à 7.

          Oui, mais c'est ça le logiciel libre : On peut perdre son temps comme on veut ! ;-)

          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  (site web personnel) . Évalué à 7.

    Le fichier README parle d'une version stable 1.0. Mince, je me suis fait avoir j'ai pris une version 0.6 qui doit sûrement être instable. Je vais pour charger la version git du coup : $ git co ssh://jbdenis.net:9999/belier
    git: '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 :$ ./bel
    SALUT
    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  (site web personnel) . Évalué à 4.

      Sûrement un problème avec le README, merci de le signaler. Tous les dépôts (Debian, installeur Python, repo git) proposent la version 0.6. L'accès au dépot Git est sur le site internet du projet.

      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  . Évalué à 4.

      Si tu es admin des machines, penses également à changer AuthorizedKeysFile dans sshd_config.

      AuthorizedKeysFile %h/.ssh/.RANDOMNAME

      Cela permet d'éviter les injections en aveugle de clé ssh.

  • # Cool !

    Posté par  . Évalué à 0.

    Vraiment sympa ce petit programme, et surtout tellement utile !!!
    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  . Évalué à 3.

    Moi non plus je n'aime pas trop l'idée d'avoir des mots de passe en clair dans des fichiers (pourtant mon home et mon swap sont chiffrés). C'est surtout le fait, que j'ai l'impression que des scripts je peux les "perdre" a gauche a droite, faire un petit backup rapide en oubliant qu'il y a des données importantes non chiffrées, ... le tout sur plusieurs années.

    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  . Évalué à 3.

      Chiffrement systématique?
      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  . Évalué à 1.

    Je connais un produit open source, qui répond à ce besoin, au niveau entreprise. C'est assez récent comme projet mais déjà très complet et fonctionnel, c'est développé par quelqu'un chez Savoir-faire Linux inc, une boîte de service en logiciel libre à Montréal au Canada.

    Ç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.