Re: sftp und virtual users

[Håkan Kaellberg <hk@xxxxxxxxxxx>]

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 Kaellberg wrote:
> > On Sat, Mar 19, 2011 at 08:36:45PM +0100, Raphael Eiselstein wrote:
> > > HÃ¥kan Kaellberg wrote:
> > > > Die Unix User muessen 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 tatsaechlich ein chroot-environment, in dem der sshd laeuft.
> > 
> > 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/* unabhaengig verwaltet werden koennen.[1]

Ich habe nicht verstanden, dass 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. fuer Zugriff haben willst, muss Du eher Unix-User haben, dann waere
wohl ein richtiger Chroot die LOesung.

> openssh kann man aber scheinbar nicht nativ dazu bringen, User
> ausschliesslich(!) unabhaengig von von /etc/passwd zu authentiizieren.

Ich sehe zwei moeglich andere Wege... Ob sie fuer Dich gangbar sind,
oder nicht kann ich nicht so genau sagen. "UsePAM" gibt die Moeglichkeit
ueber PAM zu authentifizieren, leider scheint die Schnittstelle
ausschliesslich fuer 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-Loesung waere sicherlich
einfacher.

> Weitere Ueberlegung: Wenn ich fuer eine systemunabhaengige sftp-Authentifi-
> kation ein chroot bauen muss, dann kann ich auch fuer die einfache ftp-
> Authentifikation einen ganz normalen vsftpd mit "real users" verwenden, 
> der innerhalb des gleichen chroot laeuft. Aktuell laeuft schon ein vsftpd 
> mit "virtual users", der Benutzer mit PAM ueber /opt/path/to/passwordfile 
> authentifiziert.

Ich kenne vsftpd nicht. Kommst Du damit von klartext-uebertragene
Passwoerter weg??

> > Viele Gruesse:				HÃ¥kan
> 
> Gruss
> 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 koennen. Schon aus diesem Grund 
> darf der von extern erreichbare ssh-Daemon keine Benutzer authtentifi-
> zieren *koennen*, es muss also durch Konfiguration 100% ausgeschlossen 
> werden. Schon allein fuer diese Sicherheitsanforderung ist ein chroot fuer
> den *externen* ssh-Daemon fast unumgaenglich. 

Das waere ein Argument in sich! Aber eigentlich ist dass auch mit Public
Key Login gewaehrleistet. Sofern, und das waere 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 muesstest Du ja Konsolezugang zur Hardware haben... Heute stehen ja
die Rechnier im RZ, irgendwo anders. Dann *muessen* wir ja mit ssh als
Priv-User mittelst Public Key an die Kisten kommen. Das ist doch ein
Mechanismus, den wir absolut trauen muessen, 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 fuer das ganze System tun, zum Beispiel device-nodes fuer 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 bewusst, daÃ? alle genannte Konzepte
nicht ganz vergleichbar sind )

Viele Gruesse:				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/