Bonjour,
J'utilise proxytunnel pour me connecter à un serveur SSH. Si je rajoute
l'option -e, le traffic est chiffré en SSL, ce qui est intéressant
pendant la phase de négociation (avant que SSH ne soit réellement
actif). Toutefois, mon serveur SSH (Openssh-server 1:5.5p1-5) ne
reconnaît plus rien et n'accepte pas que je me connecte si j'ai cette
option [qui m'est obligatoire].
Bonjour,
J'utilise proxytunnel pour me connecter à un serveur SSH. Si je rajoute
l'option -e, le traffic est chiffré en SSL, ce qui est intéressant
pendant la phase de négociation (avant que SSH ne soit réellement
actif). Toutefois, mon serveur SSH (Openssh-server 1:5.5p1-5) ne
reconnaît plus rien et n'accepte pas que je me connecte si j'ai cette
option [qui m'est obligatoire].
Bonjour,
J'utilise proxytunnel pour me connecter à un serveur SSH. Si je rajoute
l'option -e, le traffic est chiffré en SSL, ce qui est intéressant
pendant la phase de négociation (avant que SSH ne soit réellement
actif). Toutefois, mon serveur SSH (Openssh-server 1:5.5p1-5) ne
reconnaît plus rien et n'accepte pas que je me connecte si j'ai cette
option [qui m'est obligatoire].
J'utilise proxytunnel pour me connecter à un serveur SSH. Si je rajoute
l'option -e, le traffic est chiffré en SSL, ce qui est intéressant
pendant la phase de négociation (avant que SSH ne soit réellement
actif). Toutefois, mon serveur SSH (Openssh-server 1:5.5p1-5) ne
reconnaît plus rien et n'accepte pas que je me connecte si j'ai cette
option [qui m'est obligatoire].
Avez-vous déjà été confronté à ce problème ?
Et avez-vous trouvé une solution ?
J'utilise proxytunnel pour me connecter à un serveur SSH. Si je rajoute
l'option -e, le traffic est chiffré en SSL, ce qui est intéressant
pendant la phase de négociation (avant que SSH ne soit réellement
actif). Toutefois, mon serveur SSH (Openssh-server 1:5.5p1-5) ne
reconnaît plus rien et n'accepte pas que je me connecte si j'ai cette
option [qui m'est obligatoire].
Avez-vous déjà été confronté à ce problème ?
Et avez-vous trouvé une solution ?
J'utilise proxytunnel pour me connecter à un serveur SSH. Si je rajoute
l'option -e, le traffic est chiffré en SSL, ce qui est intéressant
pendant la phase de négociation (avant que SSH ne soit réellement
actif). Toutefois, mon serveur SSH (Openssh-server 1:5.5p1-5) ne
reconnaît plus rien et n'accepte pas que je me connecte si j'ai cette
option [qui m'est obligatoire].
Avez-vous déjà été confronté à ce problème ?
Et avez-vous trouvé une solution ?
On Thu, Oct 07, 2010 at 09:12:20AM +0200, David BERCOT wrote:
> J'utilise proxytunnel pour me connecter à un serveur SSH. Si je
> rajoute l'option -e, le traffic est chiffré en SSL, ce qui est
> intéressant pendant la phase de négociation (avant que SSH ne soit
> réellement actif). Toutefois, mon serveur SSH (Openssh-server
> 1:5.5p1-5) ne reconnaît plus rien et n'accepte pas que je me
> connecte si j'ai cette option [qui m'est obligatoire].
Ãa parait normal, sshd s'attend à une connexion SSH, et tu
te connectes alors en SSL: pas le bon protocole, donc.
> Avez-vous déjà été confronté à ce probl ème ?
> Et avez-vous trouvé une solution ?
Non, mais j'essairais de décapsuler le SSH du SSL en mettant
stunnel en frontal, comme ceci:
ssh -> proxytunnel -e --------ssh/ssl------> stunnel ---ssh---> sshd
La configuration de stunnel n'est pas totalement triviale:
il faut écouter (par ex. sur 443...), forwarder sur port 22,
et générer un certificat.
On doit même pouvoir supporter HTTPS en intercalant sslh
après stunnel, sslh switchant alors du traffic HTTP
déchiffré par stunnel:
ssh -> proxytunnel -e --------ssh/ssl------> stunnel ---ssh---> sslh
--> sshd
navigateur --------http/ssl------> stunnel ---http---> sslh -->
http:80
Rien de tout ça n'est testé :-)
On Thu, Oct 07, 2010 at 09:12:20AM +0200, David BERCOT wrote:
> J'utilise proxytunnel pour me connecter à un serveur SSH. Si je
> rajoute l'option -e, le traffic est chiffré en SSL, ce qui est
> intéressant pendant la phase de négociation (avant que SSH ne soit
> réellement actif). Toutefois, mon serveur SSH (Openssh-server
> 1:5.5p1-5) ne reconnaît plus rien et n'accepte pas que je me
> connecte si j'ai cette option [qui m'est obligatoire].
Ãa parait normal, sshd s'attend à une connexion SSH, et tu
te connectes alors en SSL: pas le bon protocole, donc.
> Avez-vous déjà été confronté à ce probl ème ?
> Et avez-vous trouvé une solution ?
Non, mais j'essairais de décapsuler le SSH du SSL en mettant
stunnel en frontal, comme ceci:
ssh -> proxytunnel -e --------ssh/ssl------> stunnel ---ssh---> sshd
La configuration de stunnel n'est pas totalement triviale:
il faut écouter (par ex. sur 443...), forwarder sur port 22,
et générer un certificat.
On doit même pouvoir supporter HTTPS en intercalant sslh
après stunnel, sslh switchant alors du traffic HTTP
déchiffré par stunnel:
ssh -> proxytunnel -e --------ssh/ssl------> stunnel ---ssh---> sslh
--> sshd
navigateur --------http/ssl------> stunnel ---http---> sslh -->
http:80
Rien de tout ça n'est testé :-)
On Thu, Oct 07, 2010 at 09:12:20AM +0200, David BERCOT wrote:
> J'utilise proxytunnel pour me connecter à un serveur SSH. Si je
> rajoute l'option -e, le traffic est chiffré en SSL, ce qui est
> intéressant pendant la phase de négociation (avant que SSH ne soit
> réellement actif). Toutefois, mon serveur SSH (Openssh-server
> 1:5.5p1-5) ne reconnaît plus rien et n'accepte pas que je me
> connecte si j'ai cette option [qui m'est obligatoire].
Ãa parait normal, sshd s'attend à une connexion SSH, et tu
te connectes alors en SSL: pas le bon protocole, donc.
> Avez-vous déjà été confronté à ce probl ème ?
> Et avez-vous trouvé une solution ?
Non, mais j'essairais de décapsuler le SSH du SSL en mettant
stunnel en frontal, comme ceci:
ssh -> proxytunnel -e --------ssh/ssl------> stunnel ---ssh---> sshd
La configuration de stunnel n'est pas totalement triviale:
il faut écouter (par ex. sur 443...), forwarder sur port 22,
et générer un certificat.
On doit même pouvoir supporter HTTPS en intercalant sslh
après stunnel, sslh switchant alors du traffic HTTP
déchiffré par stunnel:
ssh -> proxytunnel -e --------ssh/ssl------> stunnel ---ssh---> sslh
--> sshd
navigateur --------http/ssl------> stunnel ---http---> sslh -->
http:80
Rien de tout ça n'est testé :-)
> On doit même pouvoir supporter HTTPS en intercalant sslh
> après stunnel, sslh switchant alors du traffic HTTP
> déchiffré par stunnel:
Alors là , ça m'intéresse beaucoup. Je me suis dit que j'al lais perdre
ces fonctionnalités :-(
> ssh -> proxytunnel -e --------ssh/ssl------> stunnel ---ssh---> sslh
> --> sshd
>
> navigateur --------http/ssl------> stunnel ---http---> sslh -->
> http:80
>
> Rien de tout ça n'est testé :-)
Je vais le faire ;-)... ce week-end...
> On doit même pouvoir supporter HTTPS en intercalant sslh
> après stunnel, sslh switchant alors du traffic HTTP
> déchiffré par stunnel:
Alors là , ça m'intéresse beaucoup. Je me suis dit que j'al lais perdre
ces fonctionnalités :-(
> ssh -> proxytunnel -e --------ssh/ssl------> stunnel ---ssh---> sslh
> --> sshd
>
> navigateur --------http/ssl------> stunnel ---http---> sslh -->
> http:80
>
> Rien de tout ça n'est testé :-)
Je vais le faire ;-)... ce week-end...
> On doit même pouvoir supporter HTTPS en intercalant sslh
> après stunnel, sslh switchant alors du traffic HTTP
> déchiffré par stunnel:
Alors là , ça m'intéresse beaucoup. Je me suis dit que j'al lais perdre
ces fonctionnalités :-(
> ssh -> proxytunnel -e --------ssh/ssl------> stunnel ---ssh---> sslh
> --> sshd
>
> navigateur --------http/ssl------> stunnel ---http---> sslh -->
> http:80
>
> Rien de tout ça n'est testé :-)
Je vais le faire ;-)... ce week-end...
> > Rien de tout ça n'est testé :-)
>
> Je vais le faire ;-)... ce week-end...
Bon, finalement, je viens de tester et ça ne marche pas :-(
Dommage... Je vais perdre cette fonctionnalité...
Yves, si jamais tu as un peu de temps, une nouvelle version de sslh
compatible avec stunnel m'intéresserait beaucoup ;-)
> > Rien de tout ça n'est testé :-)
>
> Je vais le faire ;-)... ce week-end...
Bon, finalement, je viens de tester et ça ne marche pas :-(
Dommage... Je vais perdre cette fonctionnalité...
Yves, si jamais tu as un peu de temps, une nouvelle version de sslh
compatible avec stunnel m'intéresserait beaucoup ;-)
> > Rien de tout ça n'est testé :-)
>
> Je vais le faire ;-)... ce week-end...
Bon, finalement, je viens de tester et ça ne marche pas :-(
Dommage... Je vais perdre cette fonctionnalité...
Yves, si jamais tu as un peu de temps, une nouvelle version de sslh
compatible avec stunnel m'intéresserait beaucoup ;-)
Avec un sslh non modifié, et stunnel3, je fais:
stunnel -f -p moncert.pem -d thelonious:443 -l /usr/local/sbin/sslh
-- sslh -i -l localhost:80 -s localhost:22
et ça marche.
Pour sslh: -i l'appelle en mode inetd, -l redirige le "SSL"
(en fait du HTTP normal) vers Apache:80, et -s redirige le
SSH vers sshd:22. Ãa marche parceque sslh ne se base que sur
le fait que le client parle en moins de 2s pour rediriger
vers ce qui est spécifié avec -l, et HTTP et SSL on ça en
commun que le client parle en premier.
Voilà voilà . Les outils permettent bien de le faire.
Bonne chance,
Avec un sslh non modifié, et stunnel3, je fais:
stunnel -f -p moncert.pem -d thelonious:443 -l /usr/local/sbin/sslh
-- sslh -i -l localhost:80 -s localhost:22
et ça marche.
Pour sslh: -i l'appelle en mode inetd, -l redirige le "SSL"
(en fait du HTTP normal) vers Apache:80, et -s redirige le
SSH vers sshd:22. Ãa marche parceque sslh ne se base que sur
le fait que le client parle en moins de 2s pour rediriger
vers ce qui est spécifié avec -l, et HTTP et SSL on ça en
commun que le client parle en premier.
Voilà voilà . Les outils permettent bien de le faire.
Bonne chance,
Avec un sslh non modifié, et stunnel3, je fais:
stunnel -f -p moncert.pem -d thelonious:443 -l /usr/local/sbin/sslh
-- sslh -i -l localhost:80 -s localhost:22
et ça marche.
Pour sslh: -i l'appelle en mode inetd, -l redirige le "SSL"
(en fait du HTTP normal) vers Apache:80, et -s redirige le
SSH vers sshd:22. Ãa marche parceque sslh ne se base que sur
le fait que le client parle en moins de 2s pour rediriger
vers ce qui est spécifié avec -l, et HTTP et SSL on ça en
commun que le client parle en premier.
Voilà voilà . Les outils permettent bien de le faire.
Bonne chance,
Le Fri, 8 Oct 2010 15:44:59 +0200,
Yves Rutschle a écrit :Avec un sslh non modifié, et stunnel3, je fais:
stunnel -f -p moncert.pem -d thelonious:443 -l /usr/local/sbin/sslh
-- sslh -i -l localhost:80 -s localhost:22
et ça marche.
Pour sslh: -i l'appelle en mode inetd, -l redirige le "SSL"
(en fait du HTTP normal) vers Apache:80, et -s redirige le
SSH vers sshd:22. Ça marche parceque sslh ne se base que sur
le fait que le client parle en moins de 2s pour rediriger
vers ce qui est spécifié avec -l, et HTTP et SSL on ça en
commun que le client parle en premier.
Voilà voilà. Les outils permettent bien de le faire.
Bonne chance,
Je reviens à la charge car ça ne correspond pas "tout à fait" à ma
config ;-)
En effet, le test que tu as fait concerne du HTTP et pas du HTTPS vers
Apache. Or, mon souhait est de faire du "VRAI" HTTPS.
Je m'explique... Je voudrais recevoir, sur le port 443, soit du SSH
encapsulé dans du SSL, soit du HTTPS.
C'est donc STunnel qui reçoit la requête. Là, il retire la couche SSL
(c'est son boulot) et transmet le nouveau flux vers SSLH. S'il s'agit,
à l'origine, d'un flux SSH encapsulé, ça marche. En revanche, s'il
s'agit de HTTPS, ça ne marche plus car il transfert à Apache du HTTP
car il a enlevé la couche SSL... Et là, dans mon navigateur, j'ai une
erreur du genre :
Your browser sent a request that this server could not understand.
Reason: You're speaking plain HTTP to an SSL-enabled server port.
Instead use the HTTPS scheme to access this URL, please.
Bon, tout ça est très logique mais je ne vois pas comment gérer, sur
mon serveur et sur le même port, du SSH encapsulé dans du SSL et du
HTTPS.
En effet, il faudrait que le flux ne soit décapsulé que s'il s'agit de
SSH, sauf que là, il faudrait que le serveur soit magicien ;-)
Bref, je n'ai pas de solution :-(
David.
Le Fri, 8 Oct 2010 15:44:59 +0200,
Yves Rutschle <debian.anti-spam@rutschle.net> a écrit :
Avec un sslh non modifié, et stunnel3, je fais:
stunnel -f -p moncert.pem -d thelonious:443 -l /usr/local/sbin/sslh
-- sslh -i -l localhost:80 -s localhost:22
et ça marche.
Pour sslh: -i l'appelle en mode inetd, -l redirige le "SSL"
(en fait du HTTP normal) vers Apache:80, et -s redirige le
SSH vers sshd:22. Ça marche parceque sslh ne se base que sur
le fait que le client parle en moins de 2s pour rediriger
vers ce qui est spécifié avec -l, et HTTP et SSL on ça en
commun que le client parle en premier.
Voilà voilà. Les outils permettent bien de le faire.
Bonne chance,
Je reviens à la charge car ça ne correspond pas "tout à fait" à ma
config ;-)
En effet, le test que tu as fait concerne du HTTP et pas du HTTPS vers
Apache. Or, mon souhait est de faire du "VRAI" HTTPS.
Je m'explique... Je voudrais recevoir, sur le port 443, soit du SSH
encapsulé dans du SSL, soit du HTTPS.
C'est donc STunnel qui reçoit la requête. Là, il retire la couche SSL
(c'est son boulot) et transmet le nouveau flux vers SSLH. S'il s'agit,
à l'origine, d'un flux SSH encapsulé, ça marche. En revanche, s'il
s'agit de HTTPS, ça ne marche plus car il transfert à Apache du HTTP
car il a enlevé la couche SSL... Et là, dans mon navigateur, j'ai une
erreur du genre :
Your browser sent a request that this server could not understand.
Reason: You're speaking plain HTTP to an SSL-enabled server port.
Instead use the HTTPS scheme to access this URL, please.
Bon, tout ça est très logique mais je ne vois pas comment gérer, sur
mon serveur et sur le même port, du SSH encapsulé dans du SSL et du
HTTPS.
En effet, il faudrait que le flux ne soit décapsulé que s'il s'agit de
SSH, sauf que là, il faudrait que le serveur soit magicien ;-)
Bref, je n'ai pas de solution :-(
David.
Le Fri, 8 Oct 2010 15:44:59 +0200,
Yves Rutschle a écrit :Avec un sslh non modifié, et stunnel3, je fais:
stunnel -f -p moncert.pem -d thelonious:443 -l /usr/local/sbin/sslh
-- sslh -i -l localhost:80 -s localhost:22
et ça marche.
Pour sslh: -i l'appelle en mode inetd, -l redirige le "SSL"
(en fait du HTTP normal) vers Apache:80, et -s redirige le
SSH vers sshd:22. Ça marche parceque sslh ne se base que sur
le fait que le client parle en moins de 2s pour rediriger
vers ce qui est spécifié avec -l, et HTTP et SSL on ça en
commun que le client parle en premier.
Voilà voilà. Les outils permettent bien de le faire.
Bonne chance,
Je reviens à la charge car ça ne correspond pas "tout à fait" à ma
config ;-)
En effet, le test que tu as fait concerne du HTTP et pas du HTTPS vers
Apache. Or, mon souhait est de faire du "VRAI" HTTPS.
Je m'explique... Je voudrais recevoir, sur le port 443, soit du SSH
encapsulé dans du SSL, soit du HTTPS.
C'est donc STunnel qui reçoit la requête. Là, il retire la couche SSL
(c'est son boulot) et transmet le nouveau flux vers SSLH. S'il s'agit,
à l'origine, d'un flux SSH encapsulé, ça marche. En revanche, s'il
s'agit de HTTPS, ça ne marche plus car il transfert à Apache du HTTP
car il a enlevé la couche SSL... Et là, dans mon navigateur, j'ai une
erreur du genre :
Your browser sent a request that this server could not understand.
Reason: You're speaking plain HTTP to an SSL-enabled server port.
Instead use the HTTPS scheme to access this URL, please.
Bon, tout ça est très logique mais je ne vois pas comment gérer, sur
mon serveur et sur le même port, du SSH encapsulé dans du SSL et du
HTTPS.
En effet, il faudrait que le flux ne soit décapsulé que s'il s'agit de
SSH, sauf que là, il faudrait que le serveur soit magicien ;-)
Bref, je n'ai pas de solution :-(
David.
Ton site en https, mets le en http sur un port quelconque en
n'autorisant que les connexions depuis localhost. stunnel s'occupe alors
de la partie SSL, et apache n'a plus à s'en occuper.
> En effet, le test que tu as fait concerne du HTTP et pas du HTTPS vers
> Apache. Or, mon souhait est de faire du "VRAI" HTTPS.
Ton site en https, mets le en http sur un port quelconque en
n'autorisant que les connexions depuis localhost. stunnel s'occupe alors
de la partie SSL, et apache n'a plus à s'en occuper.
> En effet, le test que tu as fait concerne du HTTP et pas du HTTPS vers
> Apache. Or, mon souhait est de faire du "VRAI" HTTPS.
Ton site en https, mets le en http sur un port quelconque en
n'autorisant que les connexions depuis localhost. stunnel s'occupe alors
de la partie SSL, et apache n'a plus à s'en occuper.
> En effet, le test que tu as fait concerne du HTTP et pas du HTTPS vers
> Apache. Or, mon souhait est de faire du "VRAI" HTTPS.
On Sun, Oct 10, 2010 at 10:33:17AM +0200, Erwan David wrote:
> Ton site en https, mets le en http sur un port quelconque en
> n'autorisant que les connexions depuis localhost. stunnel s'occupe
> alors de la partie SSL, et apache n'a plus à s'en occuper.
C'est exactement ça: en prenant, pour Apache, au hasard, le
port 80 :-)
> > En effet, le test que tu as fait concerne du HTTP et pas du HTTPS
> > vers Apache. Or, mon souhait est de faire du "VRAI" HTTPS.
Non, dans mon test ce qui transite "sur le fil" est du vrai
HTTPS: HTTPS, c'est littéralement du HTTP dans du SSL. Il
est exactement equivalent de faire:
Navigateur/https---------https--------> stunnel --http--> apache:80
ou:
Navigateur/https----------https-------> apache:443
La partie 'https' est identique.
Dans mon exemple, j'ai configuré le stunnel en réception
avec le certificat que j'utilise d'habitude pour apache, et
vu depuis le navigateur on n'y voit que du feu.
Pour faire ce que tu suggères, c'est à dire stunnel qui
décapsule puis qui forwarde vers HTTPS, il faudrait
encapsuler le HTTPS dans du SSL:
Navigateur/https-->stunnel-----https/ssl--------> stunnel --https-->
apache:443
Dans ce cas, ton serveur n'offre plus un service 'https'
mais 'https sur ssl', qui n'est plus compatible avec les
navigateurs.
Y.
On Sun, Oct 10, 2010 at 10:33:17AM +0200, Erwan David wrote:
> Ton site en https, mets le en http sur un port quelconque en
> n'autorisant que les connexions depuis localhost. stunnel s'occupe
> alors de la partie SSL, et apache n'a plus à s'en occuper.
C'est exactement ça: en prenant, pour Apache, au hasard, le
port 80 :-)
> > En effet, le test que tu as fait concerne du HTTP et pas du HTTPS
> > vers Apache. Or, mon souhait est de faire du "VRAI" HTTPS.
Non, dans mon test ce qui transite "sur le fil" est du vrai
HTTPS: HTTPS, c'est littéralement du HTTP dans du SSL. Il
est exactement equivalent de faire:
Navigateur/https---------https--------> stunnel --http--> apache:80
ou:
Navigateur/https----------https-------> apache:443
La partie 'https' est identique.
Dans mon exemple, j'ai configuré le stunnel en réception
avec le certificat que j'utilise d'habitude pour apache, et
vu depuis le navigateur on n'y voit que du feu.
Pour faire ce que tu suggères, c'est à dire stunnel qui
décapsule puis qui forwarde vers HTTPS, il faudrait
encapsuler le HTTPS dans du SSL:
Navigateur/https-->stunnel-----https/ssl--------> stunnel --https-->
apache:443
Dans ce cas, ton serveur n'offre plus un service 'https'
mais 'https sur ssl', qui n'est plus compatible avec les
navigateurs.
Y.
On Sun, Oct 10, 2010 at 10:33:17AM +0200, Erwan David wrote:
> Ton site en https, mets le en http sur un port quelconque en
> n'autorisant que les connexions depuis localhost. stunnel s'occupe
> alors de la partie SSL, et apache n'a plus à s'en occuper.
C'est exactement ça: en prenant, pour Apache, au hasard, le
port 80 :-)
> > En effet, le test que tu as fait concerne du HTTP et pas du HTTPS
> > vers Apache. Or, mon souhait est de faire du "VRAI" HTTPS.
Non, dans mon test ce qui transite "sur le fil" est du vrai
HTTPS: HTTPS, c'est littéralement du HTTP dans du SSL. Il
est exactement equivalent de faire:
Navigateur/https---------https--------> stunnel --http--> apache:80
ou:
Navigateur/https----------https-------> apache:443
La partie 'https' est identique.
Dans mon exemple, j'ai configuré le stunnel en réception
avec le certificat que j'utilise d'habitude pour apache, et
vu depuis le navigateur on n'y voit que du feu.
Pour faire ce que tu suggères, c'est à dire stunnel qui
décapsule puis qui forwarde vers HTTPS, il faudrait
encapsuler le HTTPS dans du SSL:
Navigateur/https-->stunnel-----https/ssl--------> stunnel --https-->
apache:443
Dans ce cas, ton serveur n'offre plus un service 'https'
mais 'https sur ssl', qui n'est plus compatible avec les
navigateurs.
Y.