FreeNX werkt, maar nu nog SSH authentication met keys

dinsdag 10 november 2009 09:18

Crakie schreef op maandag 09 november 2009 @ 21:16:
2) FreeNX geïnstalleerd met zijn eigen (niet veilige) keys (repo, dan /usr/lib/nx/nxsetup --install)
3) Op verzoek van FreeNX in sshd_config opgenomen:

Welke oude versie heb je dan proberen te installeren? Ik heb de PPA van freenx-team gebruikt en daarbij krijg ik de output dat het deprecated is die dingen te doen die jij allemaal doet. Zoiets van 'dump die oude tutorials, het is nu allemaal beter'.

Volgens mij snap je namelijk niet helemaal wat er gebeurt met FreeNX. De NX Client logt in met user 'nx' met de public/private key. Verdere auth (user) gaan helemaal buiten SSH om, namelijk door de reeds veilige SSH tunnel! Je hoeft dan ook alleen maar FreeNX te installeren, vervolgens alleen de user 'nx' toegang te geven in de sshd_config. Zonder wachtwoord inloggen op NX zal niet gaan vrees ik, want zo werkt het NX framework nou eenmaal.

Kia e-Niro 2021 64kWh DynamicPlusLine. 3x Victron MP-II op 15kWh US5000 3f thuisbatterij met 3x25A→3x40A PowerAssist, Victron EVCS, 3200Wp HoyMiles zp. my GitHub, my blog

Acties:

dinsdag 10 november 2009 12:32

Running on Ubuntu

Als je geen /etc/nxserver/node.conf hebt, dan is er toch iets fout gegaan met de installatie van FreeNX.
Als ik FreeNX installeer werkt het eigenlijk vrijwel out of the box.
Ik verander in sshd_config wel de standaard port van 22 > ? (schijnveiligheid, maar scheelt heel wat regels in je logfile)
Daarnaast verander ik in /etc/nxserver/node.conf ENABLE_USERMODE_AUTHENTICATION="0" zodat ik met mijn gewone credentials in kan loggen.
Dan de private key in de NX Client plakken / importeren
Even verbindingssettings goed instellen (Gnome / KDE / enz) goede portnummer en gaan met die banaan..

Als je gewoon de tutorial volgt https://help.ubuntu.com/community/FreeNX dan kan er weinig misgaan.

Btw voor de kenners
Ik draai zelf Ubuntu 9.04. sshd_config staat PermitRootLogin=YES. Is dat een veiligheidsrisico? Met root heb ik geen WW of iets dergelijks ingevuld

Statistieken zijn als bikini's: wat ze tonen is erg suggestief, wat ze niet tonen is essentieel

Acties:

dinsdag 10 november 2009 12:57

I want my board back, Lance

Topicstarter

gertvdijk schreef op maandag 09 november 2009 @ 23:43:
[...]

Welke oude versie heb je dan proberen te installeren? Ik heb de PPA van freenx-team gebruikt en daarbij krijg ik de output dat het deprecated is die dingen te doen die jij allemaal doet. Zoiets van 'dump die oude tutorials, het is nu allemaal beter'.

Dezelfde repo gebruikt, die van Jaunty welteverstaan. Ik wil nog niet upgraden naar Karmic.

Volgens mij snap je namelijk niet helemaal wat er gebeurt met FreeNX. De NX Client logt in met user 'nx' met de public/private key. Verdere auth (user) gaan helemaal buiten SSH om, namelijk door de reeds veilige SSH tunnel! Je hoeft dan ook alleen maar FreeNX te installeren, vervolgens alleen de user 'nx' toegang te geven in de sshd_config. Zonder wachtwoord inloggen op NX zal niet gaan vrees ik, want zo werkt het NX framework nou eenmaal.

Ik snap er inderdaad niks van. Ik neem aan dat je bedoelt dat de NX-client met user NX inlogt met zijn eigen keys (niet die van SSH). Die zijn niet veilig genoeg, maar die kan ik vervangen in /var/lib/nxserver/home/authorized_keys2 (de regel die ik in sshd_config heb gezet) en in de client de complementaire te zetten. Prima, dan is de login voor NX-gebruik goed geregeld.

MAAR: de login voor andere users nog niet. Ik wil namelijk óóḱ via SSH met een andere user dan NX kunnen inloggen op de shell (niet die FreeNX-omgeving), dus er moet behalve NX minimaal één andere user geallowed worden in sshd_config. En aangezien ik volgens de instructies die ik kreeg, passwordauthentication op yes moet staan, kan die user gewoon met zijn wachtwoord inloggen. En dat wil ik absoluut niet als de boel naar internet open staat. Elke oplossing voor mijn probleem moet dus inhouden dat passwordauthentication op no komt te staan en er uitsluitend met keys kan worden ingelogd. Maar volgens mij kan 'mijn'FreeNX daar dus niet tegen.

Let wel, ik begrijp heel goed dat FreeNX na authenticatie met keys ook een user inlogt met wachtwoord. Geen enkel bezwaar, maar waarom moet passwordauthentication in sshd_config dan op no staan? De FreeNX-authenticatie gaat juist met keys!

Als je geen /etc/nxserver/node.conf hebt, dan is er toch iets fout gegaan met de installatie van FreeNX.
Als ik FreeNX installeer werkt het eigenlijk vrijwel out of the box.
Ik verander in sshd_config wel de standaard port van 22 > ? (schijnveiligheid, maar scheelt heel wat regels in je logfile)
Daarnaast verander ik in /etc/nxserver/node.conf ENABLE_USERMODE_AUTHENTICATION="0" zodat ik met mijn gewone credentials in kan loggen.
Dan de private key in de NX Client plakken / importeren
Even verbindingssettings goed instellen (Gnome / KDE / enz) goede portnummer en gaan met die banaan..

Als je gewoon de tutorial volgt https://help.ubuntu.com/community/FreeNX dan kan er weinig misgaan.

Btw voor de kenners
Ik draai zelf Ubuntu 9.04. sshd_config staat PermitRootLogin=YES. Is dat een veiligheidsrisico? Met root heb ik geen WW of iets dergelijks ingevuld

/etc/nxserver/node.conf bestaat echt niet. Wel een lege map /etc/nxserver/node.conf.d. Tutorial heb ik gevolgd, en de boel werkt in principe.

Ik zou rootlogins echt alleen maar toestaan als het niet anders kan, en dan zeker wel met wachtwoord.

Deze signature is strikt genomen langer dan noodzakelijk.

Acties:

dinsdag 10 november 2009 13:06

Running on Ubuntu

Het is eigenlijk heel simpel.
Eerst opent de NX Client een SSH tunnel aan de hand van de public / private key
Is de key correct, dan pas kan de user inloggen aan de hand van username / password
Is de key niet correct dan kun je niet eens connecten, dus ik zie je probleem eigenlijk niet zolang je je private key ook private houdt. Jij bent bang voor brute force, maar ze zullen dus altijd EN je public key EN je username EN je password moeten raden. Iets wat mij erg onwaarschijnlijk lijkt.

Zoals ik al eerder aanhaalde, er is waarschijnlijk toch echt iets fout gegaan tijdens de installatie van FreeNX server. Als ik bij mij in de folder /etc/nxserver kijk dan staan daar de volgende files / folders

Folder:
node.conf.d

Files:
node.conf
nxacl
nxcheckload
nxshadowacl
passwords
passwords.orig
users.id_dsa
users.id_dsa.pub

Welke files heb jij in de folder /etc/nxserver staan?
Verder over de sshd_config file. Ik heb alleen het portnummer verandert en verder de configuratie default gelaten. Waar heb jij gelezen dat je password authentication op YES moet zetten? Als je de tutorial die ik in voorgaande post volgt, moet je een werkbare omgeving krijgen.
Misschien een rare vraag, maar werk je echt met FreeNX? niet NoMachine NXServer? Daar heb ik ook even naar gekeken namelijk, en daar zijn de mappen en files toch iets anders dan bij FreeNX

Statistieken zijn als bikini's: wat ze tonen is erg suggestief, wat ze niet tonen is essentieel

Acties:

dinsdag 10 november 2009 13:52

Crakie schreef op dinsdag 10 november 2009 @ 12:32:
MAAR: de login voor andere users nog niet. Ik wil namelijk óóḱ via SSH met een andere user dan NX kunnen inloggen op de shell (niet die FreeNX-omgeving), dus er moet behalve NX minimaal één andere user geallowed worden in sshd_config. En aangezien ik volgens de instructies die ik kreeg, passwordauthentication op yes moet staan, kan die user gewoon met zijn wachtwoord inloggen. En dat wil ik absoluut niet als de boel naar internet open staat. Elke oplossing voor mijn probleem moet dus inhouden dat passwordauthentication op no komt te staan en er uitsluitend met keys kan worden ingelogd. Maar volgens mij kan 'mijn'FreeNX daar dus niet tegen.

Dan zet je passwordauth toch uit? NX verandert verder niks aan je SSH server, hoor. Als jij voorheen al met keys kon inloggen kan je dat nu ook. en als je voorheen het had dichtgetimmerd met passwordauth uit dan is dat nu ook nog tenzij je braindead tutorials gaat volgen en gaat gillen dat iets niet meer gaat werken terwijl je ook zelf wat kan interpreteren (lees: iets anders doen).

Crakie schreef op dinsdag 10 november 2009 @ 12:32:
Tutorial heb ik gevolgd, en de boel werkt in principe.

Welke tutorial? In die post die je quote staat niks over passwordauth op yes met SSH.

skinlee78 schreef op dinsdag 10 november 2009 @ 09:18:
Btw voor de kenners
Ik draai zelf Ubuntu 9.04. sshd_config staat PermitRootLogin=YES. Is dat een veiligheidsrisico? Met root heb ik geen WW of iets dergelijks ingevuld

Dat is wel veilig omdat root in Ubuntu standaard een disabled login heeft, net zoals system users. Die zouden dan ook niet veilig zijn...

[ Voor 21% gewijzigd door gertvdijk op 10-11-2009 13:10 ]

Kia e-Niro 2021 64kWh DynamicPlusLine. 3x Victron MP-II op 15kWh US5000 3f thuisbatterij met 3x25A→3x40A PowerAssist, Victron EVCS, 3200Wp HoyMiles zp. my GitHub, my blog

Acties:

dinsdag 10 november 2009 14:31

I want my board back, Lance

Topicstarter

gertvdijk schreef op dinsdag 10 november 2009 @ 13:06:
[...]

Dan zet je passwordauth toch uit? NX verandert verder niks aan je SSH server, hoor. Als jij voorheen al met keys kon inloggen kan je dat nu ook. en als je voorheen het had dichtgetimmerd met passwordauth uit dan is dat nu ook nog tenzij je braindead tutorials gaat volgen en gaat gillen dat iets niet meer gaat werken terwijl je ook zelf wat kan interpreteren (lees: iets anders doen).

Als ik passwordauth uitzet, dan lukt inloggen met NX niet meer. Waarom zou ik hier anders posten? Ik gebruik tutorials als leidraad, is dat zo erg? Ik probeer echt wel te snappen hoe het werkt, maar ik kom er niet uit. Bovendien is er toch echt iets raars aan de hand als ik bij dezelfde installatieprocedure geen node.conf aanmaak en Skinlee78 wel.

Welke tutorial? In die post die je quote staat niks over passwordauth op yes met SSH.

Nee, dat staat nergens, maar in mijn OP staat duidelijk dat ik dat op verzoek van FreeNX heb gedaan. Met andere woorden, als ik apt-get install freenx draai of nxsetup --install (welke van de twee weet ik niet meer) dan vertelt hij dat ik passwordauth op yes moet zetten... en dat moet inderdaad want anders logt hij niet in.

Het is eigenlijk heel simpel.
Eerst opent de NX Client een SSH tunnel aan de hand van de public / private key
Is de key correct, dan pas kan de user inloggen aan de hand van username / password
Is de key niet correct dan kun je niet eens connecten, dus ik zie je probleem eigenlijk niet zolang je je private key ook private houdt. Jij bent bang voor brute force, maar ze zullen dus altijd EN je public key EN je username EN je password moeten raden. Iets wat mij erg onwaarschijnlijk lijkt.

Voor FreeNX is dat prima inderdaad, maar als ik ssh naar user@host (niet nx@host) dan vraagt hij enkel om een wachtwoord en dat is NIET veilig. Zet ik passwordauth uit, dan lukt inloggen met FreeNX niet meer.

Folder:
node.conf.d

Files:
node.conf
nxacl
nxcheckload
nxshadowacl
passwords
passwords.orig
users.id_dsa
users.id_dsa.pub

Welke files heb jij in de folder /etc/nxserver staan?
Verder over de sshd_config file. Ik heb alleen het portnummer verandert en verder de configuratie default gelaten. Waar heb jij gelezen dat je password authentication op YES moet zetten? Als je de tutorial die ik in voorgaande post volgt, moet je een werkbare omgeving krijgen.
Misschien een rare vraag, maar werk je echt met FreeNX? niet NoMachine NXServer? Daar heb ik ook even naar gekeken namelijk, en daar zijn de mappen en files toch iets anders dan bij FreeNX

Zal vanavond nog eens in de folder kijken maar uit mijn hoofd stonden er minder files. Ik herken er wel een paar. Dat pwauth op yes moet komt (zoals gezegd) van output van apt-get install freenx of nxsetup --install en als ik het niet doe, kan ik wel SSH'en, maar niet NX'en. En ja, het is echt FreeNX.

Deze signature is strikt genomen langer dan noodzakelijk.

Acties:

woensdag 11 november 2009 00:44

Running on Ubuntu

Ik zou freenx toch eens de-installeren en dan rmdir /etc/nxserver doen
Ff opnieuw beginnen.
Probeer de tutorial te volgen die ik al eerder gepost heb.
Outcomment toch even je passwordauth (# ervoor) in sshd_config

Daarna, tijdens install van Freenx heb ik gekozen om NIET de default key van NoMachine te gebruiken, in de terminal zie je waar de client.id_dsa.key naar toe gekopieerd wordt. Kopieer die key naar je ~/ en gebruik die key in je NX Client(s).

Verder zoals ik al eerder aanhaalde, verander eventueel de default poort van sshd_config en PermitRootLogin NO en verder laat je sshd_config default.

Stap 2, bij mij is node.conf aanpassen

# weghalen bij:
EnableUserModeAuthentication ="0"
Enable_Force_Encryption="0"

Verder, als je de poort van sshd_config aangepast hebt, voor de zekerheid ook:
SSHD_PORT=je nieuwe poort

Reboot / Restart Freenx + SSH

En probeer met gebruik van je private key te connecten gebruik makend van je eigen credentials.

Ben benieuwd of het dan wel gaat werken

Statistieken zijn als bikini's: wat ze tonen is erg suggestief, wat ze niet tonen is essentieel

Acties:

woensdag 11 november 2009 08:10

I want my board back, Lance

Topicstarter

Oké, ik heb uren zitten prutsen, maar ik ben er.

1) Eerst heb ik de SSH-server geconfigureerd. Het is daarbij volgens mij absoluut essentieel om "PasswordAuthentication no" in sshd_config te zetten. Doe je dat niet, dan geef SSH de optie om met je wachtwoord in te loggen als er geen keys op de client staan (probeer maar door ~/.ssh te renamen op de client).

2) Bij deze SSH-configuratie kreeg ik na installatie van FreeNX wél een /etc/nxserver/node.conf om te editten (al weet ik niet zeker of dat aan de SSH-configuratie lag). Dat gaf weer een hoop nieuwe mogelijkheden.

3) De truc is om deze node.conf eerst te editten, dan dpkg-reconfigure freenx-server te draaien en DAN pas het installatiescript van FreeNX zelf. In node.conf heb ik drie parameters veranderd in (mogelijk hoeft dat niet alle drie, maar het werkt nu eenmaal)

ENABLE_USERMODE_AUTHENTICATION="1"
ENABLE_PASSDB_AUTHENTICATION="1"
ENABLE_SSH_AUTHENTICATION="0"

In dpkg-reconfigure kies ik vervolgens custom keys respectievelijk usermode authentication. De key van /var/lib/nxserver/home/custom_keys/client.id_dsa.key gaat naar de client.

4) Het installatiescript /usr/lib/nx/nxsetup vraagt of de default keys moeten worden gebruikt. Nee, en de keys die dan worden aangemaakt worden in /etc/nxserver gezet, maar kennelijk niet gebruikt. Die van dpkg-reconfigure zijn de enige die werken (de twee paren zijn ook niet hetzelfde).

5) Vervolgens nog een user en wachtwoord aanmaken: nxsetup --adduser $user en nxsetup --passwd $user.

Nu heb ik precies wat ik wil. Als ik met SSH inlog op een shell met mijn standaard account op de server heb ik per se een key nodig, zonder key vraagt hij niet om een wachtwoord maar weigert hij toegang. Als ik via SSH nx probeer aan te loggen weigert hij ook toegang op basis van een key, en die key is niet de standaard NoMachine-key. Inloggen met NoMachine lukt uiteraard. Tijd om een gaatje in mijn router te prikken

Bedankt voor de input.

Deze signature is strikt genomen langer dan noodzakelijk.

Acties:

woensdag 11 november 2009 09:56

Running on Ubuntu

Goed nieuws. Top dat het werkt.
Zo zie je maar, er lopen meerdere wegen naar Rome

Statistieken zijn als bikini's: wat ze tonen is erg suggestief, wat ze niet tonen is essentieel

Acties:

woensdag 11 november 2009 10:42

Interessant hoe je het gedaan hebt. Ik heb het op een andere manier gedaan:

http://ubuntuforums.org/s...hp?p=7444638&postcount=78

Niet simpeler dan jouw methode. Ik begrijp trouwens niet waarom er niet meer te vinden is over dit onderwerp. SSH met key-authentification is toch heel wijd verbreid? Geeft iedereen dat dan maar op om FreeNX te kunnen draaien?

Een beetje offtopic, maar toch... een paar dagen geleden probeerde ik de FreeNX-server in Karmic te installeren en dat ging niet zoals ik wilde. FreeNX maakte geen nieuwe sleutels aan in /var/lib/nxserver/home/custom_keys, nadat ik dpkg-reconfigure freenx-server deed. Zou een bug kunnen zijn, maar ik kon er niets over vinden. Het kan ook dat FreeNX iets nieuws doet met de sleutels. Als iemand iets meer weet, ben ik erg geïnteresseerd.

Acties:

woensdag 11 november 2009 11:53

Running on Ubuntu

@jrs77
Dat probleem kwam ik inderdaad ook tegen. Iets met een stopargument die anders zou zijn dan verwacht als je dpkg-reconfigure inklopt.
Ik heb tijdens install van FreeNX gekozen om niet de default key te gebruiken en dus een custom key aan laten maken. Tijdens de install wordt er dan dus wel een client.id_dsa.key aangemaakt en naar een locatie geschreven (staat in terminal waar).
Die key heb ik gecopieerd en gebruikt in mn NXClient. Werkte zonder problemen.
Hopelijk heb je hier iets aan, als je het niet zelf al gevonden had.
Ik neem aan dat binnen aantal dagen / weken over dit probleem wel wat meer te vinden zal zijn, want inderdaad toen ik ging zoeken kwam ik niks tegen in de forums

Statistieken zijn als bikini's: wat ze tonen is erg suggestief, wat ze niet tonen is essentieel

Acties:

woensdag 11 november 2009 12:04

I want my board back, Lance

Topicstarter

Ik ben ook bepaald niet onder de indruk geraakt van de informatie over FreeNX. Je moet het echt bij elkaar schrapen, en blijkbaar moet het voor sommigen anders dan voor anderen. Eerlijk gezegd zal het ook niet meevallen een verzameling scripts (want dat is FreeNX vnl) te maken die op alle distro's 100 % werken. Ook de documentatie op de site van FreeNX zelf is gebrekkig. Vind ik precies het item in de FAQ dat ik nodig heb, staat er in de cruciale zin iets van 'Do not ... with without... first'. Ja, wat is het nu?

Maar goed, we kunnen het er wel over eens zijn dat het sleutelwerk de moeite waard is. Iedereen die tien seconden met VNC heeft gewerkt, weet waarom

Deze signature is strikt genomen langer dan noodzakelijk.

Acties:

woensdag 11 november 2009 15:30

Running on Ubuntu

Misschien een idee om hier een soort van Howto te maken op tweakers?
Maar ook hier blijft het probleem, elke distro zal enigszins afwijken en aangezien FreeNX nogal configureerbaar is, zal het een flink uitgewerkte howto moeten worden die verschillende functies uitlegt.

Maar inderdaad, als het werkt............dan is het echt alle moeite waard.
Draai het hier op een bescheten oude laptop (PIII, 700 mhz, 512 mb) icm Ubuntu 9.04 over een langzame ziggo lijn 3 mbit down / 0,5 mbit up en dan nog voelt het bijna alsof ik rechtstreeks achter de laptop zit. Geweldig spul in ieder geval.

Een tijd terug kwam ik ook ergens tegen dat Google ook bezig was om een NX Server te creëeren, NeatX genaamd, maar daar is al helemaal geen informatie over te vinden. Voordeel van NeatX is vooral dat het in 1 taal geschreven is, ipv een mengelmoes van programmeertalen zoals in FreeNX.
Als laatste optie heb je natuurlijk ook nog de gratis NX Server van Nomachine, met de restrictie om maar met max 2 personen te connecten, maar ook bij dit product, veels te weinig info over te vinden.

Statistieken zijn als bikini's: wat ze tonen is erg suggestief, wat ze niet tonen is essentieel

Acties:

woensdag 11 november 2009 19:09

Na wat gepuzzel ben ik er ook uit. Kortgezegd komt het op het volgende neer:

FreeNX gebruikt SSH standaard als auth backend. Hij connect naar localhost en duwt gewoon het username/password door wat je in je client invoert.
Als je PasswordAuthentication in je sshd uitzet geldt dat ook voor connecties op localhost en dus FreeNX kan niet meer authenticeren.
Om een andere auth backend te gebruiken voor FreeNX kan je dus als alternatief passdb gebruiken (FreeNX eigen password database). Dat werkt altijd, ongeacht de SSH server instellingen.

Die setting 'ENABLE_USERMODE_AUTHENTICATION' heeft er volgens mij niet zoveel mee te maken. Volgens de uitleg die erbij staat is dat alleen relevant als je de NX server als user lokaal (op de server) wil opstarten.

# Usermode means that a user can start the nxserver as his shell
# and connect directly to the right server via a custom client.

Crakie schreef op woensdag 11 november 2009 @ 00:44:
5) Vervolgens nog een user en wachtwoord aanmaken: nxsetup --adduser $user en nxsetup --passwd $user.

Jammer dat dit dus nodig is door het disablen van passwordauth in SSH. Hopelijk komt er snel gewoon PAM ondersteuning in FreenXN server!

Maar volgens mij kan het dus nog beter door 'SU auth' te gebruiken. Je moet daarvoor wel de 'nx' user wat meer rechten geven op je server:

# This adds SU to the possible authentication methods. For it to work the 
# "nx" user must be in the wheel (RedHat, Fedora) or the users group (SUSE)
# and the user logging in must have a valid shell that accepts the -c
# parameter.
#ENABLE_SU_AUTHENTICATION="0"

[ Voor 80% gewijzigd door gertvdijk op 11-11-2009 15:46 ]

Kia e-Niro 2021 64kWh DynamicPlusLine. 3x Victron MP-II op 15kWh US5000 3f thuisbatterij met 3x25A→3x40A PowerAssist, Victron EVCS, 3200Wp HoyMiles zp. my GitHub, my blog

Acties:

woensdag 11 november 2009 19:34

I want my board back, Lance

Topicstarter

skinlee78 schreef op woensdag 11 november 2009 @ 12:04:
Misschien een idee om hier een soort van Howto te maken op tweakers?
Maar ook hier blijft het probleem, elke distro zal enigszins afwijken en aangezien FreeNX nogal configureerbaar is, zal het een flink uitgewerkte howto moeten worden die verschillende functies uitlegt.

Goed idee, maar zoiets kun je beter in het engels doen: kunnen meer mensen ervan profiteren. En aangezien mijn kennis niet verder reikt dan Ubuntu/Debian, ben ik meer geneigd om een en ander toe te voegen aan die Howto. Kunnen andere distro's weer op voortborduren. Hoe vaak ik niet gered ben door een Gentoo-wiki...

gertvdijk schreef op woensdag 11 november 2009 @ 15:30:
Na wat gepuzzel ben ik er ook uit. Kortgezegd komt het op het volgende neer:
FreeNX gebruikt SSH standaard als auth backend. Hij connect naar localhost en duwt gewoon het username/password door wat je in je client invoert.
Als je PasswordAuthentication in je sshd uitzet geldt dat ook voor connecties op localhost en dus FreeNX kan niet meer authenticeren.
Om een andere auth backend te gebruiken voor FreeNX kan je dus als alternatief passdb gebruiken (FreeNX eigen password database). Dat werkt altijd, ongeacht de SSH server instellingen.

Makes sense. Ik vind de standaardoptie om SSH te gebruiken en dus PasswordAuthentication te moeten uitzetten in sshd geen gelukkige (als in veilige) keuze. Aan de andere kant zitten veel mensen tegenwoordig achter een router, en iedereen die er genoeg van snapt om daarin poorten te forwarden, snapt ook wel dat het niet veilig is om met een wachtwoord in te kunnen loggen.

Die setting 'ENABLE_USERMODE_AUTHENTICATION' heeft er volgens mij niet zoveel mee te maken. Volgens de uitleg die erbij staat is dat alleen relevant als je de NX server als user lokaal (op de server) wil opstarten.
# Usermode means that a user can start the nxserver as his shell
# and connect directly to the right server via a custom client.

Je heb zeer waarschijnlijk gelijk, maar ik er ga niet meer mee experimenteren

Maar volgens mij kan het dus nog beter door 'SU auth' te gebruiken. Je moet daarvoor wel de 'nx' user wat meer rechten geven op je server:
# This adds SU to the possible authentication methods. For it to work the 
# "nx" user must be in the wheel (RedHat, Fedora) or the users group (SUSE)
# and the user logging in must have a valid shell that accepts the -c
# parameter.
#ENABLE_SU_AUTHENTICATION="0"

De NX user moet in de groep van de user waar je mee inlogt ofzo?

Deze signature is strikt genomen langer dan noodzakelijk.

Acties:

donderdag 12 november 2009 01:29

I want my board back, Lance

Topicstarter

Hier nog een oplossing, waarbij SSH authenticatie in tact blijft. Best elegant eigenlijk. Dit komt uit de mailing list van FreeNX, waar ik ook gepost had en nu pas dit antwoord in mijn mail vond.

FreeNX uses ssh with authorized keys and a private key file to log in
user nx.

This user ( nx ) has /usr/bin/nxserver as its login shell.

FreeNX then does a local ssh login via nxserver, but this time as the user's
account, using password authentication, over the encrypted link.

BUT

This means you have to have an ssh daemon listening with password authentication
enabled.

This is not so good on port 22 on an outside IP address as you will be blasted
with script attacks and you will be relying on the user's passwords.

A couple of user mode ways using suid etc are available, but in my view the most
reliable way, (if a little messy), is to have a first sshd with password disabled
for the first user=nx public key connection, and then run a second sshd listening
only on 127.0.0.1 on another port with password enabled, which means ssh password
authentication is not available externally.

If you are using an exposed IP address then it is better to have port 22 listening only
on localhost with password enabled, and have the "external" sshd listening on another
port.

I use this arrangement for an external sshd anyway even without FreeNX.

You will need two sshd_config files in /etc/ssh/, two start lines in /etc/init.d/sshd
with the appropriate sshd_config file selected with the command line switch
-f /etc/ssh/sshd_configNX for the second sshd.

You will need to make sure the password enabled sshd is configured in
/etc/nxserver/node.conf line 51 if you choode to have that one not on port 22

NOTE:- If you have any interface exposed to the Internet with sshd listening
and FreeNX enabled with the default key, then anyone with the default key can
try a brute force attack !!!

It's not very likely, but if someone doesn't like you they may well try.

So if you use external FreeNX connections, change your FreeNX keys.

Deze signature is strikt genomen langer dan noodzakelijk.

Acties:

vrijdag 13 november 2009 16:50

Crakie schreef op woensdag 11 november 2009 @ 19:34:
Hier nog een oplossing, waarbij SSH authenticatie in tact blijft. Best elegant eigenlijk. Dit komt uit de mailing list van FreeNX, waar ik ook gepost had en nu pas dit antwoord in mijn mail vond.

Elegant? Twee SSH daemons runnen noem ik dat niet. Ik ga binnenkort eens experimenteren met SU login. Dat met een NX eigen passdb vind ik erg onpraktisch; een wachtwoord wijzigen voor een user moet dan op twee plekken.

Kia e-Niro 2021 64kWh DynamicPlusLine. 3x Victron MP-II op 15kWh US5000 3f thuisbatterij met 3x25A→3x40A PowerAssist, Victron EVCS, 3200Wp HoyMiles zp. my GitHub, my blog

Acties:

dinsdag 17 november 2009 13:02

Crakie schreef op woensdag 11 november 2009 @ 19:34:
Hier nog een oplossing, waarbij SSH authenticatie in tact blijft. Best elegant eigenlijk

Ja misschien niet voor een sysadmin, maar als je de enige gebruiker bent dan ziet het er niet uit alsof het heel veel extra werk is. Ik zie het echter nog niet helemaal voor me hoe ik dit moet doen. Als iemand een uitgewerkte howto heeft gevonden dan ben ik wel benieuwd...

Acties:

dinsdag 17 november 2009 14:25

Running on Ubuntu

Heeft iemand enig idee welke files ik moet vervangen om gebruik te maken van nieuwe key files voor FreeNX.
Ik maak gebruik van Ubuntu 9.10. Sinds deze versie mislukt

"sudo dpkg-reconfigure freenx-server".

Het menu om een nieuwe key te genereren start wel op, maar als ik dan een nieuwe SSH key wil genereren dan krijg ik een error message:

"update-rc.d: warning: freenx-server stop runlevel arguments (1) do not match LSB Default-Stop values (0 1 6) Not starting freenx-server, it's already started."

Online kan ik hier ook echt niets over vinden, alleen hier in dit forum is het eerder aangehaald door JRS77.
Toen heb ik een nieuwe keypair gegenereert met ssh keygen, wat wel werkt, maar deze worden naar ~/.ssh/ weggeschreven en verder niet gebruikt.
Toen heb ik op verschillende locaties de keyfiles proberen te vervangen met de nieuwe content, maar nergens succes. Locaties waar ik het heb vervangen zijn /usr/NX/share/keys/ (server.id_dsa.key), /etc/nxserver/ (users.id_dsa + users.id_dsa.pub), /var/lib/nxserver/home/default_keys/ (client.id_dsa.key) en /etc/ssh/ (ssh_host_dsa_key + ssh_host_dsa_key.pub)

Tot op heden kan ik alleen connecten met de default key van NoMachine, iets wat ik niet echt wil.
Iemand enige clue hoe dit op te lossen?

Statistieken zijn als bikini's: wat ze tonen is erg suggestief, wat ze niet tonen is essentieel

Acties:

dinsdag 17 november 2009 14:58

skinlee78 schreef op dinsdag 17 november 2009 @ 13:02:
[...]dan krijg ik een error message:

"update-rc.d: warning: freenx-server stop runlevel arguments (1) do not match LSB Default-Stop values (0 1 6) Not starting freenx-server, it's already started."

Geen error, maar een waarschuwing dat de init scripts verouderd zijn of niet aan de standaarden voldoen. Niets om aan te nemen dat je dpkg-reconfigure niet is gelukt.

skinlee78 schreef op dinsdag 17 november 2009 @ 13:02:
Tot op heden kan ik alleen connecten met de default key van NoMachine, iets wat ik niet echt wil.
Iemand enige clue hoe dit op te lossen?

Wat dacht je van /var/lib/nxserver/home/.ssh? Nogal logisch als je kijkt naar de homedir van de nx user:

grep ^nx /etc/passwd

en volgens een default SSH daemon staan keys in %h/.ssh.
En als je als root dingen gaat kopiëren in andermans homedirs: let op de rechten en ownership. Die zijn streng bij SSH keys. Eventuele fouten daarmee staan in /var/log/auth.log

[ Voor 11% gewijzigd door gertvdijk op 17-11-2009 14:27 ]

Kia e-Niro 2021 64kWh DynamicPlusLine. 3x Victron MP-II op 15kWh US5000 3f thuisbatterij met 3x25A→3x40A PowerAssist, Victron EVCS, 3200Wp HoyMiles zp. my GitHub, my blog

Acties:

dinsdag 17 november 2009 15:19

Running on Ubuntu

Helaas, ook daar de public en private key vervangen werkt niet.
Nog steeds kan ik met de default key connecten. En de key waarmee ik ze vervang dus juist niet.
Overigens ik neem wel aan dat dpkg-reconfigure misslukt, juist omdat er geen nieuwe key gegenereert wordt. Voorheen kon je die van van een default locatie copieren, maar dat werkt dus niet.
Hoe zou ik het init script kunnen updaten of wijzigen zodat dit wel gaat werken.
Dit probleem is er pas sinds Ubuntu 9.10. Bij 8.10 en 9.04 werkte dit allemaal prima, dus ik neem aan dat daarin het probleem zit.

Statistieken zijn als bikini's: wat ze tonen is erg suggestief, wat ze niet tonen is essentieel

Acties:

dinsdag 17 november 2009 15:29

skinlee78 schreef op dinsdag 17 november 2009 @ 14:58:
Helaas, ook daar de public en private key vervangen werkt niet.
Nog steeds kan ik met de default key connecten. En de key waarmee ik ze vervang dus juist niet.

Ik denk dat jij een heel basaal aspect niet begrijpt: SSH key authentication.
Je NX client heeft een private key waarvan een public deel in de authorized_keys file staat op de server. Je moet dus de private key (id_{d,r}sa) die je genereert in je client gebruiken en je public key (id_{d,r}sa.pub) in de authorized_keys2 file zetten op de NX server. Je kan meerdere public keys daarin hebben staan (één per regel) en daarmee dus meerdere keys authorizen. Als je de NX key eruit wil hebben moet je die regel verwijderen uit de authorized_keys file.

Want volgens mij heb jij nooit eerder iets met SSH key auth gedaan als ik dit zo lees. Ik zou zeggen doe dat eerst eens als good practice.

Wat je dus doet met het vervangen van public/private keys in de nx user op de server is de authenticatie vanaf de server een andere identity keyfile geven en dus helemaal niet wat je wil bereiken. Die denkfout las ik eerst ook niet in je eerdere post trouwens.

[ Voor 28% gewijzigd door gertvdijk op 17-11-2009 15:38 ]

Kia e-Niro 2021 64kWh DynamicPlusLine. 3x Victron MP-II op 15kWh US5000 3f thuisbatterij met 3x25A→3x40A PowerAssist, Victron EVCS, 3200Wp HoyMiles zp. my GitHub, my blog

Acties:

woensdag 18 november 2009 12:07

Running on Ubuntu

Goede analyse inderdaad. Al met al een behoorlijke Linux Noob, dus alle input is welkom.
Ik ga eens stoeien met authorized keys. Ben benieuwd of dat gaat werken.
In ieder geval bedankt voor de tip in de goede richting.

edit:
En dat werkt inderdaad

Ik was inderdaad de server.id_dsa.key aan het vervangen, maar blijkbaar moest dat dus in de authorized_keys gezet worden. Nog een pluspunt, clipboard copy tussen client en server werkt nu ook, dus dubbel blij

Hartelijk dank voor de input, maar toch blijf ik me afvragen wat er fout gaat bij dpkg-reconfigure. Heb al even in het script zitten snuffelen, maar daar zie ik weinig raars.

[ Voor 49% gewijzigd door arie_papa op 17-11-2009 15:40 ]

Statistieken zijn als bikini's: wat ze tonen is erg suggestief, wat ze niet tonen is essentieel

Acties:

woensdag 18 november 2009 13:18

Hier een link naar de threat waar Crakie het over had:

http://old.nabble.com/Fre...tt26274389.html#a26274389

Interessante threat. Ik blijf het erg irritant vinden dat de standaard ubuntu wiki (en eigenlijk elke tutorial over ssh) adviseert om ssh met sleutels te gebruiken, maar als je freenx gaat gebruiken dan is het opeens geen probleem meer dat je ssh met een paswoord gebruikt. Wie het toch veilig wil doen moet erg zijn best doen. Dat lijkt me niet verstandig. Zeker omdat veel mensen wel erg graag freenx zullen willen gebruiken.(Het is ook echt geweldig, zeker in vergelijking met vnc.)

Als ik het goed begrijp ligt het dus eigenlijk aan de NoMachine client, die zou, als je wil inloggen op de local host, behalve de mogelijkheid om dat met een paswoord te doen, ook de mogelijkheid moeten bieden om dat met een ssh private key te doen. Dat zou alles oplossen of begrijp ik het helemaal verkeerd?

Acties:

woensdag 18 november 2009 17:00

jrs77 schreef op woensdag 18 november 2009 @ 12:07:
Als ik het goed begrijp ligt het dus eigenlijk aan de NoMachine client, die zou, als je wil inloggen op de local host, behalve de mogelijkheid om dat met een paswoord te doen, ook de mogelijkheid moeten bieden om dat met een ssh private key te doen. Dat zou alles oplossen of begrijp ik het helemaal verkeerd?

Nee, het is totaal onzinnig dat de FreeNX server authenticeert tegen SSH. Daarvoor zijn talloze efficiëtere manieren: PAM, SASL, ... De enige reden die ik kan bedenken om het via SSH te doen is om zo de SSH config met betrekking tot allowed users wordt gerespecteerd.
Om misverstanden te voorkomen: ik bedoel de authenticatie van de FreeNX server nadat er een SSH tunnel is opgezet naar de FreeNX server vanaf de client naar de server (nx user). Als je niet weet wat ik bedoel moet je maar even uitzoeken wat alle stappen zijn die je doorloopt totdat je een NX verbinding hebt.

[ Voor 18% gewijzigd door gertvdijk op 18-11-2009 13:21 ]

Kia e-Niro 2021 64kWh DynamicPlusLine. 3x Victron MP-II op 15kWh US5000 3f thuisbatterij met 3x25A→3x40A PowerAssist, Victron EVCS, 3200Wp HoyMiles zp. my GitHub, my blog

Acties:

woensdag 18 november 2009 17:06

gertvdijk schreef op woensdag 18 november 2009 @ 13:18:
[...]

Nee, het is totaal onzinnig dat de FreeNX server authenticeert tegen SSH. Daarvoor zijn talloze efficiëtere manieren: PAM, SASL, ...

Ok wellicht is dat zo, maar ik meen me te herinneren dat de NoMachine server ook zo werkte. Weet iemand of dat ook echt zo is en hoe zit het eigenlijk met neatnx?. (Zit inmiddels ook in de freenx karmic ppa zag ik)

Anders kies ik bij een volgende instalatie niet meer voor freenx.

[ Voor 10% gewijzigd door jrs77 op 18-11-2009 17:02 ]

Acties:

woensdag 18 november 2009 17:22

jrs77 schreef op woensdag 18 november 2009 @ 17:00:
Ok wellicht is dat zo, maar ik meen me te herinneren dat de NoMachine server ook zo werkte. Weet iemand of dat ook echt zo is en hoe zit het eigenlijk met neatnx?. (Zit inmiddels ook in de freenx karmic ppa zag ik)

Neatx bedoel je? Dat bevindt zich nog niet eens in alpha volgens mij, aangezien er nog helemaal geen documentatie is, veel features nog ontbreken, maar de core op zich al wel een eind op weg is. Iets van toekomstmuziek en volgens mij ook niet echt iets waarvan nu al alles vastligt.

[ Voor 3% gewijzigd door gertvdijk op 18-11-2009 17:07 ]

Kia e-Niro 2021 64kWh DynamicPlusLine. 3x Victron MP-II op 15kWh US5000 3f thuisbatterij met 3x25A→3x40A PowerAssist, Victron EVCS, 3200Wp HoyMiles zp. my GitHub, my blog

Acties:

vrijdag 20 november 2009 09:16

gertvdijk schreef op woensdag 18 november 2009 @ 17:06:
[...]

Neatx bedoel je?

Ja die bedoel ik

Het installeren van een deb bestand is niet echt moeilijk en Nomachine en Freenx werken in theorie allemaal ongeveer min of meer op dezelfde manier, dus dan moet je met de Freenx en nomachine documentatie misschien al een eind kunnnen komen. De features die er nog niet zijn ga ik niet echt missen, shadow sessions zitten er wel al in en dat is wat ik voornamelijk doe.

Maar je hebt natuurlijk wel gelijk om enige afstand tot alfa software te bewaren....

Acties: