Pour éditer le wiki, il faut demander un compte à un Lapin !
Difference between revisions of "Passerelle SSH"
(→Premieres idées et résultats de recherche) |
m (+cat +wikify) |
||
Line 1: | Line 1: | ||
+ | Comment donner un acces distant sur le reseau du Loop, sans en compromettre la securite, ni alourdir la gestion de [[:Category:Infrastructure|l'infrastructure]] ? | ||
+ | |||
== Premieres idées et résultats de recherche == | == Premieres idées et résultats de recherche == | ||
Line 14: | Line 16: | ||
== Questions en cours == | == Questions en cours == | ||
− | + | N'autoriser que ssh ( dans un chroot ?) pour rebondir vers sa machine du reseau local du loop. | |
− | + | * [http://www.queret.net/blog/post/2010/03/03/Chrooter-une-session-SSH-utilisateur SSH dans un chroot] | |
− | + | Comment faire pour utiliser les users et mdp de la machine cible, pour ne pas avoir a gerer les users sur la passerelle ? | |
− | + | * authoriser toute connexion mais killer toute session qui serait pas un ssh vers une machine locale (limiter le rebond vers l'exterieur par n'importe qui) toutes les X secondes. (X = 10 ?). Cette solution répond aussi a la question du nombre de mdp ... est-ce possible seulement ? | |
− | + | ** [http://www.linux-france.org/article/devl/sshcvs_fr.html CVS via SSH] un contournement, mais ca parait lourd coté client ... | |
− | + | * obligation d'utiliser un user-agent pour utiliser une clef RSA ? (impossible de la stocker la clef privée sur la passerelle ...) | |
− | + | Comment faire pour n'avoir a rentrer son mdp qu'une seule fois ? (ou 0 sans mdp sur la clef). | |
− | + | * [http://linux-attitude.fr/post/Connexion-sans-mot-de-passe utilisation des clefs RSA] | |
− | + | * [http://www.unixwiz.net/techtips/ssh-agent-forwarding.html avec le user-agent] | |
== Mise en place == | == Mise en place == | ||
reste a trouver une petite machine, y mettre une debian de base avec juste ssh. et forwarder le port 22 de la freebox vers la passerelle. | reste a trouver une petite machine, y mettre une debian de base avec juste ssh. et forwarder le port 22 de la freebox vers la passerelle. | ||
− | + | ||
− | + | Configuration de base : | |
− | + | * Root non autorisé. | |
+ | * Utilisation de la version 2 uniquement. | ||
+ | |||
+ | [[Category:Projets]] | ||
+ | [[Category:Logistique]] |
Revision as of 06:21, 11 July 2012
Comment donner un acces distant sur le reseau du Loop, sans en compromettre la securite, ni alourdir la gestion de l'infrastructure ?
Premieres idées et résultats de recherche
A la mano :
- ssh user@passerelle "ssh user@cible"
- Cette méthode demande 2 mots de passe.
En configurant ~/.ssh/config sur le client :
- Utilisation transparente d'une passerelle SSH
- Automatisation de la méthode précédente, 2 mdp a rentrer.
au final aller voir : ca
Questions en cours
N'autoriser que ssh ( dans un chroot ?) pour rebondir vers sa machine du reseau local du loop.
Comment faire pour utiliser les users et mdp de la machine cible, pour ne pas avoir a gerer les users sur la passerelle ?
- authoriser toute connexion mais killer toute session qui serait pas un ssh vers une machine locale (limiter le rebond vers l'exterieur par n'importe qui) toutes les X secondes. (X = 10 ?). Cette solution répond aussi a la question du nombre de mdp ... est-ce possible seulement ?
- CVS via SSH un contournement, mais ca parait lourd coté client ...
- obligation d'utiliser un user-agent pour utiliser une clef RSA ? (impossible de la stocker la clef privée sur la passerelle ...)
Comment faire pour n'avoir a rentrer son mdp qu'une seule fois ? (ou 0 sans mdp sur la clef).
Mise en place
reste a trouver une petite machine, y mettre une debian de base avec juste ssh. et forwarder le port 22 de la freebox vers la passerelle.
Configuration de base :
- Root non autorisé.
- Utilisation de la version 2 uniquement.