nicht angemeldet
Immer noch Kummer mit einer selektiven chroot ssh-Umgebung
Hello,
ich habe immer noch Kummer mit einem chrooted ssh-Zugang für User _und_ root (mit su) auf
- einer Suse 10.3
- einem Debian 4.0
1. Wie erkenne ich, ob der vorhandene sshd für chroot gepached ist?
Abfrage mit 'sshd -v' odr muss ich eine andere benutzen?
2. Root soll auf eine vollwertige Konsole umschalten können
alle anderen User sollen nur das dürfen, was für sie festgelegt wurde
3. Wie könnte man alternativ anderen Usern als dem der per su
zu root werden darfden SSH-Zugang ganz untersagen
wenn wir dann für den Filetransfer doch mit vsftp arbeiten würden?
Das ist nicht so optimal, da unverschlüsselt.
Die User sollen aber bei lokaler Anmeldung die vorgesehenen Konsolen
bekommen, also vermutlich doch schon wieder chroot...
4. Wenn ich jetzt eine gepatchte Version von sshd von sourceforge runter-
laden und selber kompilieren würde, wie könnte ich die dann mit
yast oder auch kompatibel zu apt-get in die Systeme einbauen?
Ich möchte keine Nebenschauplätze aufmachen.
Ein harzliches Glückauf
Tom vom Berg
-
Tach,
ich habe immer noch Kummer mit einem chrooted ssh-Zugang für User _und_ root (mit su) auf
chroot ist _kein_ Sicherheitsmerkmal: z.B. http://kerneltrap.org/Linux/Abusing_chroot
Was ist das eigentliche Ziel, das du mit chroot erreichen willst?
- Root soll auf eine vollwertige Konsole umschalten können
alle anderen User sollen nur das dürfen, was für sie festgelegt wurde
Dann mußt du die Zugriffsrechte entsprechend restriktiv setzten oder eine echte Virtualisierung nutzen (unter Linux wäre das z.B. http://linux-vserver.org/Welcome_to_Linux-VServer.org@titleVServer).
- Wie könnte man alternativ anderen Usern als dem der per su
zu root werden darfden SSH-Zugang ganz untersagen
wenn wir dann für den Filetransfer doch mit vsftp arbeiten würden?
Als Shell für User, die nur Daten übertragen sollen, eignet sich scponly
- Wenn ich jetzt eine gepatchte Version von sshd von sourceforge runter-
laden und selber kompilieren würde, wie könnte ich die dann mit
yast oder auch kompatibel zu apt-get in die Systeme einbauen?
Ich möchte keine Nebenschauplätze aufmachen.
Bei sicherheitsrelevanten Tools wie ssh ist das keine gute Idee; ansonsten kann man entsprechende Pakete für Debian relativ einfach erstellen; aber solange es um einen einzelnen Rechner geht, hat man davon keinerlei Vorteil gegenüber der händischen Installation.
mfg
Woodfighter-
Hello,
Dann mußt du die Zugriffsrechte entsprechend restriktiv setzten oder eine echte Virtualisierung nutzen (unter Linux wäre das z.B. http://linux-vserver.org/Welcome_to_Linux-VServer.org@titleVServer).
Es geht schon teilweise um gemeinsame Verzeichnisse, aber eben nur teilweise.
Ich werde mir das nun morgen auch noch alles reinziehen.
Das wird wohl ein "Dauerauftrag", weil ich immer wieder Gegenteiliges lese, wenn ich gerade denke, dass es nun so gehen würde...Da schätze ich mir doch die NDS von Novell. Leider sind die auch für Linux nicht ganz billig.
Ein harzliches Glückauf
Tom vom Berg
-
Tach,
Dann mußt du die Zugriffsrechte entsprechend restriktiv setzten oder eine echte Virtualisierung nutzen (unter Linux wäre das z.B. VServer).
Es geht schon teilweise um gemeinsame Verzeichnisse, aber eben nur teilweise.
das ist auch mit echter Virtualisierung kein Problem.
Da schätze ich mir doch die NDS von Novell. Leider sind die auch für Linux nicht ganz billig.
Du kannst auch unter Linux LDAP oder ähnliches einsetzen; allerdings klingt es für dein Problem erheblich überdimmensioniert.
mfg
Woodfighter-
Hello,
Du kannst auch unter Linux LDAP oder ähnliches einsetzen; allerdings klingt es für dein Problem erheblich überdimmensioniert.
... und hätte dudem den Nachteil, dass ich es in der verbleibenden Zeit bestimmt nicht zum Laufen bringe. Ich werde mir also noch mal die Virtualisierung ansehen, wenn Du meunst, dass das Zweck hat und ich nicht alles neu installieren muss.
Es soll ja nebenbei auch die Forderung erfüllt sein, dass nichts Grundlegendes am yast-Paketmanager vorbei installiert wird. Kleinere Einstellungen in Conf-Dateien sind erlaubt, die verhindern ja nicht das Entfernen/Updaten durch yast.
Ein harzliches Glückauf
Tom vom Berg
-
Tach,
Ich werde mir also noch mal die Virtualisierung ansehen, wenn Du meunst, dass das Zweck hat und ich nicht alles neu installieren muss.
das habe ich nicht gesagt, VServer wird einiges an Aufwand bedeuten.
Es soll ja nebenbei auch die Forderung erfüllt sein, dass nichts Grundlegendes am yast-Paketmanager vorbei installiert wird.
Das ist unter Linux theoretisch vermeidbar, wenn alle Partitionen auf die der User schreiben kann noexec sind und auch das bietet prinzipiell erstmal nur eine kleine Hürde sofern dynamische Bibliotheken benutzt werden, ist also kein wirkliches Sicherheitsmerkmal.
Das A und O bei der Konfiguration eines Mehrbenutzersystems sind korrekt gesetzte Zugriffsberechtigungen, alles weitere sind eher nette Einschränkungen aber nicht mehr.
mfg
Woodfighter-
Hello,
ich habe jetzt die Chroot-Umgebung nach der Anleitung
http://www.howtoforge.de/howto/sshsftp-chroot-umgebung-aufbauen.htmlauf der Suse eingerichtet. Das funktioniert für die Konsole auch soweit.
Nur der sftp-server startet nicht. Da gibt es nur eine Meldung am Client
"faild to open a secure file transfer session"Den Fehler habe ich noch nicht gefunden...
Kann an Pfaden liegen odr auch einfach an einer falschen version von sftp-server, die nämlich mit der Installation nicht mitgekommen ist, oder aber die alte am falschen Platz überschrieben hat.
Das habe ich noch nicth näher untersucht. Kommt Donnerstag erst an die Reihe :-((Ein harzliches Glückauf
Tom vom Berg
-
Tach,
ich habe jetzt die Chroot-Umgebung nach der Anleitung
http://www.howtoforge.de/howto/sshsftp-chroot-umgebung-aufbauen.html404
auf der Suse eingerichtet. Das funktioniert für die Konsole auch soweit.
Nur der sftp-server startet nicht. Da gibt es nur eine Meldung am Client
"faild to open a secure file transfer session"entweder der SSH-Server liegt nicht da, wo er in der sshd_config beschrieben ist, oder der User kann ihn nicht ausführen.
mfg
Woodfighter-
Hello,
404
Entschuldigung. Da war auf meinem Austruck ein Stück verloren gegangen:
http://www.howtoforge.de/howto/sshsftp-chroot-umgebung-auf-fedora-7/
entweder der SSH-Server liegt nicht da, wo er in der sshd_config beschrieben ist, oder der User kann ihn nicht ausführen.
Jau, ersteres hatte ich schon vermutet, aber dann durch Richtigstellen des Pfades und/oder Hineinkopieren des Programmfiles in den verwendeten Pfad auch keinen Erfolg gehabt.
Die Rechte muss ich dann nochmal genau prüfen.
Ich hatte noch den Verdacht, dass die Versionen nicht mehr zusammen passen, weil ich den sshd in der gepatchten Form von OpenSSH neu heruntergelden hatte und selber compiliert und der sftp-server nicht zum Paket dazugehört...
Ich habe also die alte Version weiterbenutzt.
Ein harzliches Glückauf
Tom vom Berg
-
Tach,
entweder der SSH-Server liegt nicht da, wo er in der sshd_config beschrieben ist, oder der User kann ihn nicht ausführen.
korrektur, ich meinte sftp-server
Jau, ersteres hatte ich schon vermutet, aber dann durch Richtigstellen des Pfades und/oder Hineinkopieren des Programmfiles in den verwendeten Pfad auch keinen Erfolg gehabt.
Das Kopieren von binaries erzeugt Sicherheitslücken, da beim nächsten Sicherheitsupdate die kopierten Versionen nicht geändert werden; statt dessen sollten immer Links verwendet werden, oder man dokumentiert das ordentlich und flucht dann bei jedem Update.
Hast du den Pfad zur Datei auch als ge-chrooteter User überprüft?
mfg
Woodfighter-
Hello,
entweder der SSH-Server liegt nicht da, wo er in der sshd_config beschrieben ist, oder der User kann ihn nicht ausführen.
korrektur, ich meinte sftp-server
Das hatte ich auch so verstanden. Denn der SSH-Server läuft ja, wie ich berichtet hatte.
Jau, ersteres hatte ich schon vermutet, aber dann durch Richtigstellen des Pfades und/oder Hineinkopieren des Programmfiles in den verwendeten Pfad auch keinen Erfolg gehabt.
Das Kopieren von binaries erzeugt Sicherheitslücken, da beim nächsten Sicherheitsupdate die kopierten Versionen nicht geändert werden; statt dessen sollten immer Links verwendet werden, oder man dokumentiert das ordentlich und flucht dann bei jedem Update.
Den hatte ich als erstes, wegen der von Dir erwähnten Gründe. Da ich aber nicht weiß, wie sshd innen drin aussieht, habe ich eben probiert. Hätte ja sein können, dass der aus irgendwelchen Sicherheitserwägungen heraus nicht mit Links auf seine Sub-Programme sonden nur direkt mit dem Programm arbeiten will.
Hast du den Pfad zur Datei auch als ge-chrooteter User überprüft?
Da steckt eventuell der Fehler. Bin ich Dienstag nicht mehr zu gekommen, das zuende zu prüfen.
Nur wird der Pfad ja eigentlich in der sshd_config angegeben und nicht als öffentlicher Parameter für den jeweilgen SSH-User.Der gefangene User hat nur Pfade auf seine eigene bin usw.
Genau gucke ich das morgen nach.Aber mir dünkt, dass der sftp-server im Gefängnis liegen muss und nicht mehr außerhalb. Alle nicht gefangenen User können sich ja anmelden zum sftp. *klicker, klicker* Nal sehen, obs ein guter alter Groschen wird.
Ein harzliches Glückauf
Tom vom Berg
-
Hello,
Aber mir dünkt, dass der sftp-server im Gefängnis liegen muss und nicht mehr außerhalb. Alle nicht gefangenen User können sich ja anmelden zum sftp. *klicker, klicker* Nal sehen, obs ein guter alter Groschen wird.
Habe das jetzt überprüft.
Der sftpd-Server liegt ebenfalls im Gefängnis und sogar unter dem (relativ) richtigen Pfad.Ein Gefangener hat aber nur folgenden Pfad nach der Anmeldung mit der SSH-Konsole
Last login: Tue May 6 16:29:59 2008 from 192.168.178.30
-bash-3.2$ echo $PATH
/usr/bin:/bin:/usr/sbin:/sbin
-bash-3.2$Wo stelle ich nun ggf. den Pfad zum sftp-server für diese User dauerhaft ein?
Und muss ich das überhaupt? Scheint zwar so, aber sicher bin ich nicht.Das kann ja nicht die /etc/login.defs sein, oder?
Ein harzliches Glückauf
Tom vom Berg
-
Hello,
es liegt an den Pfaden UND der fehlenden Kopie
Der Gefängnisinsasse muss ja das Executable innerhalb seines Gefängnisses liegen haben.Zusätzlich habe ich übersehen, dass in der Dartei '/etc/ssh/sshd_config' der Pfad für das Subsystem noch auf '/usr/lib/ssh/sftp-server' gesetzt ist, da er da im ungepatchten ssh-Paket auch liegt.
Es musste also ersten dieser Pfad innerhalb des Gefängnisses angelegt werden
/home/chroot/usr/lib/ssh/sftp-server
------------|-----------------------und dann darin ein Link auf die tatsächliche Lage des sftp-servers gesetzt werden, bzw dieser gleich in das Verzeichnis kopiert werden.
Das Verzeichnis, dass laut dieser Anleitung erzeugt wird, ist
/home/chroot/usr/libexec/openssh/
------------|--------------------Der Link müsste aber lauten
ln -s /usr/libexec/openssh/sftp-server sftp-server
da er relativ zur virtual Root gesetzt werden muss.
Und das war mein Fehler.Es wäre nun zu überlegen, ob man nun für die nicht gefangenen User auch das sftp-server Executable unter
/home/chroot/usr/lib/ssh/sftp-server
benutzt, damit es nur einmal auf der Platte liegt. Dan müsste im Verzeichnis
/usr/lib/ssh/
ein Link gelegt werden
ln -s /home/chroot/usr/lib/ssh/sftp-server sftp-server
da es keinen Zweck hätte, einfach den Pfad in der Konfiguration zu ändren. Der muss ja sowohl im Gefängnis relativ zur Virtual Root als auch außerhalb relativ zur Origin Root passen.
Soweit, so gut.
Es funktioniert jetzt einigermaßen zufriedenstellend.
Kleiner Wehrmutstropfen bei dieser Art, sich ein Chroot für ssh-Konsole UND sftp-server zu bauen ist, dass der User mit seinem sftp-Client noch in die virtuelle Root kommt und dadurch auch die Verzeichnisse der anderen User (namentlich) sehen könnte. Auslesen und Bentutzung kann man ihm mit den File-Rechten verbieten...Ich muss also nochmal eine Nacht darüber schlafen...
Ein harzliches Glückauf
Tom vom Berg
-
Tach,
Kleiner Wehrmutstropfen bei dieser Art, sich ein Chroot für ssh-Konsole UND sftp-server zu bauen ist, dass der User mit seinem sftp-Client noch in die virtuelle Root kommt und dadurch auch die Verzeichnisse der anderen User (namentlich) sehen könnte.
normalerweise legt man für jeden User einzeln ein entsprechendes Jail an.
Auslesen und Bentutzung kann man ihm mit den File-Rechten verbieten...
Auch das Auflisten von Verzeichnisinhalten.
mfg
Woodfighter-
Hello,
Auslesen und Bentutzung kann man ihm mit den File-Rechten verbieten...
Auch das Auflisten von Verzeichnisinhalten.
Ja, sagte ich ja: Auslesen des Verzeichnisses. Sollte bedeuten: kein Browserecht oder auch kein r-Recht für das Verzeichnis.
Dass die betroffene Usergruppe ein gemeinsames "Jail" habt, ist hier nicht unerwünscht.
Das hatte ich vielleicht bei der Aufgabenstellung nicht klar genug rüber gebracht.Mal sehen, wie ich den Knoten morgen auflöse.
Ein harzliches Glückauf
Tom vom Berg
-
Tach,
Auslesen und Bentutzung kann man ihm mit den File-Rechten verbieten...
Auch das Auflisten von Verzeichnisinhalten.
Ja, sagte ich ja: Auslesen des Verzeichnisses. Sollte bedeuten: kein Browserecht oder auch kein r-Recht für das Verzeichnis.
nein, ich meinte das Leserecht auf das übergeordnete Verzeichnis, das muß der Nutzer nicht haben, da reicht ihm "ausführen" und schon kann er keine Verzeichnisnamen, die ihn nichts angehen mehr sehen.
mfg
Woodfighter-
Hello,
Ja, sagte ich ja: Auslesen des Verzeichnisses. Sollte bedeuten: kein Browserecht oder auch kein r-Recht für das Verzeichnis.
nein, ich meinte das Leserecht auf das übergeordnete Verzeichnis, das muß der Nutzer nicht haben, da reicht ihm "ausführen" und schon kann er keine Verzeichnisnamen, die ihn nichts angehen mehr sehen.
ACK
Zumindest kann er sie nicht mehr auflisten lassen.
Benutzen kann er sie ja ggf. noch und dann werden sie auch wieder sichtbar für ihn.
Man könnte also eine "Wörterbuchattake" auf ./<verzeichnis>/null versuchen, wobei <verzeichnis> der gesuchte Name ist.Ein harzliches Glückauf
Tom vom Berg
-
Tach,
Zumindest kann er sie nicht mehr auflisten lassen.
Benutzen kann er sie ja ggf. noch und dann werden sie auch wieder sichtbar für ihn.
Man könnte also eine "Wörterbuchattake" auf ./<verzeichnis>/null versuchen, wobei <verzeichnis> der gesuchte Name ist.dann sind die Rechte falsch gesetzt.
mfg
Woodfighter
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Root soll auf eine vollwertige Konsole umschalten können
-
Hallo,
- Wie könnte man alternativ anderen Usern als dem der per su
zu root werden darfden SSH-Zugang ganz untersagen
wenn wir dann für den Filetransfer doch mit vsftp arbeiten würden?
Das ist nicht so optimal, da unverschlüsselt.
vsftp unterstützt FTPS (FTP over TLS). AFAIR sogar aus dem Deb-Paket heraus.
-
Hello,
- Wie könnte man alternativ anderen Usern als dem der per su
zu root werden darfden SSH-Zugang ganz untersagen
wenn wir dann für den Filetransfer doch mit vsftp arbeiten würden?
Das ist nicht so optimal, da unverschlüsselt.
vsftp unterstützt FTPS (FTP over TLS). AFAIR sogar aus dem Deb-Paket heraus.
Ja, man kann SSL benutzen, aber das löst ja nicht das Problem, dass jeder auf dem Host angelegte User dann trotzdem SSH zur Verfügung hat, denn das benötigen wir ja auf jeden Fall und eben leider auch von außen.
Ein harzliches Glückauf
Tom vom Berg
-
Tach,
Ja, man kann SSL benutzen, aber das löst ja nicht das Problem, dass jeder auf dem Host angelegte User dann trotzdem SSH zur Verfügung hat, denn das benötigen wir ja auf jeden Fall und eben leider auch von außen.
warum willst du das Einloggen der User denn unbedingt verhindern?
mfg
Woodfighter-
Hello,
Ja, man kann SSL benutzen, aber das löst ja nicht das Problem, dass jeder auf dem Host angelegte User dann trotzdem SSH zur Verfügung hat, denn das benötigen wir ja auf jeden Fall und eben leider auch von außen.
warum willst du das Einloggen der User denn unbedingt verhindern?
Es gibt eine Reihe von Usern, die nur einen Filetransfer-Zugang zum Server benötigen.
Der Grundgedanke ist nun der gewesen, für alle das unverschlüsslete FTP zu vermeiden und nur noch sftp (also filetransfer via ssh) zu verwenden.
Bisher gab es FTP. Ich habe dann auf Wunsch den vsftpd eingerichtet und dann fiel mir auf, dass ja jeder User, der auf dem System bekannt ist, auch einen uneingeschränkten ssh-Zugang hat, weil ssh eben auch eingerichtet ist. DAS ist aber für die meisten User nicht erwünscht, während sftp schon erwünscht wäre.
Auch wenn wir jetzt wieder zurückrudern, und nur vsftpd einsetzen oder aber z.B. ProFTPd mit TLS, dann bliebe der SSH-Zugang trotzdem, denn der wird für die wenigen User benötigt, die ihn tatsächlich auch nutzen sollen, inclusive root.
Wie mache ich also das Loch im SSH zu, denn das muss ich auf jeden Fall?
Und wenn ich das schaffe, brauche ich auch keinen ProFTPd mehr, denn dann habe ich SFTP, was für unsere Belange reicht und außerdem den Vorteil hat, dass es besser durch die Firewalls der User passt, denn die sitzen breit verteilt und man muss ggf. nur über Telefon helfen, wie sie denn auf den Server kommen.
Ich hoffe, dass das jetzt mein Problemchen befriedigend beschreibt und mir am Ende doch noch jemand den Schubs in die richtige Richtung geben kann.
Ein harzliches Glückauf
Tom vom Berg
-
Tach,
Bisher gab es FTP. Ich habe dann auf Wunsch den vsftpd eingerichtet und dann fiel mir auf, dass ja jeder User, der auf dem System bekannt ist, auch einen uneingeschränkten ssh-Zugang hat, weil ssh eben auch eingerichtet ist. DAS ist aber für die meisten User nicht erwünscht, während sftp schon erwünscht wäre.
wie schon gesagt, da hilft scponly.
Wie mache ich also das Loch im SSH zu, denn das muss ich auf jeden Fall?
Warum du ssh für ein Loch hälst, hast du noch nicht erklärt. Wenn es ein Loch ist, sind die Rechte auf dem Server falsch gesetzt oder du vertraust den installierten Programmen nicht.
mfg
Woodfighter
-
-
- Wie könnte man alternativ anderen Usern als dem der per su
- Wie könnte man alternativ anderen Usern als dem der per su