[OpenSSH] Authenticatie mechanismen

[BlaTieBla]

Ik heb een Ubuntu server (v7.x) draaien met daarop OpenSSH (en nog wat andere zaken). Omdat de machine aan het Internet komt te hangen heb ik public key authenticatie aangezet als authenticatie middel en dit werkt naar tevredenheid (tot op zeker hoogte).

Nu zit ik met het volgende probleem (of uitdaging);
Om shell toegang te krijgen tot de machine moet SSH gebruikt worden. Om te kunnen authenticeren is public key authenticatie nodig. Om dat werkende te krijgen moet de gebruiker zijn public key op de server zetten, maar die kan daar niet op komen, omdat je alleen aan kan loggen met public key authentication (kip en het ei verhaal).
De gebruikers gebruiken tools als Putty, SecureCRT etc. om een SSH verbinding op te zetten en gebruiken diverse Operating Systemen.

Nu loop ik zelf met de gedachte om twee sshd's te draaien op verschillende poorten met verschillende configuraties. de ene is vanaf Internet bereikbaar (alleen public key authenticatie) en de andere alleen via het interne netwerk (gebruikersnaam en wachtwoord). op die manier kunnen de gebruikers dus aanloggen en de public key authenticatie zelf regelen. En via het internet is alleen een veilige authenticatie methode beschikbaar.

Ik kan me niet indenken dat ik de eerste ben met deze uitdaging en vraag me dan ook af of er geen andere oplossingen mogelijk zijn (plaintext protocollen als ftp, telnet etc.) zijn uit den boze.
Ik ben al op zoek geweest om bijvoorbeeld in de config files iets te regelen met een authenticatie methode per subnet ofzo, maar daar heb ik nog niets over kunnen vinden.

Al vast bedankt voor het meedenken.

[Erkens]

Public key naar de systeembeheerder laten mailen? Natuurlijk is het nogsteeds plain text, maar het gaat hier om een public key. Anders kan je ook natuurlijk de public key persoonlijk laten overhandigen via bijvoorbeeld een usb stick.

[Verwijderd]

Psies... noormaal gesproken hoort de systeembeheerder dat te regelen.

Maar mocht je dat echt niet willen, dan is jou oplossing een prima oplossing.

[Verwijderd]

Idd normaal verzorgt de beheerder van een *NIX server het key verhaal voor zijn klanten.

[phobosdeimos]

ALS je dit oplost, heb je automatisch een security lek.
Het wel of niet toegang geven gebeurt door een root gebruiker, niet door de end-user in kwestie.

[BlaTieBla]

phobosdeimos schreef op donderdag 17 april 2008 @ 15:19:
ALS je dit oplost, heb je automatisch een security lek.
Het wel of niet toegang geven gebeurt door een root gebruiker, niet door de end-user in kwestie.

De beheerder maakt de gebruiker aan. Op deze manier kan de gebruiker zelf kiezen of hij/zij ook toegang via het internet wil krijgen. Als dat het geval is, dan moeten ze zelf de public key toevoegen. Die laatste mogelijkheid is er alleen vanaf het interne netwerk op basis van de username en wachtwoord van de gebruiker.

code:

Internet<--port12345, public key--->[SSH server]<---port 22, password-->Interne netwerk

Dus ik ben even op zoek naar dat security probleem. De gebruiker is immers al geautoriseerd.

De reden dat ik geen sleutelparen aan wil maken is dat ik dan ook uit moet gaan leggen hoe dat per applicatie gaat werken en dat mogen ze zelf uitzoeken. Ga maar eens na wat er tegenwoordig allemaal met public keys kan werken.

• Filezilla [unprotected PuttY (ppk) private key]
• SecureCRT
• Bitwise Tunnelier
• PuttY
• Linux/OSX/Solaris
• etc...

En allemaal werken ze anders (qua key generatie)

[ Voor 21% gewijzigd door BlaTieBla op 17-04-2008 17:07 ]

[Keeper of the Keys]

Zou je niet iets van een OTP [One Time Password] kunnen gebruiken, waarbij de gebruiker precies 1 wachtwoord krijgt om zich die ene keer die nodig is om de key neer te zetten aan te melden en daarna moet hij/zijn van binnen en van buiten zijn key gebruiken?

[Osiris]

BlaTieBla schreef op donderdag 17 april 2008 @ 17:03:
De reden dat ik geen sleutelparen aan wil maken is dat ik dan ook uit moet gaan leggen hoe dat per applicatie gaat werken en dat mogen ze zelf uitzoeken.

"Hier heb je een OpenSSH-key, veel plezier ermee, zoek het zelf maar uit."

Elke zichzelf respecterende SSH-client die public key authentication e.d. ondersteunt kan als 't goed is heus wel een OpenSSH-key importeren. Putty iig wel. En de gebruiker moest het sowieso volgens jou allemaal al uitzoeken, dus wat is het verschil nou?

[BlaTieBla]

Keeper of the Keys schreef op donderdag 17 april 2008 @ 21:18:
Zou je niet iets van een OTP [One Time Password] kunnen gebruiken, waarbij de gebruiker precies 1 wachtwoord krijgt om zich die ene keer die nodig is om de key neer te zetten aan te melden en daarna moet hij/zijn van binnen en van buiten zijn key gebruiken?

Volgens mij heeft de SSH server van VanDyke (Vshell) dergelijke functionaliteit, die is alleen niet helemaal gratis . Ik had dus gehoopt dat dit ook op een manier mogelijk was met OpenSSH.
Vooralsnog ziet het er naar uit dat het een kwestie wordt van twee sshd'd met eigen specifieke configs.

Osiris schreef op donderdag 17 april 2008 @ 21:22:
[...]

"Hier heb je een OpenSSH-key, veel plezier ermee, zoek het zelf maar uit."

Elke zichzelf respecterende SSH-client die public key authentication e.d. ondersteunt kan als 't goed is heus wel een OpenSSH-key importeren. Putty iig wel. En de gebruiker moest het sowieso volgens jou allemaal al uitzoeken, dus wat is het verschil nou?

Ik leg die verantwoordelijkheid liever gewoon bij de gebruiker neer. Daarnaast ga je op die manier tegen alle principes in waar public key crypto voor staat. Je bent als eindgebruiker zelf ten alle tijde verantwoordelijk voor je eigen sleutelpaar (en dan met name de private key). Dat is je identiteit en die wil je dan ook zelf aanmaken.

Ik weet dat dit laatste enigszins overtrokken is, maar je moet ergens een grens trekken (en pki is mijn primaire aandachtsgebied).
Ook bij wachtwoorden hoort een beheerder het wachtwoord niet te weten. Dat hij (toch wel) bij de bestanden kan komen etc. (als hij dat echt wil) is weer een hele andere discussie.

[Erkens]

BlaTieBla schreef op donderdag 17 april 2008 @ 22:13:
Ik leg die verantwoordelijkheid liever gewoon bij de gebruiker neer. Daarnaast ga je op die manier tegen alle principes in waar public key crypto voor staat. Je bent als eindgebruiker zelf ten alle tijde verantwoordelijk voor je eigen sleutelpaar (en dan met name de private key). Dat is je identiteit en die wil je dan ook zelf aanmaken.

Als je dus niet wilt dat ze aan jou hun private key geven (zodat je hun account kan "activeren") dan kan je ook een ander systeem maken waarbij jij hun een eenmalige private key geeft, zodra ze eenmaal ingelogd zijn verwijder je met een scriptje hun key van de server waarna ze hun eigen key kunnen plaatsen.

Het draaien van een tweede SSH service vind ik een beetje overdreven en onhandig. Zelf zou ik het gewoon houden op het handmatig doorgeven van de public keys, al dan niet via een encrypted/signed mail bericht (waarbij je het zelfs nog zou kunnen automatiseren)

[BlaTieBla]

Erkens schreef op donderdag 17 april 2008 @ 22:25:
[...]

Als je dus niet wilt dat ze aan jou hun private key geven (zodat je hun account kan "activeren") dan kan je ook een ander systeem maken waarbij jij hun een eenmalige private key geeft, zodra ze eenmaal ingelogd zijn verwijder je met een scriptje hun key van de server waarna ze hun eigen key kunnen plaatsen.

Het draaien van een tweede SSH service vind ik een beetje overdreven en onhandig. Zelf zou ik het gewoon houden op het handmatig doorgeven van de public keys, al dan niet via een encrypted/signed mail bericht (waarbij je het zelfs nog zou kunnen automatiseren)

Dit alles is meer werk dan eenmalig configureren en het starten van een tweede sshd (althans voor mij dan).
De server is er voor een aantal mensen (zijn consultants mensen?? ) om wat met linux (security) cli-tools te kunnen spelen. Als hij 'uitbrand' is er geen schade wat productiviteit betreft. En juist vanwege die 'as is' status wil ik er zeker geen procedures en scripts aan vuil maken.

Enige vereiste vanuit security oogpunt is dat er niet op basis van gebruikersnaam en wachtwoord aangelogd kan worden vanaf het Internet, maar dat daar OTP of PKI voor gebruikt moet worden.
OTP is een extra investering die wellicht later nog ingepast kan gaan worden (wat het dan wel weer eenvoudiger maakt, omdat dan de tweede sshd ook weg kan).

In ieder geval bedankt voor het meedenken tot zo ver.

[Keeper of the Keys]

BlaTieBla schreef op donderdag 17 april 2008 @ 22:13:
[...]

Volgens mij heeft de SSH server van VanDyke (Vshell) dergelijke functionaliteit, die is alleen niet helemaal gratis . Ik had dus gehoopt dat dit ook op een manier mogelijk was met OpenSSH.
Vooralsnog ziet het er naar uit dat het een kwestie wordt van twee sshd'd met eigen specifieke configs.

Er zijn ook allerlei 'vrije' OTP oplossingen als ik zo in mijn apt-cache kijk....

Verder zou je ook kunnen overwegen om port 22 gewoon dicht te gooien en met portknocking + "one time knocks" te werken (of hergebruikte, maar gebruiker verschillend etc... is veel mee te doen)...
Op die manier heb je al een vorm van authenticatie gedaan voor ze ooit met sshd praten over user/pass...