[linux-l] Rechner hinter Router administrieren

[Steffen Schulz]

On 070921 at 07:02, Volker Grabsch wrote:
> > --> Das war mein Einwand, unkontrollierter Verbindungsaufbau, genau danach 
> > hörte sich das an.
> Auch eine Variante wäre, den SSH-Daemon auf dem Support-Rechner
> überhaupt nur dann laufen zu lassen, wenn sich ein Kunde auch einloggen
> soll, und nach erfolgreichem Login den SSH-Daemon wieder zu stoppen
> (die eine offene Verbindung bleibt ja erstmal).

...Hauptsache, man handelt an allen anderen Ecken dann ebenso
paranoid...

> Auch nett: Wegwerf-Passwörter. Auf dem Client ist dann halt ein
> "Support-Icon", das nach einem Doppeltklick erstmal ein Passwort
> verlangt - das einem der Support dann mitteilt, und dieses Passwort
> erst in dem Moment freischaltet. Danach wieder den Account deaktivieren.

Ich weiss nicht ob du das meinst, da du freischalten und deaktivieren
sagst vermutlich nicht: Man kann einfach OTP-basierten Login verlangen.
Den OTP-Generator hat dann nur der Support, der auf Anfrage genau ein
Passwort an den Kunden weiter gibt.

http://en.wikipedia.org/wiki/One-time_password
http://www.onlamp.com/pub/a/bsd/2003/02/06/FreeBSD_Basics.html

> (z.B. "*" vor den Passwort-Hash in der /etc/shadow setzen, oder in
> /etc/passwd die Shell auf /bin/false setzen, oder was auch immer)

Dann braucht man das hier nicht. Ich glaube man braucht so noch
nichtmal verschiedene Accounts. Muss man pruefen, ob sich zwei Kunden
irgendwie beeinflussen koennten.


Fast immer funktioniert auch ein einfacher UDP-Tunnel. Wichtig ist nur,
dass das erste Packet vom Kunden zum Support geht. Da UDP stateless
ist, wird der darauf folgende Verbindungsaufbau vom Support als Antwort
interpretiert und von Routern/Firewalls durchgelassen. Die
Authentifikation muss dann natuerlich innerhalb des Tunnels geschehen.
Nach kurzer Inaktivitaet werden Router/Firewalls den Kanal wieder
vergessen.


mfg
pepe
-- 
Hi, I'm a unix-virus.
Please copy me into your .signature to help me spread!