Forum Astuces.divers Comment lancer un ssh-agent pour root au boot ?

Posté par (page perso) .
Tags : aucun
-1
10
août
2012

Salut,

Voilà, comme à chaque fois que je lance une session de travail j'ai besoin d'avoir tout un tas de redirections de ports < 1024 avec ssh, il faut que ce soit root qui s'en charge.
Il faut donc que j'ouvre un terminal, que je me connecte en root puis que je lance un ssh-agent, que j'exporte ensuite les variables SSH_AUTH_SOCK et SSH_AGENT_PID et enfin que je charge mes clés avec ssh-add.
Tout ça avant de pouvoir lancer mes scripts automatiques de redirections ! Pfiou.

J'utilise Kde et j'ai un script qui lance un ssh-add depuis Autostart ce qui lance Ksshaskpass qui appelle (je ne sais trop comment) Kwallet. Ainsi mes différentes clés sont ajoutées à l'agent ssh dès l'ouverture de session. L'idéal serait qu'il en soit de même pour root. Il faudrait donc que j'arrive pas à pas à:

1) avoir un ssh-agent de lancé au boot du système pour l'utilisateur root
2) que les variables d'environnement SSH_AUTH_SOCK et SSH_AGENT_PID soient correctement renseignées quand j'ouvre un terminal sous root.
3) que je puisse appeler un script qui lance un ssh-add pour root (genre sudo ssh-add) à l'ouverture de ma session Kde.
4) cerise sur le gateau, si le précédent script pouvait appeler ksshaskpass et faire appel à kwallet ce serait byzance. ;) Mais là il faut que je lise un peu de doc avant.

Voili-voilou, si vous avez des pistes n'hésitez pas.
Merci d'avance.

  • # pourquoi ?

    Posté par . Évalué à 2.

    pourquoi faire des redirections de ports 1024 pour pouvoir les faire en utilisateur.

    ta redirection du port local 443 vers le serveur https://XYZ.com devient alors le port 8443 (par exemple
    et il suffit alors de te connecter à https://localhost:8443 pour que cela fonctionne.

    et si le 8443 te genes, suffit de mettre un marque page dessus.

    note que pour le coup, tu peux mettre tes redirections de ports dans autossh pour que les ports se remappes des la connexion reseau.

    • [^] # Re: pourquoi ?

      Posté par . Évalué à 1.

      Sinon le coup d'iptables ça marche aussi, il suffit de rediriger le port <1024 sur un port que l'user peut binder.

    • [^] # Re: pourquoi ?

      Posté par (page perso) . Évalué à 2.

      pourquoi faire des redirections de ports 1024 pour pouvoir les faire en utilisateur.

      Je parle de ports inférieurs à 1024. Il n'y a pas que des services standards, il y a un VPN, des applications spécifiques et des redirections dynamiques pour le reste du Lan.

      et si le 8443 te genes, suffit de mettre un marque page dessus.

      Un marque page sur un port TCP ??? Que veux-tu dire ?

      note que pour le coup, tu peux mettre tes redirections de ports dans autossh

      autossh ne sert à rien quand je reboot ma machine. Pour le reste je n'ai pas de souci avec mon réseau.
      Mais merci quand même. ;)

      • [^] # Re: pourquoi ?

        Posté par . Évalué à 2.

        Je parle de ports inférieurs à 1024. Il n'y a pas que des services standards, il y a un VPN, des applications spécifiques et des redirections dynamiques pour le reste du Lan.

        ton server vpn est sur le port disons 1194 TCP ou UDP pour openvpn
        qu'est ce qui t'empeche de faire ta redirection ssh sur le port 21194 et dire à ton client VPN de se connecter sur le localhost:21194 plutot que sur localhost:1194

        et si le 8443 te genes, suffit de mettre un marque page dessus.

        Un marque page sur un port TCP ??? Que veux-tu dire ?

        le marque page, c'etait pour l'exemple avec https://localhost:8443 dans le cas ou on a du mal à se souvenir de rajouter le port 8443 à la fin de l'URL alors que le https sans port se fera sur 443

        bref, je ne comprend toujours pas pourquoi tu as besoin des ports inferieurs à 1024 dans ta redirection ssh.

        en utilisateur j'ai toujours fait : ssh -L 8xxx:machine_a_joindre:port utilisateur@machine_tunnel
        pour ensuite demander à mon logiciel local (thunderbird, firefox, filezilla, whatever, etc) de se connecter sur le port 8xxx de localhost

        • [^] # Re: pourquoi ?

          Posté par (page perso) . Évalué à 2.

          ton server vpn est sur le port disons 1194 TCP ou UDP pour openvpn

          Non, c'est un VPN avec ssh, mais c'est un détail.

          pour ensuite demander à mon logiciel local (thunderbird, firefox, filezilla, whatever, etc)

          Justement, whatever n'accepte pas…
          Mais j'ai l'impression d'avoir mal posé ma question parce que la redirection de port ce n'est pas vraiment mon problème même s'ils sont en dessous de 1024.

          Ce que je cherche c'est à avoir au minimum un ssh-agent pour root au boot du système. Le reste c'est cosmétique.

          • [^] # Re: pourquoi ?

            Posté par . Évalué à 2.

            En gros tu veux lancer des ssh -L port:remote:remoteport avec port < 1024, n'est-ce pas ?

            Ce que je cherche c'est à avoir au minimum un ssh-agent pour root au boot du système. Le reste c'est cosmétique.

            Je ne suis pas sur de suivre ton raisonement… Quel est l'interêt ? Tu veux pouvoir manipuler un trousseau "global" par ton user (ou par sudo) afin que tes scripts ne te demande plus aucun mot de passe, est-ce donc cela ? Personnelement, je ferais l'inverse cf. plus bas… Enfin soit puisque c'est ce que tu as gentillement demandé…

            dans rc.boot, rc.local ou le truc qui va bien pour ta distrib:
            ssh-agent > /root/ssh-agent.env

            dans /etc/bash.bashrc ou le truc qui va bien pour ton shell
            if [ `id -u` -eq 0 -a -r /root/ssh-agent.env ]; then source /root/ssh-agent.env ; fi

            Bon c'est assez dégueu, ça ne vérifie pas que le ssh-agent est encore là,… 'fin ce serait plus ou moins l'idée. Est-ce que ça te convient ?

            Ceci dit je ferais l'inverse, je demanderais à mes "scripts de connections" d'interroger le ssh-agent de l'user… Alors chez moi sudo -E /bin/bash -c "echo \$SSH_AGENT_PID; ssh-add -L" fonctionne et permet de lancer ssh en root mais en utilisant le trousseau de l'user… Est-ce que cela pourrait te convenir ? Sinon merci d'expliquer ton problème de façon plus explicite pour que l'on puisse t'aider… Aussi pourquoi tiens-tu absolument vouloir lancer ces scripts en root, vu que ce n'est pas une question de port <1024, quelle est la raison ? Merci d'avance de satisfaire à ma curiosité :)

            • [^] # Re: pourquoi ?

              Posté par (page perso) . Évalué à 2.

              En gros tu veux lancer des ssh -L port:remote:remoteport avec port < 1024, n'est-ce pas ?

              C'est à peu près cela avec également du forwarding dynamique (pour certains postes du Lan), du remote (pour qd je suis en déplacement), un tunneling et des exécutions de scripts distants.

              afin que tes scripts ne te demande plus aucun mot de passe, est-ce donc cela ?

              Ben de toutes façons une fois la passphrase saisie par root c'est le cas. Je pensais juste pouvoir éviter cette étape avec l'outil ksshaskpass mais je vais devoir lire la doc.

              dans rc.boot, rc.local ou le truc qui va bien pour ta distrib:
              ssh-agent > /root/ssh-agent.env

              dans /etc/bash.bashrc ou le truc qui va bien pour ton shell
              if [ id -u -eq 0 -a -r /root/ssh-agent.env ]; then source /root/ssh-agent.env ; fi

              Tip Top ! C'est exactement ce que je voulais. ;) Merci.

              Alors chez moi sudo -E /bin/bash -c "echo \$SSH_AGENT_PID; ssh-add -L" fonctionne et permet de lancer ssh en root mais en utilisant le trousseau de l'user… Est-ce que cela pourrait te convenir ?

              Heu là je ne suis pas certain de comprendre. Le compte root utilise l'agent SSH d'un utilisateur lambda ? C'est bien cela ? J'ignorais totalement que c'était possible.
              Sinon pour moi l'option 'L' de ssh-add ne fait que lister les clés authentifiées par l'agent mais c'est un détail.
              En tous cas merci beaucoup. Je vais également regarder de ce coté là.

              • [^] # Re: pourquoi ?

                Posté par . Évalué à 1.

                En fait l'option -E de sudo préserve l'environement c.-à-d. tes variables SSH_* pour que le process root se connecte à l'agent de l'user. (Il y a peut-être qq chose à activer du côté de /etc/sudoers, je ne me souvient plus.) ssh-add -L c'était juste pour prouver que le process root se connecte bien à l'agent de l'user. De suite l'intégration avec kwallet ou que sais-je est transparente il me semble…

                • [^] # Re: pourquoi ?

                  Posté par . Évalué à 1.

                  Sinon il y a toujours la forme suivant qui peut marcher aussi : 'sudo SSH_AGENT_PID=$SSH_AGENT_PID SSH_AUTH_SOCK=$SSH_AUTH_SOCK ma_commande'.
                  Pour répondre à votre question: un process root aura les permissions nécessaire sur la socket unix de l'user donc ça marche. !

                • [^] # Re: pourquoi ?

                  Posté par (page perso) . Évalué à 2.

                  De suite l'intégration avec kwallet ou que sais-je est transparente il me semble…

                  Encore merci. Je vais tester cette solution mais j'ai de gros traitements en cours, donc pas de reboot avant plusieurs jours.

                  • [^] # Re: pourquoi ?

                    Posté par . Évalué à 2.

                    Encore merci. Je vais tester cette solution mais j'ai de gros traitements en cours, donc pas de reboot avant plusieurs jours.

                    depuis quand il faut rebooter pour tester une commande ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.