SSH-Server mit Jail chroot Gefängnis für bestimmte User

[pangu]

Hi @ll,

ich kenne das Tutorial http://www.howtoforge.com/restricting-u ... an-squeeze aber ich wundere mich, ob es nicht ein fertiges SSH-Paket gibt, dass so etwas bereitstellt. Ich hab zwar mit dem Tutorial das Ziel erreicht, aber gibt's tatsächlich keinen fertigen SSH oder SSH2-Server, mit dem man ganz einfach konfigurieren kann, welche User in ein Verzeichnis gefesselt werden sollen? Mir ist klar, dass jeder seine Shell dann braucht, die zu erlaubenden Binaries, die Verzeichnisstruktur (/dev, /etc, /tmp usw...).

Gibt's da sowas fertiges schnell zu konfigurierendes Paket?

[xdanx]

Die Anleitung ist vollkommen Banane, da nicht mehr auf dem aktuellen Stand (obwohl da squeeze steht).

Seit OpenSSH 4.9 braucht man nicht mehr die ganzen binaries und libraries ins chroot kopieren.

Halte dich lieber an folgende Anleitung: http://blog.schalanda.name/archives/154 ... nSSH.html/

[startx]

Mir ist klar, dass jeder seine Shell dann braucht, die zu erlaubenden Binaries, die Verzeichnisstruktur (/dev, /etc, /tmp usw...).

Auch wenn chrrot jails inzwischen von ssh selbst unterstuetzt werden lohnt ein blick auf linux-vserver.

[pangu]

Danke. Ich schau mir grad die Anleitung an. Was mich immer wieder verwirrt ist dieser Eintrag in der sshd_config. Auch in diesem Tutorial steht man soll diese Zeile reinschreiben:

Subsystem sftp internal-sftp

In der Defaultinstallation von openssh-server ist jedoch der ähnliche Eintrag "Subsystem sftp /usr/lib/openssh/sftp-server" bereits vorhanden. Welchen soll ich also nutzen?

[pangu]

Es klappt leider nicht. Ich erstelle erst einen neuen User mit "adduser maxmustermann". In die /etc/ssh/sshd_config schreibe ich am Ende der Config:

Match User maxmustermann
ChrootDirectory /home/maxmustermann

speicher ab, und restarte mit /etc/init.d/ssh restart

Wenn ich mich nun mit "ssh maxmustermann@testmachine" einzuloggen versuchen, dann erhalte ich nach Passworteingabe den Fehler "Broken Pipe". Ich hab sowohl den standard-Eintrag belassen wegen diesem sftp-server, als auch den vom Tutorial probiert (den anderen zuvor auskommentiert)

[xdanx]

das chroot-directory muss root gehören. Durch folgenden Trick musst du aber nicht den Eintrag in /etc/passwd ändern:

erstelle in dem Homeverzeichnis nochmal die Hierarchie, d.h.:

Code: Alles auswählen

/home/maxmustermann/home/maxmustermann

alle Verzeichnisse bis inkl. /home/maxmustermann/home gehören root, nur das letzte Verzeichnis 'maxmustermann' gehört dem User maxmustermann.

Probier es mal so

EDIT:
Den Originaleintrag "Subsystem sftp internal-sftp" kannst du so belassen.

[pangu]

Jetzt krieg ich beim Anmeldeversuch den Fehler " /bin/bash: no such file or directory." Das verwirrt mich. Muss ich also im Unterverzeichnis von /home/maxmustermann die gesamte Filestruktur aufbauen, sprich inkl. /etc /proc /tmp /lib /bin Verzeichnisse, usw??? Ich dachte, dass erübrigt sich ja nachdem was ich in der Beschreibung zu den neuestens OpenSSH-Versionen las.

Was ich getan hab:

1.) adduser maxmustermann
2.) chown root /home/maxmustermann
3.) mkdir -p /home/maxmustermann/home/maxmustermann

in der sshd_config steht:

Subsystem sftp /usr/lib/openssh/sftp-server
#Subsystem sftp internal-sftp (habs auch damit probiert)

und ganz unten

Match User maxmustermann
ChrootDirectory /home/maxmustermann
AllowTCPForwarding no
X11Forwarding no

[uname]

Den Zugang auf sftp einzuschränken ist recht einfach. Eine geeignete chroot-Umgebung um z.B. nur eine Shell und darin "ls" zu erlauben habe ich trotz mehrmaligen Anlauf auch nicht hinbekommen. Die Frage ist ob mit der neuen openSSH-Version aus ca. 2008 (!!!) auch die Notwendigkeit weggefallen ist libpam-chroot zu nutzen.

Die Debian-Anleitung zu dem Thema (keine Ahnung ob veraltet)
http://www.debian.org/doc/manuals/secur ... nv.de.html

verlangt noch libpam-chroot. Wobei selbst die habe ich nicht ans Laufen bekommen. Aber vielleicht weiß jemand hier im Forum wie man heutzutage eine SSH-CHROOT-Umgebung (nicht sftp) baut.

[pangu]

Wie ich ja bereits im Ursprungpost schrieb, kann man das nach der genannten Anleitung durchführen. Es ist eigentlich simpel, ich beschreib hier nochmal eine 'nur' SSH-CHROOT Umgebung, ohne die SFTP-Geschichte:

1.) in die /etc/ssh/sshd_config kommt ans Ende rein:

Code: Alles auswählen

Match User maxmustermann
 ChrootDirectory /home/maxmustermann
 AllowTCPForwarding no
 X11Forwarding no

2.) Dann diese drei Pakete installieren:

Code: Alles auswählen

apt-get install sudo debianutils coreutils

3.) Die Chroot-Umgebung (also Ordnerstrukturen und Dateien) erstellen:
Du musst ja dem chrooted User die Binaries mitgeben, und auch die Filestruktur innnerhalb seiner chroot-Umgebung definieren. Da das ein mühsamen Unterfangen ist, gibt es ein fertiges Skript, dass du hier downloaden kannst (http://www.fuschlberger.net/programs/ss ... ot_jail.sh). Kopier es nach /usr/local/sbin und mache es ausführbar. Schau es dir mal in Ruhe an. Ich hab hier noch folgende Änderungen hinzugefügt, damit es auf Debian Squeeze 64bit auch funktioniert:

- Zeile 481+482 auskommentiert, damit es laut Beschreibung des Skript-Authors, die notwendigen libraries (/lib und /lib64) mitkopiert. Dazu habe ich die lib64-Zeile anpassen müssen, weil in meinem Squeeze die 64er libs unter /lib64 liegen und nicht /lib/lib64 wie im Skript steht. So habe ich das angepasst:

cp /lib/*.* ${JAILPATH}/lib/
cp /lib64/*.* ${JAILPATH}/lib64/

- in Zeile 118+119 (wenn Distro=Debian) habe ich noch in der Programmliste /bin/cat und /usr/bin/vi hinzugefügt, damit der chrooted Benutzer 'cat' und 'vi' nutzen kann. Das kannst du ja dann erweitern wie du Lust und Laune hast. Die in dieser Zeile angegeben Programme werden also der chroot-Umgebung für den ssh-User hinzugefügt, damit er sie nutzen kann.

3,5.) jetzt sollten wir laut Tutorial einen Softlink in /home erstellen:
cd /home
ln -s . home

ich verstehe aber nicht, WARUM? Es funktioniert auch ohne diesen Schritt, ich hab's ausprobiert. Bitte korrigiert mich falls ich falsch liege, aber ich versteh wirklich nicht den Hintergrund dieses Schrittes. Ich hab also keinen Softlink erstellt und diesen Schritt weggelassen.

4.) die /bin/bash sichern, warum siehst du gleich. Jetzt führen wir das Skript aus, um die chroot-Umgebung für den User zu erstellen:

Code: Alles auswählen

make_chroot_jail.sh maxmustermann /bin/bash /home/maxmustermann

Das Skript sagt, dass die /bin/bash bereits existiert und frägt ob man überschreiben möchte. Aus diesem Grunde habe ich sie mir vorher irgendwo hinkopiert (z.B. cp /bin/bash /bin/bash.bak). Ich bestätige mit 'yes'.
Das erstellt den Benutzer maxmustermann, gibt ihm die bash mit, kopiert die notwendigen Files in seine neue chroot-Umgebung und frägt nach dem zu vergebenden Passwort für den User. Es kommt eine Fehlermeldung:

cp: Aufruf von stat für „/lib/libcap.so.1“ nicht möglich: Datei oder Verzeichnis nicht gefunden

Ist aber kein Problem, da in meinem Fall ja die libcap.so.2 verwendet wird. Das skript versucht einfach alle zu kopieren, deswegen kommt die Fehlermeldung. Ist nicht relevant.

5.) SSH-Daemon neu starten mit "/etc/init.d/ssh restart"

Fertig. Der User kann sich nun anmelden und ist in seinem Verzeichnis gefangen.

Hoffe es hat dir geholfen,
viele Grüße...Pangu

[xdanx]

Match User maxmustermann
ChrootDirectory /home/maxmustermann
AllowTCPForwarding no
X11Forwarding no

Ich denke das sollte dann in dem Fall

Code: Alles auswählen

ChrootDirectory %h

heißen.

[uname]

Nichts gegen den Autor des Scriptes. Aber ich hatte gehofft, dass ich in einer offiziellen Debian-Anleitung eine Möglichkeit finde.

[marting]

Wenngleich der Beitrag schon fast ein Jahr auf dem Buckel hat, will ich mal was konstruktives beitragen. Das Skript gefiel mir nicht so recht, da es die Besonderheit ignoriert, die openssh ab 4.9 mitbringt. Es kopierte und legte mir für meine Zwecke zu viel an. Es reicht aber auch nicht aus, wie bei sftp (ForceCommand) nur den sshd zu konfigurieren.
Die Minimal Lösung sieht auf einem Squeeze System für mich folgendermaßen aus (sieht viel aus weil es ausführlich ist, geht aber sehr schnell):

Code: Alles auswählen

# sshd entsprechend konfigurieren
root:~# vim /etc/ssh/sshd_config
Match Group chroot
    ChrootDirectory /chroot
    AllowTCPForwarding no
    X11Forwarding no
Match
root:~# /etc/init.d/ssh reload

root:~# mkdir -p /chroot/bin
root:~# chmod 750 /chroot
root:~# groupadd chroot
root:~# chgrp chroot /chroot
root:~# useradd -d /chroot/myuser -m -g chroot -s /bin/dash myuser
root:~# passwd myuser
root:~# cd /chroot
root:/chroot# ln -s . chroot

root:~# cp -p /bin/dash /chroot/bin
# Beim nächste Schritt gibt es Unterschiede - abhängig, ob man in einer 32bit oder 64bit Umgebung unterwegs ist.
# Einfach den Kopf einschalten und ggf. die cp Kommandos anpassen. Muss man ohnehin, wenn eine andere Shell verwendet wird.
root@32bit:~# ldd /bin/dash
        linux-gate.so.1 =>  (0x...)
        libc.so.6 => /lib/i686/cmov/libc.so.6 (0x...)
        /lib/ld-linux.so.2 (0x...)
root@32bit:~# mkdir -p /chroot/lib/i686/cmov
root@32bit:~# cp -p /lib/i686/cmov/libc.so.6 /chroot/lib/i686/cmov
root@32bit:~# cp -p /lib/ld-linux.so.2 /chroot/lib
root@64bit:~# ldd /bin/dash
        linux-vdso.so.1 =>  (0x...)
        libc.so.6 => /lib/libc.so.6 (0x...)
        /lib64/ld-linux-x86-64.so.2 (0x...)
root@64bit:~# mkdir /chroot/lib /chroot/lib
root@64bit:~# cp -p /lib/libc.so.6 /chroot/lib
root@64bit:~# cp -p /lib64/ld-linux-x86-64.so.2 /chroot/lib64

# Nun sollte ein Connect schon möglich sein und alle dash Builtins sind möglich
someone@somewhere:~# ssh myuser@chroothost
myuser@chroothost's password:
$ pwd
/myuser
$ exit

# Nach Belieben kann man nun weitere Binaries kopieren, in meinem Fall nur Echo
root:~# cp -p /bin/echo /chroot/bin
# Man sollte noch prüfen, ob das Binary weitere Bibliotheken benötigt und diese ggf. noch kopieren.
root@32bit:~# ldd /bin/echo
        linux-gate.so.1 =>  (0x...)
        libc.so.6 => /lib/i686/cmov/libc.so.6 (0x...)
        /lib/ld-linux.so.2 (0x...)
# Im Fall von Echo ist das also nicht nötig. Wenn man es nicht prüft, wird man in der Regel aber auf fehlende Bibs aufmerksam gemacht:
root:~# cp -p /bin/ls /chroot/bin
$ ls -l
ls: error while loading shared libraries: libselinux.so.1: cannot open shared object file: No such file or directory
# Dann einfach noch kopieren

Ein paar Dinge will ich noch mal speziell erwähnen, über die ich und laut google viele andere gestolpert sind:
- Wer sich nicht sicher ist, sollte erstmal mit meiner Beispielkonfiguration anfangen und eigene Wünsche nachträglich anpassen. Wenn es erstmal funktioniert, ist vieles schon klarer. Die Umgebung ist schnell geändert oder wieder gelöscht.
- Es ist wichtig, dass /chroot und ggf. der Weg dorthin root gehört und von niemand sonst geschrieben werden kann
- Folglich kann ein User nie in sein eigenes Homeverzeichnis gepfercht werden, weil er dort Schreibzugang haben sollte, was wiederum nicht erlaubt ist.
- Der Match am Ende ist optional, verhindert aber, dass die chroot Konfiguration möglicherweise weiter geht, als man das eigentlich wollte. Wenn der Inhalt nur angefügt wird und danach nichts mehr kommt, ist er überflüssig.
- Ich habe absichtlich die Dash Shell genommen. Wer die Bash will, kann das auch tun, hat aber mehr Abhängigkeiten.
- Ob man die Binaries und libs nach einem Update von Hand nachkopiert oder sporadisch einen Cron laufen lässt, oder es völlig bleiben lässt, sei jedem selbst überlassen. Spätestens nach einem dist-upgrade sollte man die chroot Umgebung aber kontrollieren.
- Der relative Symlink /chroot/chroot auf /chroot hat mehrfach zu Verwirrung geführt. Der Grund ist aber ganz einfach: Wir haben als Homepfad /chroot/myuser angegeben. Absolut gesehen ist das auch richtig, aber in der chroot Umgebung gibt es diesen Pfad ohne Symlink nicht. Man kann sich auch ohne Symlink einloggen, startet dann aber im chroot Wurzelverzeichnis. Alternativ kann man den Homepfad auch auf die chroot Umgebung anpassen - das kann aber verwirren. Vor allem, wenn mehr als ein Admin auf der Maschine unterwegs ist.
- Fehlerbehebung:
a) /bin/dash: No such file or directory -> Vermutlich wurde die Shell noch nicht kopiert
b) /bin/dash: Permission denied -> Vermutlich hat die Gruppe chroot keine rx Rechte auf /chroot
c) Write failed: Broken Pipe -> Vermutlich hat jemand außer root Schreibrechte auf /chroot. Oder die sshd_config ist falsch.
- Im Zweifelsfall hilft es (wenn man die Möglichkeit hat), den SSH Daemon zu stoppen und mittels /usr/sbin/sshd -d zu starten. Er ist dann recht gesprächig und sagt auch dem Client, was nicht passt.

So, das war viel mehr, als ich eigentlich schreiben wollte, aber vielleicht hilft es ja mal jemandem.

Viele Grüße
Martin

[marting]

Hier noch ein kurzer Tree - man sieht also, dass wirklich nur drei Dateien benötigt werden, um sich einzuloggen.

Code: Alles auswählen

root@32bit:/# tree /chroot
/chroot
├── bin
│   ├── dash
│   └── echo   # optional
├── chroot -> .
├── myuser
└── lib
    ├── ld-linux.so.2
    └── libc.so.6

4 directories, 4 files

Edit: Noch ein Nachtrag: Der Symlink auf chroot ist in jedem Fall nötig, wenn der Benutzer 1. im richtigen Directory starten soll und 2. ssh authentication keys verwenden soll.