Re: Alternativen zum NFS-Loopback-Mount in 5.1?

From: Oliver Fromme <olli(at)secnetix.de>
Date: Sat, 2 Aug 2003 16:03:37 +0200 (CEST)

Gordon Bergling <gordon(at)bsd-network.org> wrote:
> On Sat Aug 02, 2003 at 02:20PM +0200, Matthias Teege wrote:
> > On Sat, Jul 26, 2003 at 02:36:45PM +0200, Oliver Fromme wrote:
> > > lo:/usr on /jail/chris (nfs, nodev, read-only, union)
> > > procfs on /jail/chris/proc (procfs, local)
> > > lo:/usr on /jail/jens (nfs, nodev, read-only, union)
> > > procfs on /jail/jens/proc (procfs, local)
> >
> > Ich habe hierzu noch eine Frage. Hat jede jail einen eigenen IP
> > Adresse und laeuft dazu jeweils ein ssh daemon? Es ist schon eine
> > Weile her, dass ich eine jail aufgesetzt habe.
>
> Das ein Jail jeweils eine eigene IP-Adresse hat ist logisch und
> notwendig.

Nein.

Man _kann_ natürlich jedem Jail eine eigene IP-Adresse ge-
ben, aber das ist keineswegs notwendig.

Auf dem Rechner, von dem o.g. Daten stammen, habe alle
Jails dieselbe IP-Adresse. In jedem Jail läuft ein eigener
sshd auf einem eigenen Port, den man natürlich den Usern
mitteilen muß. Ist nicht super elegant, aber man kann da-
mit leben. Die betreffenden Benutzer tragen den Port halt
einmal in ihre ~/.ssh/config ein (oder in die GUI-Config
ihres Windows-ssh-Clients) und können ihn danach getrost
vergessen.

In einem anderen Fall habe ich das Problem mit Hilfe eines
Layer-7-Switches (Nortel Alteon) gelöst. In dem Fall ging
es um Zugänge für Webhosting-Kunden, die sich per ssh auf
einem Pflege-Rechner einloggen können sollen, auf dem ihr
Web-Content gemountet ist. Jeder Kunde hat dort ein Jail,
jedes Jail hat dieselbe IP-Adresse, und in jedem Jail läuft
ein sshd auf einem anderen Port. So weit ist es wie im
ersten Beispiel. Und jetzt kommen die L7-Switches ins
Spiel: Macht ein Kunde eine ssh-Verbindung zu www.seine-
domain.de auf (ganz normal auf Port 22), so schickt ihn der
Alteon intern auf »seinen« Port auf dem Pflege-Server, ohne
daß der Kunde etwas davon wissen muß. Verbindungen auf
Port 80/443 (HTTP/HTTPS) dagegen schickt der L7-Switch auf
den eigentlichen Web-Server (auf den der Kunde natürlich
keinen Shell-Zugang hat). Die offiziellen Adressen der
Kunden-Webserver müssen in diesem Fall natürlich schon un-
terschiedliche IP-Adressen sein, aber das müssen sie eh,
wenn HTTPS produktiv verwendet werden soll.

Und schließlich möchte ich noch einen dritten Fall erwäh-
nen, den ich allerdings in dieser Form nicht mehr weiter-
geführt habe. Dort lief nur _ein_ sshd-Prozess im Host-
System (außerhalb der Jails). Ich hatte den sshd-Source so
gepatcht, daß er unmittelbar nach der Entgegennahme der
User-Identifikation (aber vor der Authentisierung) einen
jail()-Call in das Jail dieses Benutzers macht. Dazu gab
es in der sshd_config für jeden Benutzer einen jail-Ein-
trag. Das hatte den Vorteil, daß jeder Benutzer sich ganz
normal auf Port 22 auf einer IP-Adresse verbinden konnte.
Es war eine sehr elegante Lösung. Nachteil war, daß jeder
EInlogvorgang ein separates Jail war -- Zwar mit gleichem
chroot und gleicher IP, aber doch ein anderes Jail. Das
bedeutete, daß, wenn ein Prozeß Amok lief, sich der User
nicht ein zweites mal einloggen konnte, um ihn zu killen.
Da es ein anderes Jail war, sah er den Prozeß gar nicht.
Mit JailNG (-current) wird man dieses Problem lösen können,
da man dort Prozesse in ein existierendes Jail stecken
kann. Aber mit den Jails in -stable geht das nicht.

Ein weiterer Nachteil war, daß ich bei jeder neuen ssh-Ver-
sion meine Patches wieder mitziehen und mergen mußte, was
nicht sehr spaßig war. Die Sourcen von ssh/sshd sind nicht
gerade ein Ausbund an Struktur und Übersichtlichkeit. Da-
her habe ich diese Lösung inzwischen wieder begraben. Aber
falls es jemanden interessiert und er bereit ist, ein biß-
chen Fleiß zu investieren, kann ich ihm gerne die alten
Patches zuschicken (die sind noch für OpenSSH 2.x).

> Ob Du einen SSH-Deamon am laufen hast ist Dir überlassen aber
> sehr zu empfehlen sonst kommt man ja nur noch über Umwege ins Jail.

Naja, irgendeine Art von Login-Möglichkeit muß es schon ge-
ben. Und das sollte schon eine halbwegs sichere sein, also
ssh, crypto-telnet, Kerberos ... Notfalls normales (unver-
schlüsseltes) telnet mit s/key o.ä., was immerhin von über-
all funktioniert, ohne daß man einen speziellen Client
braucht, und trotzdem muß man keine Paßwörter im Klartext
durch's Netz schicken. Aber von all diesen Möglichkeiten
ist ssh wohl am verbreitetsten.

Eine »Lösung«, wo man sich erst in das Host-System einloggt
und dann von dort auf irgendeinem Weg in sein Jail gelangt,
wäre ja komplett witzlos. Da könnte man sich die Jails
auch gleich ganz sparen. (Immer vorausgesetzt, wir reden
hier von Shell-Zugängen. Bei anderen jailifizierten Servi-
ces mag das ganz anders aussehen, je nach Einzelfall.)

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"With sufficient thrust, pigs fly just fine.  However, this
is not necessarily a good idea.  It is hard to be sure where
they are going to land, and it could be dangerous sitting
under them as they fly overhead." -- RFC 1925
To Unsubscribe: send mail to majordomo.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Sat 02 Aug 2003 - 16:03:47 CEST

search this site