Discussion:
Tunnel zonder inloggen
(te oud om op te antwoorden)
Paul van der Vlis
2011-04-04 07:40:25 UTC
Permalink
Hallo,

Om op een remote machine achter een firewall in te loggen is het handig
als de andere kant een tunnel opbouwt, zoiets:
ssh -R 11111:localhost:22 ***@server.vandervlis.nl

Nadeel daarvan is dat mensen daarmee ook binnenkomen op mijn machine,
terwijl alleen die tunnel maar nodig is.

Weet iemand ook een methode om een tunnel op te bouwen zonder dat men
daarna een prompt krijgt? Of een prompt die gewoon echt niks kan?

Met vriendelijke groet,
Paul van der Vlis.
--
http://www.vandervlis.nl/
richard lucassen
2011-04-04 08:28:10 UTC
Permalink
On Mon, 04 Apr 2011 09:40:25 +0200
Post by Paul van der Vlis
Om op een remote machine achter een firewall in te loggen is het
Nadeel daarvan is dat mensen daarmee ook binnenkomen op mijn machine,
terwijl alleen die tunnel maar nodig is.
Weet iemand ook een methode om een tunnel op te bouwen zonder dat men
daarna een prompt krijgt? Of een prompt die gewoon echt niks kan?
Openvpn? Je kunt ssh wel zo configgen dat je een shell krijgt waar je
niets mee kunt, maar als je vpn's wilt aanleggen dan is openvpn een
aanrader. Als je een openvpn server maakt (eenvoudig) en met certs
werkt wordt het zeer handelbaar. En werkt ook vanuit OSX en MS clients.

Dat iedereen nog zit te etteren met IPSEC, pptp, l2tp en dat soort zooi
is me soms wel eens een raadsel.
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+
Paul van der Vlis
2011-04-04 09:06:28 UTC
Permalink
Post by richard lucassen
On Mon, 04 Apr 2011 09:40:25 +0200
Post by Paul van der Vlis
Om op een remote machine achter een firewall in te loggen is het
Nadeel daarvan is dat mensen daarmee ook binnenkomen op mijn machine,
terwijl alleen die tunnel maar nodig is.
Weet iemand ook een methode om een tunnel op te bouwen zonder dat men
daarna een prompt krijgt? Of een prompt die gewoon echt niks kan?
Openvpn? Je kunt ssh wel zo configgen dat je een shell krijgt waar je
niets mee kunt, maar als je vpn's wilt aanleggen dan is openvpn een
aanrader. Als je een openvpn server maakt (eenvoudig) en met certs
werkt wordt het zeer handelbaar. En werkt ook vanuit OSX en MS clients.
Dat iedereen nog zit te etteren met IPSEC, pptp, l2tp en dat soort zooi
is me soms wel eens een raadsel.
Ik werk ook veel met openvpn. Het gaat me echter om mensen die ik verder
niet ken, en die vragen "kun je even kijken?" o.i.d.

Het is toch wat lastig om hen eerst te leren openvpn te installeren.
Een regeltje zoals bovenstaande copy/pasten gaat echter wel.


Groet,
Paul.
--
http://www.vandervlis.nl/
richard lucassen
2011-04-04 09:55:27 UTC
Permalink
On Mon, 04 Apr 2011 11:06:28 +0200
Post by Paul van der Vlis
Ik werk ook veel met openvpn. Het gaat me echter om mensen die ik
verder niet ken, en die vragen "kun je even kijken?" o.i.d.
Het is toch wat lastig om hen eerst te leren openvpn te installeren.
Een regeltje zoals bovenstaande copy/pasten gaat echter wel.
Maar als je de mensen niet kent, maar het zijn wel door jou geleverde
machines, waarom zet je dan poort 22 niet open vanaf jouw ip
83.160.123.102? Dan zet jij een verbinding op en niet zij.
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+
Paul van der Vlis
2011-04-04 11:07:36 UTC
Permalink
Post by richard lucassen
On Mon, 04 Apr 2011 11:06:28 +0200
Post by Paul van der Vlis
Ik werk ook veel met openvpn. Het gaat me echter om mensen die ik
verder niet ken, en die vragen "kun je even kijken?" o.i.d.
Het is toch wat lastig om hen eerst te leren openvpn te installeren.
Een regeltje zoals bovenstaande copy/pasten gaat echter wel.
Maar als je de mensen niet kent, maar het zijn wel door jou geleverde
machines, waarom zet je dan poort 22 niet open vanaf jouw ip
83.160.123.102? Dan zet jij een verbinding op en niet zij.
Het gaat om machines die niet door mij geleverd zijn (anders kom ik er
zo wel in natuurlijk), en om laptops die weer eens ergens anders staan.


Met vriendelijke groet,
Paul van der Vlis.
--
http://www.vandervlis.nl/
Stef
2011-04-04 11:24:03 UTC
Permalink
In nl.comp.os.linux.netwerken,
Post by Paul van der Vlis
Post by richard lucassen
On Mon, 04 Apr 2011 11:06:28 +0200
Post by Paul van der Vlis
Ik werk ook veel met openvpn. Het gaat me echter om mensen die ik
verder niet ken, en die vragen "kun je even kijken?" o.i.d.
Het is toch wat lastig om hen eerst te leren openvpn te installeren.
Een regeltje zoals bovenstaande copy/pasten gaat echter wel.
Maar als je de mensen niet kent, maar het zijn wel door jou geleverde
machines, waarom zet je dan poort 22 niet open vanaf jouw ip
83.160.123.102? Dan zet jij een verbinding op en niet zij.
Het gaat om machines die niet door mij geleverd zijn (anders kom ik er
zo wel in natuurlijk), en om laptops die weer eens ergens anders staan.
Is teamviewer geen optie voor je? Wij gebruiken het wel eens om even mee
te kijken en dat werkt er goed. Heb alleen ervaring met de W versie, maar
er is ook een linux versie.
--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

The rule on staying alive as a forecaster is to give 'em a number or
give 'em a date, but never give 'em both at once.
-- Jane Bryant Quinn
Paul van der Vlis
2011-04-04 11:31:54 UTC
Permalink
Post by Paul van der Vlis
Post by richard lucassen
On Mon, 04 Apr 2011 11:06:28 +0200
Post by Paul van der Vlis
Ik werk ook veel met openvpn. Het gaat me echter om mensen die ik
verder niet ken, en die vragen "kun je even kijken?" o.i.d.
Het is toch wat lastig om hen eerst te leren openvpn te installeren.
Een regeltje zoals bovenstaande copy/pasten gaat echter wel.
Maar als je de mensen niet kent, maar het zijn wel door jou geleverde
machines, waarom zet je dan poort 22 niet open vanaf jouw ip
83.160.123.102? Dan zet jij een verbinding op en niet zij.
Het gaat om machines die niet door mij geleverd zijn (anders kom ik er
zo wel in natuurlijk), en om laptops die weer eens ergens anders staan.
Nog een mooie reden: router was kapot, er is een nieuwe geplaatst maar
die is nog niet geconfigureerd.

Met vriendelijke groet,
Paul van der Vlis.
--
http://www.vandervlis.nl/
richard lucassen
2011-04-04 11:32:35 UTC
Permalink
On Mon, 04 Apr 2011 13:07:36 +0200
Post by Paul van der Vlis
Het gaat om machines die niet door mij geleverd zijn (anders kom ik er
zo wel in natuurlijk), en om laptops die weer eens ergens anders staan.
Linux machines? Als dat Linux dozen zijn dan is die ssh -R optie niet
eens zo gek. Maar dat soort fratsen haal ik zelden uit eigenlijk. Als
je inlogt met een key kun je dit in authorized_keys zetten:

from="1.2.3.4,12.13.14.15,23.24.25.26",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/home/user/script.sh",no-pty
ssh-rsa <key>

Maar dat is maar een voorbeeld van een paar opties met een key, maar
hoe dat met user/pass gaat weet ik niet, maar het lijkt me sterk dat dat
niet zou kunnen.
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+
Paul van der Vlis
2011-04-04 12:26:15 UTC
Permalink
Post by richard lucassen
On Mon, 04 Apr 2011 13:07:36 +0200
Post by Paul van der Vlis
Het gaat om machines die niet door mij geleverd zijn (anders kom ik er
zo wel in natuurlijk), en om laptops die weer eens ergens anders staan.
Linux machines?
Uiteraard.
Post by richard lucassen
Als dat Linux dozen zijn dan is die ssh -R optie niet
eens zo gek. Maar dat soort fratsen haal ik zelden uit eigenlijk. Als
from="1.2.3.4,12.13.14.15,23.24.25.26",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/home/user/script.sh",no-pty
ssh-rsa <key>
Maar dat is maar een voorbeeld van een paar opties met een key, maar
hoe dat met user/pass gaat weet ik niet, maar het lijkt me sterk dat dat
niet zou kunnen.
Ik doe het om eerlijk te zijn met sshpass, zoiets:
sshpass -psecret ssh -R 12345:localhost:22 ***@server.vandervlis.nl
Kunnen ze ook geen typefout in het paswoord maken.

Maar wat ik vervelend vind is dat ze dan een login hebben op mijn
machine. Dat vind ik vooral vervelend bij mensen die ik helemaal niet
ken. Dus ik zou ze graag een shell geven waarin ze gewoon niks kunnen.

Wat ik net vond is /bin/rbash, dat is een restricted bash. lijkt te
werken. Maar niet zeker of ik het restricted genoeg vind.

Met vriendelijke groet,
Paul van der Vlis.
--
http://www.vandervlis.nl/
Fred Mobach
2011-04-04 13:59:11 UTC
Permalink
Paul van der Vlis wrote:

<<beperkte inlogfunctie via ssh>>
Post by Paul van der Vlis
Maar wat ik vervelend vind is dat ze dan een login hebben op mijn
machine. Dat vind ik vooral vervelend bij mensen die ik helemaal niet
ken. Dus ik zou ze graag een shell geven waarin ze gewoon niks kunnen.
In de nieuwsgroep comp.security.ssh heb ik dit soort vragen vaker langs
zien komen, maar het aantal mogelijke beperkingen is vrij beperkt.
Voornamelijk omdat het aantal ontsnappingsmogelijkheden zo groot is.
--
Fred Mobach
website : https://fred.mobach.nl
.... In God we trust ....
.. The rest we monitor ..
Paul van der Vlis
2011-04-04 18:01:25 UTC
Permalink
Post by Fred Mobach
<<beperkte inlogfunctie via ssh>>
Post by Paul van der Vlis
Maar wat ik vervelend vind is dat ze dan een login hebben op mijn
machine. Dat vind ik vooral vervelend bij mensen die ik helemaal niet
ken. Dus ik zou ze graag een shell geven waarin ze gewoon niks kunnen.
In de nieuwsgroep comp.security.ssh heb ik dit soort vragen vaker langs
zien komen, maar het aantal mogelijke beperkingen is vrij beperkt.
Voornamelijk omdat het aantal ontsnappingsmogelijkheden zo groot is.
Als er een shell toegewezen is, lijkt het me toch geen zaak meer van ssh.

Een shell maken die op elk commando "forbidden" antwoord, lijkt me zo in
eerste instantie niet heel moeilijk. Welke ontsnappingsmogelijkheden zie
je dan?

Weet je of SSH een shell nodig heeft om een tunnel op te kunnen bouwen?
Het lijkt me dat SSH dat zelf doet.

Met vriendelijke groet,
Paul van der Vlis.
--
http://www.vandervlis.nl/
Philip Paeps
2011-04-04 21:03:34 UTC
Permalink
Post by Paul van der Vlis
Post by Fred Mobach
<<beperkte inlogfunctie via ssh>>
Post by Paul van der Vlis
Maar wat ik vervelend vind is dat ze dan een login hebben op mijn
machine. Dat vind ik vooral vervelend bij mensen die ik helemaal niet
ken. Dus ik zou ze graag een shell geven waarin ze gewoon niks kunnen.
In de nieuwsgroep comp.security.ssh heb ik dit soort vragen vaker langs
zien komen, maar het aantal mogelijke beperkingen is vrij beperkt.
Voornamelijk omdat het aantal ontsnappingsmogelijkheden zo groot is.
Als er een shell toegewezen is, lijkt het me toch geen zaak meer van ssh.
Een shell maken die op elk commando "forbidden" antwoord, lijkt me zo in
eerste instantie niet heel moeilijk. Welke ontsnappingsmogelijkheden zie
je dan?
Dat heet /usr/sbin/nologin.
Post by Paul van der Vlis
Weet je of SSH een shell nodig heeft om een tunnel op te kunnen bouwen?
Het lijkt me dat SSH dat zelf doet.
Kijk even naar de -N en -f vlaggen in de ssh(1) manual page.

Of probeer gewoon eens ssh -q -N -f -L ...

Het verbaast me echt dat je hier over gelezen hebt. Mijn Debian shipt wel
degelijk alle handleidingen bij ssh. Draai jij een distributie die dat niet
doet?

- Philip
--
Philip Paeps Please don't email any replies
***@paeps.cx I follow the newsgroup.
Paul van der Vlis
2011-04-05 07:35:26 UTC
Permalink
Post by Philip Paeps
Post by Paul van der Vlis
Post by Fred Mobach
<<beperkte inlogfunctie via ssh>>
Post by Paul van der Vlis
Maar wat ik vervelend vind is dat ze dan een login hebben op mijn
machine. Dat vind ik vooral vervelend bij mensen die ik helemaal niet
ken. Dus ik zou ze graag een shell geven waarin ze gewoon niks kunnen.
In de nieuwsgroep comp.security.ssh heb ik dit soort vragen vaker langs
zien komen, maar het aantal mogelijke beperkingen is vrij beperkt.
Voornamelijk omdat het aantal ontsnappingsmogelijkheden zo groot is.
Als er een shell toegewezen is, lijkt het me toch geen zaak meer van ssh.
Een shell maken die op elk commando "forbidden" antwoord, lijkt me zo in
eerste instantie niet heel moeilijk. Welke ontsnappingsmogelijkheden zie
je dan?
Dat heet /usr/sbin/nologin.
Voor zover ik weet krijg je geen tunnel zonder login.
Post by Philip Paeps
Post by Paul van der Vlis
Weet je of SSH een shell nodig heeft om een tunnel op te kunnen bouwen?
Het lijkt me dat SSH dat zelf doet.
Kijk even naar de -N en -f vlaggen in de ssh(1) manual page.
Of probeer gewoon eens ssh -q -N -f -L ...
Het verbaast me echt dat je hier over gelezen hebt. Mijn Debian shipt wel
degelijk alle handleidingen bij ssh. Draai jij een distributie die dat niet
doet?
Wellicht stel ik wat gemakkelijk vragen, ik geef toe dat ik wat lui ben.
En nee, ik zou niet zo snel denken aan opties in de client om de server
te beschermen.

Maar... blijkbaar kun je toch een tunnel krijgen zonder login!
Die -N optie doet het, dan kun je inderdaad kiezen voor
/usr/sbin/nologin op de server.

Bedankt, dit is inderdaad een uistekende oplossing.

Wat ik de klant vraag te doen is dit:
ssh -NR 12345:localhost:22 ***@server.vandervlis.nl &

Daarna kan ik bij klant naar binnen fietsen met dit:
ssh ***@localhost -o "StrictHostKeyChecking no" -p 12345

De user welkom heeft "/usr/bin/nologin" als shell, en kan er dus niet in.

Nu misschien nog wat studeren op een paswoordloze login, het zou mooi
zijn als ik "permitemptypasswords" op "yes" zou kunnen zetten voor
alleen deze user o.i.d. Er lijken een boel haken en ogen aan te zitten.

Met vriendelijke groet,
Paul van der Vlis.
--
http://www.vandervlis.nl/
Philip Paeps
2011-04-05 13:18:36 UTC
Permalink
Post by Paul van der Vlis
Post by Philip Paeps
Post by Paul van der Vlis
Post by Fred Mobach
<<beperkte inlogfunctie via ssh>>
Post by Paul van der Vlis
Maar wat ik vervelend vind is dat ze dan een login hebben op mijn
machine. Dat vind ik vooral vervelend bij mensen die ik helemaal niet
ken. Dus ik zou ze graag een shell geven waarin ze gewoon niks kunnen.
In de nieuwsgroep comp.security.ssh heb ik dit soort vragen vaker langs
zien komen, maar het aantal mogelijke beperkingen is vrij beperkt.
Voornamelijk omdat het aantal ontsnappingsmogelijkheden zo groot is.
Als er een shell toegewezen is, lijkt het me toch geen zaak meer van ssh.
Een shell maken die op elk commando "forbidden" antwoord, lijkt me zo in
eerste instantie niet heel moeilijk. Welke ontsnappingsmogelijkheden zie
je dan?
Dat heet /usr/sbin/nologin.
Voor zover ik weet krijg je geen tunnel zonder login.
Als wat jij "login" noemt een shell omvat, heb je het fout.

Tunnels liggen tussen ssh en sshd. Een shell wordt pas na het inloggen
geforkt. Je hoeft helemaal geen shell te forken om een ssh connectie in
leven te houden.
Post by Paul van der Vlis
Post by Philip Paeps
Post by Paul van der Vlis
Weet je of SSH een shell nodig heeft om een tunnel op te kunnen bouwen?
Het lijkt me dat SSH dat zelf doet.
Kijk even naar de -N en -f vlaggen in de ssh(1) manual page.
Of probeer gewoon eens ssh -q -N -f -L ...
Het verbaast me echt dat je hier over gelezen hebt. Mijn Debian shipt wel
degelijk alle handleidingen bij ssh. Draai jij een distributie die dat
niet doet?
Wellicht stel ik wat gemakkelijk vragen, ik geef toe dat ik wat lui ben.
En nee, ik zou niet zo snel denken aan opties in de client om de server
te beschermen.
Waartegen wil je de server beschermen? Je wil niet dat clients willekeurige
commando's op je server kunnen draaien. Daarom zet je hun shell op "nologin".
Default gedrag van ssh is te proberen om een shell te forken op de server.
Lukt dat niet, breekt de connectie af. Je wil niet dat de connectie wordt
afgebroken want je hebt een tunnel nodig. Ergo: je hebt een client optie
nodig om de connectie niet af te breken omdat ze geen shell kunnen forken.
Post by Paul van der Vlis
Maar... blijkbaar kun je toch een tunnel krijgen zonder login!
Neen. Je kunt geen tunnel krijgen zonder login. Je kunt een tunnel krijgen
zonder shell. Een shell impliceert login. Een login impliceert niet
vanzelfsprekend een shell.
Post by Paul van der Vlis
Die -N optie doet het, dan kun je inderdaad kiezen voor
/usr/sbin/nologin op de server.
Bedankt, dit is inderdaad een uistekende oplossing.
Graag gedaan. :-)
Je zou NoHostAuthenticationForLocalhost kunnen gebruiken. Dat zet ik
doorgaans standaard op "yes" in mijn .ssh/config.
Post by Paul van der Vlis
De user welkom heeft "/usr/bin/nologin" als shell, en kan er dus niet in.
Wel, hij kan er wel in, anders zou de tunnel niet werken. Hij heeft gewoon
geen functionele shell en kan dus niets op de machine uitvreten.

Als je public keys zou gebruiken in plaats van paswoorden, zou je command= in
je authorized_keys kunnen opnemen. Dan zou er zelfs geen shell geforkt worden
(ook nologin niet), en zouden hypothetische bugs in nologin ook geen probleem
zijn (die zijn er ooit geweest).
Post by Paul van der Vlis
Nu misschien nog wat studeren op een paswoordloze login, het zou mooi zijn
als ik "permitemptypasswords" op "yes" zou kunnen zetten voor alleen deze
user o.i.d. Er lijken een boel haken en ogen aan te zitten.
Het lijkt me bijzonder onverstandig om een willekeurige user vanop een
willekeurige plaats zonder enige vorm van authenticatie te laten tunnelen
door jouw machine.

Ik zou in ieder geval ook een _uitgaande_ firewall op jouw machine zetten.
Tenzij je het leuk zou vinden moest een van je creatieve klanten (of een
aanvaller die het paswoord raadt) een SOCKS tunnel opzetten door jouw machine
en er de rest van het internet mee lastig zou vallen. Of tenzij je zin hebt
om een open proxy te worden voor allerlei ongein?

- Philip
--
Philip Paeps Please don't email any replies
***@paeps.cx I follow the newsgroup.
Paul van der Vlis
2011-04-05 20:34:18 UTC
Permalink
Post by Philip Paeps
Tunnels liggen tussen ssh en sshd. Een shell wordt pas na het inloggen
geforkt. Je hoeft helemaal geen shell te forken om een ssh connectie in
leven te houden.
Dat wist ik nog niet, maar ik vond het inderdaad ook onnodig.
Post by Philip Paeps
Waartegen wil je de server beschermen? Je wil niet dat clients willekeurige
commando's op je server kunnen draaien. Daarom zet je hun shell op "nologin".
Default gedrag van ssh is te proberen om een shell te forken op de server.
Lukt dat niet, breekt de connectie af. Je wil niet dat de connectie wordt
afgebroken want je hebt een tunnel nodig. Ergo: je hebt een client optie
nodig om de connectie niet af te breken omdat ze geen shell kunnen forken.
Ik was op zoek naar een andere shell, want ik kon geen tunnel opbouwen
met "nologin" of "false" o.i.d.
Post by Philip Paeps
Post by Paul van der Vlis
Maar... blijkbaar kun je toch een tunnel krijgen zonder login!
Neen. Je kunt geen tunnel krijgen zonder login. Je kunt een tunnel krijgen
zonder shell. Een shell impliceert login. Een login impliceert niet
vanzelfsprekend een shell.
Bedankt voor je uitleg.
Post by Philip Paeps
Je zou NoHostAuthenticationForLocalhost kunnen gebruiken. Dat zet ik
doorgaans standaard op "yes" in mijn .ssh/config.
Oh, dat is nog een leuke.
Post by Philip Paeps
Post by Paul van der Vlis
De user welkom heeft "/usr/bin/nologin" als shell, en kan er dus niet in.
Wel, hij kan er wel in, anders zou de tunnel niet werken. Hij heeft gewoon
geen functionele shell en kan dus niets op de machine uitvreten.
Als je public keys zou gebruiken in plaats van paswoorden, zou je command= in
je authorized_keys kunnen opnemen. Dan zou er zelfs geen shell geforkt worden
(ook nologin niet), en zouden hypothetische bugs in nologin ook geen probleem
zijn (die zijn er ooit geweest).
Post by Paul van der Vlis
Nu misschien nog wat studeren op een paswoordloze login, het zou mooi zijn
als ik "permitemptypasswords" op "yes" zou kunnen zetten voor alleen deze
user o.i.d. Er lijken een boel haken en ogen aan te zitten.
Het lijkt me bijzonder onverstandig om een willekeurige user vanop een
willekeurige plaats zonder enige vorm van authenticatie te laten tunnelen
door jouw machine.
Wat voor gevaar zie je in een tunnel naar (en dus niet 'door') mijn
machine zonder shell?
Post by Philip Paeps
Ik zou in ieder geval ook een _uitgaande_ firewall op jouw machine zetten.
Tenzij je het leuk zou vinden moest een van je creatieve klanten (of een
aanvaller die het paswoord raadt) een SOCKS tunnel opzetten door jouw machine
en er de rest van het internet mee lastig zou vallen. Of tenzij je zin hebt
om een open proxy te worden voor allerlei ongein?
Ik zie nog niet hoe een creatieve klant een proxy zou kunnen opzetten
zonder shell. Maar ik kan me vergissen.

Met vriendelijke groet,
Paul van der Vlis.
--
http://www.vandervlis.nl/
Philip Paeps
2011-04-06 09:03:51 UTC
Permalink
Post by Philip Paeps
Post by Paul van der Vlis
Nu misschien nog wat studeren op een paswoordloze login, het zou mooi zijn
als ik "permitemptypasswords" op "yes" zou kunnen zetten voor alleen deze
user o.i.d. Er lijken een boel haken en ogen aan te zitten.
Het lijkt me bijzonder onverstandig om een willekeurige user vanop een
willekeurige plaats zonder enige vorm van authenticatie te laten tunnelen
door jouw machine.
Wat voor gevaar zie je in een tunnel naar (en dus niet 'door') mijn machine
zonder shell?
Als je geen uitgaande packet filter hebt, impliceert een tunnel 'naar' zo goed
als zeker een tunnel 'door'.
Post by Philip Paeps
Ik zou in ieder geval ook een _uitgaande_ firewall op jouw machine zetten.
Tenzij je het leuk zou vinden moest een van je creatieve klanten (of een
aanvaller die het paswoord raadt) een SOCKS tunnel opzetten door jouw
machine en er de rest van het internet mee lastig zou vallen. Of tenzij je
zin hebt om een open proxy te worden voor allerlei ongein?
Ik zie nog niet hoe een creatieve klant een proxy zou kunnen opzetten zonder
shell. Maar ik kan me vergissen.
Meest generiek:

% ssh -D 1080 ***@server.vandervlis.nl

Meer specifiek:

% ssh -L 1234:ergens.anders.example.net:1234 ***@server.vandervlis.nl

Geen shells voor nodig.

- Philip
--
Philip Paeps Please don't email any replies
***@paeps.cx I follow the newsgroup.

He who dies with the most toys wins.
Paul van der Vlis
2011-04-10 13:35:04 UTC
Permalink
Post by Philip Paeps
Post by Philip Paeps
Post by Paul van der Vlis
Nu misschien nog wat studeren op een paswoordloze login, het zou mooi zijn
als ik "permitemptypasswords" op "yes" zou kunnen zetten voor alleen deze
user o.i.d. Er lijken een boel haken en ogen aan te zitten.
Het lijkt me bijzonder onverstandig om een willekeurige user vanop een
willekeurige plaats zonder enige vorm van authenticatie te laten tunnelen
door jouw machine.
Wat voor gevaar zie je in een tunnel naar (en dus niet 'door') mijn machine
zonder shell?
Als je geen uitgaande packet filter hebt, impliceert een tunnel 'naar' zo goed
als zeker een tunnel 'door'.
Post by Philip Paeps
Ik zou in ieder geval ook een _uitgaande_ firewall op jouw machine zetten.
Tenzij je het leuk zou vinden moest een van je creatieve klanten (of een
aanvaller die het paswoord raadt) een SOCKS tunnel opzetten door jouw
machine en er de rest van het internet mee lastig zou vallen. Of tenzij je
zin hebt om een open proxy te worden voor allerlei ongein?
Ik zie nog niet hoe een creatieve klant een proxy zou kunnen opzetten zonder
shell. Maar ik kan me vergissen.
Geen shells voor nodig.
Bedankt voor je informatie. Ik ben er nog niet toe gekomen om het goed
te testen, maar waarschijnlijk heb je gelijk.


Met vriendelijke groet,
Paul van der Vlis.
--
http://www.vandervlis.nl/
Fred Mobach
2011-04-04 09:16:51 UTC
Permalink
Post by richard lucassen
Dat iedereen nog zit te etteren met IPSEC, pptp, l2tp en dat soort
zooi is me soms wel eens een raadsel.
Laat me trachten je daarover te informeren. Zowel OpenVPN als IPSec
gebruik ik al jaren. OpenVPN werkt prima voor het verbinden van clients
met nertwerken, maar voor het verbinden van netwerken met 24x7
ondersteuning heeft IPSec mijn voorkeur.

Qua configuratiebestanden e.d. zie ik geen verschil, ze worden
gegenereerd.
--
Fred Mobach
website : https://fred.mobach.nl
.... In God we trust ....
.. The rest we monitor ..
richard lucassen
2011-04-04 09:52:07 UTC
Permalink
On Mon, 04 Apr 2011 11:16:51 +0200
Post by Fred Mobach
Post by richard lucassen
Dat iedereen nog zit te etteren met IPSEC, pptp, l2tp en dat soort
zooi is me soms wel eens een raadsel.
Laat me trachten je daarover te informeren. Zowel OpenVPN als IPSec
gebruik ik al jaren. OpenVPN werkt prima voor het verbinden van
clients met nertwerken, maar voor het verbinden van netwerken met 24x7
ondersteuning heeft IPSec mijn voorkeur.
Ik ben benieuwd naar je argumenten. Ik gebruik al jaren OpenVPN voor
network-network implementatie en dat is erg stabiel. Ik heb ergens al
jaren een OpenVPN server al jaren draaien die 87 netwerken bedient. Ik
draai ook IPSEC op een aantal plaatsen, dat is ook stabiel (als het
werkt) maar ik ben er niet van gecharmeerd.
Post by Fred Mobach
Qua configuratiebestanden e.d. zie ik geen verschil, ze worden
gegenereerd.
Heel leuk en academisch protocol dat van ipv6 gebackporte IPSEC, maar
wee je gebeente als je verschillende apparatuur hebt die het niet eens
kunnen worden, dan heb je een probleem.

En wat ik vervelend vind van de Linux kernel implementatie is dat je
geen losse interface van de tunnel(s) hebt en dat het ook niet
zichtbaar is in de route-tabellen. Niet onoverkomelijk, maar wel
vervelend.

R.
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+
Fred Mobach
2011-04-04 11:41:45 UTC
Permalink
Post by richard lucassen
On Mon, 04 Apr 2011 11:16:51 +0200
Post by Fred Mobach
Post by richard lucassen
Dat iedereen nog zit te etteren met IPSEC, pptp, l2tp en dat soort
zooi is me soms wel eens een raadsel.
Laat me trachten je daarover te informeren. Zowel OpenVPN als IPSec
gebruik ik al jaren. OpenVPN werkt prima voor het verbinden van
clients met nertwerken, maar voor het verbinden van netwerken met
24x7 ondersteuning heeft IPSec mijn voorkeur.
Ik ben benieuwd naar je argumenten. Ik gebruik al jaren OpenVPN voor
network-network implementatie en dat is erg stabiel. Ik heb ergens al
jaren een OpenVPN server al jaren draaien die 87 netwerken bedient. Ik
draai ook IPSEC op een aantal plaatsen, dat is ook stabiel (als het
werkt) maar ik ben er niet van gecharmeerd.
Al 12 jaar lang heb ik geen problemen met onbemande remote IPSec
servers, waarbij we zelf beide eindpunten beheren. Bij OpenVPN gaat dat
meestal wel goed, maar je kunt een probleem hebben met een te oud
certificaat. En dat betekent nog wel eens te moeten reizen, hetwelk
hier geldt als zonde.
Post by richard lucassen
Post by Fred Mobach
Qua configuratiebestanden e.d. zie ik geen verschil, ze worden
gegenereerd.
Heel leuk en academisch protocol dat van ipv6 gebackporte IPSEC, maar
wee je gebeente als je verschillende apparatuur hebt die het niet eens
kunnen worden, dan heb je een probleem.
Omdat we gemeenlijk beide eindpunten controleren hebben we dat probleem
niet. En systemen met alleen ondersteuning voor shared secrets wilden
we toch al niet.
--
Fred Mobach
website : https://fred.mobach.nl
.... In God we trust ....
.. The rest we monitor ..
richard lucassen
2011-04-04 12:06:10 UTC
Permalink
On Mon, 04 Apr 2011 13:41:45 +0200
Post by Fred Mobach
Post by richard lucassen
Ik ben benieuwd naar je argumenten. Ik gebruik al jaren OpenVPN voor
network-network implementatie en dat is erg stabiel. Ik heb ergens
al jaren een OpenVPN server al jaren draaien die 87 netwerken
bedient. Ik draai ook IPSEC op een aantal plaatsen, dat is ook
stabiel (als het werkt) maar ik ben er niet van gecharmeerd.
Al 12 jaar lang heb ik geen problemen met onbemande remote IPSec
servers, waarbij we zelf beide eindpunten beheren. Bij OpenVPN gaat
dat meestal wel goed, maar je kunt een probleem hebben met een te oud
certificaat. En dat betekent nog wel eens te moeten reizen, hetwelk
hier geldt als zonde.
Ik kan er altijd bij om certs te vervangen via ssh. Kennelijk heb jij
dat niet, dat vind ik wel vreemd eigenlijk...

Maar als je niet beide eindpunten beheert kan IPSEC wel eens lastig
zijn, vooral als "de overkant" een next-next-ok-finish niveau heeft.
Post by Fred Mobach
Post by richard lucassen
Heel leuk en academisch protocol dat van ipv6 gebackporte IPSEC,
maar wee je gebeente als je verschillende apparatuur hebt die het
niet eens kunnen worden, dan heb je een probleem.
Omdat we gemeenlijk beide eindpunten controleren hebben we dat
probleem niet. En systemen met alleen ondersteuning voor shared
secrets wilden we toch al niet.
Ook bij IPSEC kunnen certs verlopen ;-)

R.
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+
Fred Mobach
2011-04-04 14:02:56 UTC
Permalink
Post by richard lucassen
On Mon, 04 Apr 2011 13:41:45 +0200
Post by Fred Mobach
Post by richard lucassen
Ik ben benieuwd naar je argumenten. Ik gebruik al jaren OpenVPN
voor network-network implementatie en dat is erg stabiel. Ik heb
ergens al jaren een OpenVPN server al jaren draaien die 87
netwerken bedient. Ik draai ook IPSEC op een aantal plaatsen, dat
is ook stabiel (als het werkt) maar ik ben er niet van gecharmeerd.
Al 12 jaar lang heb ik geen problemen met onbemande remote IPSec
servers, waarbij we zelf beide eindpunten beheren. Bij OpenVPN gaat
dat meestal wel goed, maar je kunt een probleem hebben met een te oud
certificaat. En dat betekent nog wel eens te moeten reizen, hetwelk
hier geldt als zonde.
Ik kan er altijd bij om certs te vervangen via ssh. Kennelijk heb jij
dat niet, dat vind ik wel vreemd eigenlijk...
Maar als je niet beide eindpunten beheert kan IPSEC wel eens lastig
zijn, vooral als "de overkant" een next-next-ok-finish niveau heeft.
SSH wordt lastig als de andere kant achter een erg goedkoop routertje
zit van een niet zo heel goede (consumenten) ISP met allemaal
dynamische IP adressen. Oftewel, beheerstechnisch gezien een
nachtmerrie.
Post by richard lucassen
Post by Fred Mobach
Post by richard lucassen
Heel leuk en academisch protocol dat van ipv6 gebackporte IPSEC,
maar wee je gebeente als je verschillende apparatuur hebt die het
niet eens kunnen worden, dan heb je een probleem.
Omdat we gemeenlijk beide eindpunten controleren hebben we dat
probleem niet. En systemen met alleen ondersteuning voor shared
secrets wilden we toch al niet.
Ook bij IPSEC kunnen certs verlopen ;-)
Ik beperk me bij IPSec tot zelf gegenereerde keys. :-)
--
Fred Mobach
website : https://fred.mobach.nl
.... In God we trust ....
.. The rest we monitor ..
Paul van der Vlis
2011-04-04 11:30:34 UTC
Permalink
Post by richard lucassen
Je kunt ssh wel zo configgen dat je een shell krijgt waar je
niets mee kunt,
Dat is dus wat wou. En er hoeft dus echt niets te kunnen, anders dan wat
er misschien nodig is voor het aanmaken van de tunnel.

Via die tunnel fiets ik weer bij hen naar binnen.

Met vriendelijke groet,
Paul van der Vlis.
--
http://www.vandervlis.nl/
Philip Paeps
2011-04-04 15:31:07 UTC
Permalink
Post by Paul van der Vlis
Om op een remote machine achter een firewall in te loggen is het handig
Nadeel daarvan is dat mensen daarmee ook binnenkomen op mijn machine,
terwijl alleen die tunnel maar nodig is.
Weet iemand ook een methode om een tunnel op te bouwen zonder dat men
daarna een prompt krijgt? Of een prompt die gewoon echt niks kan?
Heb je in de sshd(8) manual al eens gekeken naar het formaat van de
authorized_keys file? Specifiek de "command=" parameter?

- Philip
--
Philip Paeps Please don't email any replies
***@paeps.cx I follow the newsgroup.
Paul van der Vlis
2011-04-04 17:37:40 UTC
Permalink
Post by Philip Paeps
Post by Paul van der Vlis
Om op een remote machine achter een firewall in te loggen is het handig
Nadeel daarvan is dat mensen daarmee ook binnenkomen op mijn machine,
terwijl alleen die tunnel maar nodig is.
Weet iemand ook een methode om een tunnel op te bouwen zonder dat men
daarna een prompt krijgt? Of een prompt die gewoon echt niks kan?
Heb je in de sshd(8) manual al eens gekeken naar het formaat van de
authorized_keys file? Specifiek de "command=" parameter?
Ja, heb ik wel eens mee te maken gehad. Maar in dit geval gaat het niet
om een authorized_key maar om paswoordauthenticatie, en dan werkt dat
volgens mij niet. Maar wel iets om in mijn achterhoofd te houden mocht
ik er misschien toch nog eens authorisatie met een key van maken.

Met vriendelijke groet,
Paul van der Vlis.
--
http://www.vandervlis.nl/
Philip Paeps
2011-04-04 20:57:04 UTC
Permalink
Post by Philip Paeps
Post by Paul van der Vlis
Om op een remote machine achter een firewall in te loggen is het handig
Nadeel daarvan is dat mensen daarmee ook binnenkomen op mijn machine,
terwijl alleen die tunnel maar nodig is.
Weet iemand ook een methode om een tunnel op te bouwen zonder dat men
daarna een prompt krijgt? Of een prompt die gewoon echt niks kan?
Heb je in de sshd(8) manual al eens gekeken naar het formaat van de
authorized_keys file? Specifiek de "command=" parameter?
Ja, heb ik wel eens mee te maken gehad. Maar in dit geval gaat het niet om
een authorized_key maar om paswoordauthenticatie, en dan werkt dat volgens
mij niet.
Nee, met paswoorden werkt dat niet. Maar waarom zou je paswoorden gebruiken?
Vooral voor tunnels. Ik kan me bijvoorbeeld inbeelden dat je wil dat tunnels
terugkomen als iets de connectie breekt? Aangezien het een tunnel is, wil je
geen interactie vermoedelijk. Vooral aangezien tunnels de neiging hebben om
omver te vallen precies op het moment dat je echt geen interactie kan bieden.
Maar wel iets om in mijn achterhoofd te houden mocht ik er misschien toch
nog eens authorisatie met een key van maken.
Dat lijkt me een goed plan.

- Philip
--
Philip Paeps Please don't email any replies
***@paeps.cx I follow the newsgroup.
Paul van der Vlis
2011-04-05 07:00:34 UTC
Permalink
Post by Philip Paeps
Nee, met paswoorden werkt dat niet. Maar waarom zou je paswoorden gebruiken?
Vooral voor tunnels. Ik kan me bijvoorbeeld inbeelden dat je wil dat tunnels
terugkomen als iets de connectie breekt? Aangezien het een tunnel is, wil je
geen interactie vermoedelijk. Vooral aangezien tunnels de neiging hebben om
omver te vallen precies op het moment dat je echt geen interactie kan bieden.
Wat ik graag wil is dat mensen een regel copy-pasten in hun terminal, en
dat ik dan (door een NAT firewall heen) bij hen naar binnen kan fietsen
via SSH. Ik kan namelijk niets inrichten zonder dat ik eerst toegang heb.

Keys hebben als nadeel dat je ze eerst moet downloaden en op de juiste
plek moet neerzetten e.d. Het is dan in elk geval geen regeltje meer.

Hmm, een optie is wellicht om van dat "regeltje" af te stappen en er
meerdere regels van te maken. Zoiets:
--------
if test ! -e ~/.ssh; then mkdir ~/.ssh; fi; cd ~/.ssh
wget http://vandervlis.nl/key; cat key >> authorized_keys
ssh -R 11111:localhost:22 ***@server.vandervlis.nl
--------

Met vriendelijke groet,
Paul van der Vlis.
--
http://www.vandervlis.nl/
Philip Paeps
2011-04-05 13:08:01 UTC
Permalink
Post by Philip Paeps
Nee, met paswoorden werkt dat niet. Maar waarom zou je paswoorden
gebruiken? Vooral voor tunnels. Ik kan me bijvoorbeeld inbeelden dat je
wil dat tunnels terugkomen als iets de connectie breekt? Aangezien het
een tunnel is, wil je geen interactie vermoedelijk. Vooral aangezien
tunnels de neiging hebben om omver te vallen precies op het moment dat je
echt geen interactie kan bieden.
Wat ik graag wil is dat mensen een regel copy-pasten in hun terminal, en dat
ik dan (door een NAT firewall heen) bij hen naar binnen kan fietsen via SSH.
Ik kan namelijk niets inrichten zonder dat ik eerst toegang heb.
Als jij de hardware/software oplevert, kan je zonder problemen ook private
keys op de juiste plaats zetten, zodat ze tunnels naar jou kunnen starten.
Keys hebben als nadeel dat je ze eerst moet downloaden en op de juiste
plek moet neerzetten e.d. Het is dan in elk geval geen regeltje meer.
Tenzij je ze bij het opleveren aanlevert.
Hmm, een optie is wellicht om van dat "regeltje" af te stappen en er
--------
if test ! -e ~/.ssh; then mkdir ~/.ssh; fi; cd ~/.ssh
wget http://vandervlis.nl/key; cat key >> authorized_keys
--------
Yikes!

Je hebt net je klant een tunnel laten leggen naar een willekeurige aanvaller
die over de triviale kennis beschikt om met DNS te knoeien.

o Hoe garandeer je dat de DNS het correcte antwoord voor
vandervlis.nl geeft

o Hoe garandeer je dat wget met de echte vandervlis.nl
praat en daar de juiste key afhaalt

Ik ontbreek in dit plaatje de out-of-band verificatie van de hostkeys van jouw
machine. Als je keys over HTTP afhaalt, wil je dat minstens over TLS (ook wel
eens "HTTPS" genoemd) tunnelen.

De enige manier waarop je er veilig en reproduceerbaar voor kan zorgen dat je
klanten eenvoudig een tunnel kunnen aanleggen naar een machine bij jou, is
door een keypair op te leveren bij de klant.

Als je het vermoeden hebt dat de klant gecompromitteerd is, kan je zijn public
key uit je keyring verwijderen. Of je kan ervoor zorgen dat de tunnel enkel
opgezet kan worden als jij er expliciet om vraagt (firewall rules).

Wat je zeker niet wil, is dat je klanten tunnels opzetten naar andere
machines. De enige manier dat je dat kan garanderen is host keys checken
en keys leveren.

- Philip
--
Philip Paeps Please don't email any replies
***@paeps.cx I follow the newsgroup.
Paul van der Vlis
2011-04-05 19:58:07 UTC
Permalink
Post by Philip Paeps
Post by Philip Paeps
Nee, met paswoorden werkt dat niet. Maar waarom zou je paswoorden
gebruiken? Vooral voor tunnels. Ik kan me bijvoorbeeld inbeelden dat je
wil dat tunnels terugkomen als iets de connectie breekt? Aangezien het
een tunnel is, wil je geen interactie vermoedelijk. Vooral aangezien
tunnels de neiging hebben om omver te vallen precies op het moment dat je
echt geen interactie kan bieden.
Wat ik graag wil is dat mensen een regel copy-pasten in hun terminal, en dat
ik dan (door een NAT firewall heen) bij hen naar binnen kan fietsen via SSH.
Ik kan namelijk niets inrichten zonder dat ik eerst toegang heb.
Als jij de hardware/software oplevert, kan je zonder problemen ook private
keys op de juiste plaats zetten, zodat ze tunnels naar jou kunnen starten.
Keys hebben als nadeel dat je ze eerst moet downloaden en op de juiste
plek moet neerzetten e.d. Het is dan in elk geval geen regeltje meer.
Tenzij je ze bij het opleveren aanlevert.
Ik heb die hardware/software niet geleverd. Ik ken heel de mensen niet.
Ze bellen op zoals "mijn wasmachine is kapot".
Post by Philip Paeps
Hmm, een optie is wellicht om van dat "regeltje" af te stappen en er
--------
if test ! -e ~/.ssh; then mkdir ~/.ssh; fi; cd ~/.ssh
wget http://vandervlis.nl/key; cat key >> authorized_keys
--------
Yikes!
Je hebt net je klant een tunnel laten leggen naar een willekeurige aanvaller
die over de triviale kennis beschikt om met DNS te knoeien.
o Hoe garandeer je dat de DNS het correcte antwoord voor
vandervlis.nl geeft
Een IP nummer is misschien iets beter. Maar je gaat wel ver, die man die
belde had problemen met zijn wifi. Ik wou even kijken wat voor chip hij
had, en of de hardware lock aan stond. Er was geen enkel vermoeden dat
er wat raars aan de hand was.
Post by Philip Paeps
o Hoe garandeer je dat wget met de echte vandervlis.nl
praat en daar de juiste key afhaalt
Ik ontbreek in dit plaatje de out-of-band verificatie van de hostkeys van jouw
machine. Als je keys over HTTP afhaalt, wil je dat minstens over TLS (ook wel
eens "HTTPS" genoemd) tunnelen.
Is inderdaad beter, iets om te onthouden.
Post by Philip Paeps
De enige manier waarop je er veilig en reproduceerbaar voor kan zorgen dat je
klanten eenvoudig een tunnel kunnen aanleggen naar een machine bij jou, is
door een keypair op te leveren bij de klant.
Als je het vermoeden hebt dat de klant gecompromitteerd is, kan je zijn public
key uit je keyring verwijderen. Of je kan ervoor zorgen dat de tunnel enkel
opgezet kan worden als jij er expliciet om vraagt (firewall rules).
Wat je zeker niet wil, is dat je klanten tunnels opzetten naar andere
machines. De enige manier dat je dat kan garanderen is host keys checken
en keys leveren.
Zoals ik al schreef gaat het om een oplossing voor het geval zoiets er
niet is. Denk b.v. ook aan een situatie waarin een machine alleen nog
wil booten met een CD.

Met vriendelijke groet,
Paul van der Vlis.
--
http://www.vandervlis.nl/
Martijn Lievaart
2011-04-14 06:11:04 UTC
Permalink
Post by Paul van der Vlis
Hallo,
Om op een remote machine achter een firewall in te loggen is het handig
als de andere kant een tunnel opbouwt, zoiets: ssh -R 11111:localhost:22
Nadeel daarvan is dat mensen daarmee ook binnenkomen op mijn machine,
terwijl alleen die tunnel maar nodig is.
Weet iemand ook een methode om een tunnel op te bouwen zonder dat men
daarna een prompt krijgt? Of een prompt die gewoon echt niks kan?
Shell op nologin of false zetten en ze de -n optie laten meegeven.

M4

Loading...