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 NeoX . É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 benja . É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 Raoul Volfoni (site web personnel) . É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.
Un marque page sur un port TCP ??? Que veux-tu dire ?
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 NeoX . Évalué à 2.
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
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 Raoul Volfoni (site web personnel) . Évalué à 2.
Non, c'est un VPN avec ssh, mais c'est un détail.
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 benja . Évalué à 2.
En gros tu veux lancer des ssh -L port:remote:remoteport avec port < 1024, n'est-ce pas ?
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 ; fiBon 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 Raoul Volfoni (site web personnel) . Évalué à 2.
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.
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.
Tip Top ! C'est exactement ce que je voulais. ;) Merci.
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 benja . É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 benja . É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 Raoul Volfoni (site web personnel) . Évalué à 2.
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 NeoX . Évalué à 2.
depuis quand il faut rebooter pour tester une commande ?
[^] # Re: pourquoi ?
Posté par Raoul Volfoni (site web personnel) . Évalué à 2.
T'énerves pas Yohann, c'était juste une façon de parler…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.