[OpenSSH] PermitUserEnvironment optie werkt niet?

[Verwijderd]

Ik ben bezig met het porten van een oud DOS (standalone) systeem naar Linux. Nu werkt dit allemaal prima tot nu toe, en de uiteindelijke bedoeling word dat het hele geintje over SSH gaat draaien. (doet het nu al eigenlijk).

Nu moet iedere client een uniek poortnummer aan de SSH server geven zodra deze ingelogged is. (waarom kan ik niet precies uitleggen, te lang en complex verhaal). In ieder geval, dit wou ik dus doen aan de hand van Environment variables die geset worden op het moment dat de SSH client inlogged. Dit kan met de OpenSSH client door een file aan te maken die ~/.ssh/environment heet met daar je vars en values in. PuTTY kan dit ook (kan je instellen in de configuratie). Nu is het probleem dat de OpenSSH server weigerd de environment variable(s) te setten. Ik dus even de sshd_config doorgelopen of ik hier een instelling voor kon vinden. Veel gegoogled en kwam tot de conclusie dat de "PermitUserEnvironment" optie hier verantwoordelijk voor zou moeten zijn. Deze stond al op "yes", maar het werkt echter niet.. SSHD nog een keer geHUP'd om te kijken of ik em niet per ongeluk zelf op yes had gezet zonder te restarten, maar nee.. niets..

Ik loop hier nu al 4 a 5 uur mee te prutsen, dus ik dacht dat het tijd werd voor een draadje op twiekers hierover.

PS. ik heb het overigens op 3 machines getest.. overal hetzelfde

[Kees]

code:

     $HOME/.ssh/environment
             This file is read into the environment at login (if it exists).
             It can only contain empty lines, comment lines (that start with
             `#'), and assignment lines of the form name=value.  The file
             should be writable only by the user; it need not be readable by
             anyone else.  Environment processing is disabled by default and
             is controlled via the PermitUserEnvironment option.

Post je environment file eens?

[Verwijderd]

Het heeft niets met die file te maken. de server weigert gewoon de variablen te setten. die file is prima in orde

Ik sta nu op het punt om de OpenSSH source er maar bij te pakken om te kijken of ik kan uitvinden wat de oorzaak van dit hele probleem is. ik word er knettergek van!

[Verwijderd]

Probeer eens in te loggen (vanaf een unix bak) met ssh -vvv, dan zien we net ff wat meer debug output. Tevens, wat zijn de permisies op ~/.ssh/environment? OpenSSH wil nog wel eens borken als je niet exact de juiste permissies hebt. Wat je ook nog zou kunnen proberen is iets van:

code:

ssh user@server 'export MIJNPOORT=12345 /pad/naar/mijn/te/starten/applicatie

Dit kun je ook nog proberen: een wrapper script schrijven welke je op de server plaatst. Zoiets dus:

code:

$ cat /pad/naar/wrapper/script
export MIJNPOORT=12345
exec /pad/naar/mijn/te/starten/applicatie
$

code:

ssh user@server /pad/naar/wrapper/script

offtopic:
En toch kan ik het niet laten: Waarom moeten je gebruikers een uniek portnummer instellen? Ben razend benieuwd of het mischien op een andere (makkelijkere) manier kan...

[ Voor 62% gewijzigd door Verwijderd op 06-04-2005 14:47 ]

[Kees]

bij mij werkt het gewoon, TEST=bla in mijn environment file, en hij pikt het meteen op. Als ik er een foute regel inpleur zegt hij het bij het inloggen.

Proebber er zeker van te zijn dat die PermitUserEnvironment wel op yes staat, en restart ook je sshd

[Verwijderd]

Verwijderd schreef op woensdag 06 april 2005 @ 14:42:
Probeer eens in te loggen (vanaf een unix bak) met ssh -vvv, dan zien we net ff wat meer debug output. Tevens, wat zijn de permisies op ~/.ssh/environment? OpenSSH wil nog wel eens borken als je niet exact de juiste permissies hebt. Wat je ook nog zou kunnen proberen is iets van:

code:

ssh user@server 'export MIJNPOORT=12345 /pad/naar/mijn/te/starten/applicatie

Dat gaat niet, we gebruiken een andere default shell dan /bin/sh (namelijk een shellscript die wat dingen regeld en onze applicatie start). Dit ivm met veiligheidsredenen.

Dit kun je ook nog proberen: een wrapper script schrijven welke je op de server plaatst. Zoiets dus:

code:

$ cat /pad/naar/wrapper/script
export MIJNPOORT=12345
exec /pad/naar/mijn/te/starten/applicatie
$

Zoiets hebben we nu dus ook ja. Alleen de port is dus voor iedere client anders, dus dat gaat niet werken. de client moet de SSH server laten weten wat de poort is, zonder dat de gebruiker deze ZELF moet invoeren.

code:

ssh user@server /pad/naar/wrapper/script

Zoals ik al zei, gaat niet

offtopic:
En toch kan ik het niet laten: Waarom moeten je gebruikers een uniek portnummer instellen? Ben razend benieuwd of het mischien op een andere (makkelijkere) manier kan...

Nou het zit zo. In de SSH client hebben we het 1 en ander ingesteld, dat op het moment dat je inlogged op het systeem, er een tunnel word gemaakt om over je lokale printer te printen. (een standaard 9100 printertje). We doen dit over een tunnel omdat dit meerdere voordelen heeft. 1 daarvan is dat de data versleuteld word door OpenSSH en de andere is dat we gaan gaten in firewalls hoeven te maken bij mensen thuis. (Ze hoeven alleen een outgoing connection naar port 22 kunnen openen). Dit is het verhaal even kort samengevat.

[Verwijderd]

Verwijderd schreef op woensdag 06 april 2005 @ 15:57:
Dat gaat niet, we gebruiken een andere default shell dan /bin/sh (namelijk een shellscript die wat dingen regeld en onze applicatie start). Dit ivm met veiligheidsredenen.

Niet om te mierenneuken hoor, maar als je een shellscript start, wordt er nog steeds een shell gespawned, en is het (^C of ^Z comes to mind) nog steeds mogelijk om een shell te bemachtigen, maar ok, ook dat is af te vangen en dicht te timmeren. Maargoed, ontopic ...

Zoiets hebben we nu dus ook ja. Alleen de port is dus voor iedere client anders, dus dat gaat niet werken. de client moet de SSH server laten weten wat de poort is, zonder dat de gebruiker deze ZELF moet invoeren.

Kun je dan niet zoiets opnemen in je huidige script?:

code:

case "`whoami`" in
    user1) PORT="12345" ;;
    user2) PORT="67890" ;;
esac

Tevens is het security wise niet echt verstandig om een gedeelte van je "secure setup" af te laten hangen van een poort die op de client gedefineerd is. Des te minder mogelijkheden je aan de client bied, des te minder mogelijkheden heeft de client om door jouw security heen tebreken. Ok, ik ken jouw setup verder niet, maar dit is meer een algemene richtlijn zeg maar

Nou het zit zo. In de SSH client hebben we het 1 en ander ingesteld, dat op het moment dat je inlogged op het systeem, er een tunnel word gemaakt om over je lokale printer te printen. (een standaard 9100 printertje). We doen dit over een tunnel omdat dit meerdere voordelen heeft. 1 daarvan is dat de data versleuteld word door OpenSSH en de andere is dat we gaan gaten in firewalls hoeven te maken bij mensen thuis. (Ze hoeven alleen een outgoing connection naar port 22 kunnen openen). Dit is het verhaal even kort samengevat.

Wel vet hoor. Werkt het een beetje? Al eens aan "normale" VPN's gedacht? (of zijn dit allemaal unix clients?)

[ Voor 3% gewijzigd door Verwijderd op 06-04-2005 16:10 ]

[Verwijderd]

Verwijderd schreef op woensdag 06 april 2005 @ 16:10:
[...]

Niet om te mierenneuken hoor, maar als je een shellscript start, wordt er nog steeds een shell gespawned, en is het (^C of ^Z comes to mind) nog steeds mogelijk om een shell te bemachtigen, maar ok, ook dat is af te vangen en dicht te timmeren. Maargoed, ontopic ...

Nee, dat gaat niet. We hebben in /etc/passwd de /bin/bash vervangen door ons eigen shellscript. Druk je hier op CTRL+C dan kom je niet in bash terecht, maar word je verbinding gewoon gekilled.

[...]

Kun je dan niet zoiets opnemen in je huidige script?:

code:

case "`whoami`" in
    user1) PORT="12345" ;;
    user2) PORT="67890" ;;
esac

Nee, de poort is niet afhankelijk van de GEBRUIKER, dan hadden we het probleem allang opgelost. De poort is afhankelijk van waar de CLIENT installed is. De SSH Client zal dus echt die poort moeten doorspelen aan de SSH server zonder dat daar user interactie aan te pas komt.

Tevens is het security wise niet echt verstandig om een gedeelte van je "secure setup" af te laten hangen van een poort die op de client gedefineerd is. Des te minder mogelijkheden je aan de client bied, des te minder mogelijkheden heeft de client om door jouw security heen tebreken. Ok, ik ken jouw setup verder niet, maar dit is meer een algemene richtlijn zeg maar

Er worden uiteraard checks uitgevoerd op de door de client gegeven poort (ligt ie in de goede range, is ie niet al in gebruik, etc.)

[...]

Wel vet hoor. Werkt het een beetje? Al eens aan "normale" VPN's gedacht? (of zijn dit allemaal unix clients?)

Jep, die tunnels werken perfect! We hebben ook een webinterface aan het systeem hangen op een Apache HTTP server. En port 80 is default geblocked op die doos. Maar zodra de user via SSH inlogged word er een tunnel gecreeert en kan de gebruiker gebruik maken van de HTTP via http://localhost:10000/

[Verwijderd]

Verwijderd schreef op woensdag 06 april 2005 @ 16:28:
Nee, dat gaat niet. We hebben in /etc/passwd de /bin/bash vervangen door ons eigen shellscript. Druk je hier op CTRL+C dan kom je niet in bash terecht, maar word je verbinding gewoon gekilled.

Het is mij in prive experimenten al eens gelukt om uit een shell script te breken welke als shell gedefineerd is. Het is dus wel mogelijk Moeilijker wordt het al als je een stukje C code gaat gebruiken

Nee, de poort is niet afhankelijk van de GEBRUIKER, dan hadden we het probleem allang opgelost. De poort is afhankelijk van waar de CLIENT installed is. De SSH Client zal dus echt die poort moeten doorspelen aan de SSH server zonder dat daar user interactie aan te pas komt.

Hoeveel clients heb je per ip adres? Als er maar 1 client per ip kan zijn kun je user vervangen door ip in bovenstaande case.

Jep, die tunnels werken perfect! We hebben ook een webinterface aan het systeem hangen op een Apache HTTP server. En port 80 is default geblocked op die doos. Maar zodra de user via SSH inlogged word er een tunnel gecreeert en kan de gebruiker gebruik maken van de HTTP via http://localhost:10000/

Lemme guess, webmin Ff wat anders, welke versies van ssh draai je op je server + client, heb je de tips van Kees al uitgeprobeerd en krijg je nog wat te zien in de ssh -vvv output?

[Verwijderd]

Verwijderd schreef op woensdag 06 april 2005 @ 16:38:
[...]

Het is mij in prive experimenten al eens gelukt om uit een shell script te breken welke als shell gedefineerd is. Het is dus wel mogelijk Moeilijker wordt het al als je een stukje C code gaat gebruiken

offtopic:
Interessant.. kan je daar wat meer over vertellen? bewijs? URL?

[...]

Hoeveel clients heb je per ip adres? Als er maar 1 client per ip kan zijn kun je user vervangen door ip in bovenstaande case.

Veelal gaat het om meerdere clients per IP.

[...]

Lemme guess, webmin Ff wat anders, welke versies van ssh draai je op je server + client, heb je de tips van Kees al uitgeprobeerd en krijg je nog wat te zien in de ssh -vvv output?

Nee geen webmin, gewoon een zelf geschreven PHP web applicatie. 10000 is alleen de poort waar de client op bind om deze te bereiken, serverside gezien draait de HTTP server nog steeds op 80.
Ik gaat nu ff dat ssh -vvv verhaal proberen, I'll be back in a few minutes

Edit: back, werkt nog niet

hmm.. als ik ssh -vvv gebruik lijkt hij mijn environment file helemaal niet op te pikken Hij leest wel andere files uit mijn .ssh dir uit, maar met de env file doet ie niks.
Ik heb het ongeveer zo:

code:

peter@finance:~$ ls -al .ssh/environment
-rw-r--r--  1 peter peter 18 Apr  6 16:46 .ssh/environment
peter@finance:~$ cat .ssh/environment
PRINTPORT=ABCDEFG
peter@finance:~$ ssh root@192.168.3.1
root@192.168.3.1's password:
Finance 11.01 - Terminal Edition
[root@p-software root]# echo $PRINTPORT

[root@p-software root]#

En wederom als ik het met PuTTY probeer, krijg ik de volgende melding nadat ik ingelogged ben:

code:

login as: root
root@192.168.3.1's password:
Server refused to set environment variables

[ Voor 28% gewijzigd door Verwijderd op 06-04-2005 17:04 ]

[Verwijderd]

Hmz, ok, lets try something else

1) Als je als normale user inlogt, werkt het dan wel?
2) Als je chmod go-rwx ~/.ssh/environment doet, werkt het dan wel?
3) Als je nou eens sshd herstart ipv hup'ped, werkt het dan wel?

Mocht dit alles niet baten (het zou gewoon moeten werken als je PermitUserEnvironment geset hebt) dan kunnen we nog wel ff gaan stracen om de oorzaak te achterhalen...