Re: sftp und virtual users

Autor: Håkan Källberg <hk_at_simulina.se>
Datum: Tue, 22 Mar 2011 08:34:07 +0100
On Sun, Mar 20, 2011 at 03:36:24AM +0100, Raphael Eiselstein wrote:
> On Sat, Mar 19, 2011 at 10:02:30PM +0100, Håkan Källberg wrote:
> > On Sat, Mar 19, 2011 at 08:36:45PM +0100, Raphael Eiselstein wrote:
> > > Håkan Källberg wrote:
> > > > Die Unix User müssen mit einem * in /etc/shadow angelegt sein.
> > 
> > > Das ist schade, weil ich die Verwaltung der Systemaccounts und die der
> > > Dienstbenutzer (sftp-Accounts) getrennt halten will (muss). Also brauche
> > > ich hier wohl tatsächlich ein chroot-environment, in dem der sshd läuft.
> > 
> > Das verstehe ich nicht ganz... Chroot macht doch sshd selber:
> > 
> > > >         ChrootDirectory %h
> 
> Aus sshd_config(5):
> 
> ChrootDirectory
>   Specifies the pathname of a directory to chroot(2) to *after* authentication.
> 
> Das bedeutet, dass ich alle sftp-Benutzer in meiner /etc/(passwd|shadow)
> anlegen muss, in der ich auch meine normalen Systemaccounts habe, also
> Adminaccounts etc. Diese Dateien werden vollautomatisch und 
> zentralisiert gepflegt, ich kann (will) also in /etc/* keine "Kunden-
> Accounts" pflegen. 
> 
> Daher war auch meine "Anforderung", dass es "Virtual Users" sein sollen, 
> also Benutzer, die von /etc/* unabhängig verwaltet werden können.[1]

Ich habe nicht verstanden, daß Du die Users nach Login trennen muß. Es
war erstmals nur von Authentication die Rede, und dann reichen Public Keys
in .ssh/authorized_keys. Wenn Du nach Login unterschiedliche User-Rechte,
z.B. für Zugriff haben willst, muß Du eher Unix-User haben, dann wäre
wohl ein richtiger Chroot die LÖsung.

> openssh kann man aber scheinbar nicht nativ dazu bringen, User
> ausschließlich(!) unabhängig von von /etc/passwd zu authentiizieren.

Ich sehe zwei möglich andere Wege... Ob sie für Dich gangbar sind,
oder nicht kann ich nicht so genau sagen. "UsePAM" gibt die Möglichkeit
über PAM zu authentifizieren, leider scheint die Schnittstelle
ausschließlich für User/Pw ausgelegt zu sein. Mit PAM kann man ja
sonnst die abgefahreneste Dinge machen.

Es gibt auch GSSAPIAuthentication, also Kerberos.

Beide Wege sind hochkomplex und ein ChRoot-Lösung wäre sicherlich
einfacher.

> Weitere Überlegung: Wenn ich für eine systemunabhängige sftp-Authentifi-
> kation ein chroot bauen muss, dann kann ich auch für die einfache ftp-
> Authentifikation einen ganz normalen vsftpd mit "real users" verwenden, 
> der innerhalb des gleichen chroot läuft. Aktuell läuft schon ein vsftpd 
> mit "virtual users", der Benutzer mit PAM über /opt/path/to/passwordfile 
> authentifiziert.

Ich kenne vsftpd nicht. Kommst Du damit von klartext-übertragene
Passwörter weg??

> > Viele Grüße:				Håkan
> 
> Gruß
> Raphael
> 
> PS: 1. Der entscheidende zweite entscheidende Aspekt ist, dass Benutzer, 
> die in /etc/shadow bzw /etc/passwd angelegt sind idR normale Admins
> sind. Admins haben idR sehr hohe Rechte am System via sudo. 

Nur die mit Public Key in .ssh/authorized_keys kommen dran...

> Es *muss* ausgeschlossen sein, dass sich hochprivilegierte User direkt 
> aus dem Internet auf dem System einloggen können. Schon aus diesem Grund 
> darf der von extern erreichbare ssh-Daemon keine Benutzer authtentifi-
> zieren *können*, es muss also durch Konfiguration 100% ausgeschlossen 
> werden. Schon allein für diese Sicherheitsanforderung ist ein chroot für
> den *externen* ssh-Daemon fast unumgänglich. 

Das wäre ein Argument in sich! Aber eigentlich ist daß auch mit Public
Key Login gewährleistet. Sofern, und das wäre vielleicht das Problem,
die priviligierte Users kein Public Key in ihren .ssh/authorized_keys
einpflegen...

Aber, wie denkst Du denn als Admin an den Server zu kommen? In dem
Fall müsstest Du ja Konsolezugang zur Hardware haben... Heute stehen ja
die Rechnier im RZ, irgendwo anders. Dann *müssen* wir ja mit ssh als
Priv-User mittelst Public Key an die Kisten kommen. Das ist doch ein
Mechanismus, den wir absolut trauen müssen, sonnst geht gar nichts
mehr im Internet:-)

> PPS: Ich vermisse Jails unter Linux. Ein chroot-Environment ist zwar
> schon ganz gut, aber wenn es kompromittiert wird und root-Rechte
> eskaliert werden, kann man auch aus einem chroot heraus sehr unangenehme
> Dinge für das ganze System tun, zum Beispiel device-nodes für die
> Systemplatten in /dev anlegen und die Systemplatte einfach ins chroot
> mounten, oder aber auf Prozesse zugreifen, die ausserhalb des chroots
> laufen (z.B. kill 1). 

Ja, aber schau Euch mal alle Lxc an: http://lxc.sourceforge.net/.
Lxc ist sicherlich nicht so ausgereift, wie jails, paralells, zones et
al. Ich habe aber da Hoffnung! V-Server und OpenVZ hat es ja nie nativ
in den Kernel geschafft. ( Wohl bewußt, daß alle genannte Konzepte
nicht ganz vergleichbar sind )

Viele Grüße:				Håkan

-- 


-- 
UUGRN e.V. http://www.uugrn.org/
http://mailman.uugrn.org/mailman/listinfo/uugrn
Wiki: https://wiki.uugrn.org/UUGRN:Mailingliste
Archiv: http://lists.uugrn.org/

Empfangen am 22.03.2011

Dieses Archiv wurde generiert von hypermail 2.2.0 : 22.03.2011 CET