OpenSSH chrootdirectory + Public key Authentifizierung

[Marvho]

Hallo zusammen,

undzwar stehe ich vor folgendem Problem.


Ich habe meinen OpenSSH Dienst auf meinem Debian 6.0 Root Server so eingerichtet, dass ein login nur per Public Key und Passphrase möglich ist. Soweit so gut. Nun wollte ich für die jeweiligen Benutzer, über die ich z.B meinen CSS Server starte, ein chrootjail einfügen. Da OpenSSH ab der Version 4.9 bzw. 5.0 und höher das schon von Haus aus kann, dachte ich mir, teste ich es einfach mal. Nachdem ich dann den Home Ordner des Users dem User Root übergeben habe, die Benutzergruppe sftp dem Benutzer zugeordnet habe und die Gruppe dem Ordner zugeordet habe und anschließend noch die sshd_config angepasst habe, war soweit alles fertig.

Ich probierte mich nun, nach einem neustart des ssh daemons, als den eingerichteten Benutzer einzuloggen. Ich werde aufgefordert meine Passphrase einzugeben, gebe ich diese richig ein, so schließt sich sofort das Terminal. In der Auth.Log steht nichts ungewöhnliches drin, bloß "Accepted publickey for ****** from ********* port ******** ssh2"

Woran kann das Problem liegen? Ich bekomme ja keine Fehlermeldung oder sonstiges.

Danke im Voraus und schönen Abend noch!

Viele Grüße

Marvho

[Cae]

Gibt's im chroot eine Shell? Das und weitere Ansprueche stehen auch unter dem Punkt ChrootDirectory in sshd_conf(5).

Willkommen im Forum!

Gruss Cae

[uname]

Ich möchte dich nicht verunsichern. Aber eigentlich musst du zwischen echter Shell, sftponly und scponly (nicht in Wheezy) unterscheiden. Was soll der Anwennder dürfen? In seinem Verzeichnis seine Daten ändern? Kein Mensch braucht dafür eine Shell. Konfiguriere entsprechend "sftponly" in /etc/ssh/sshd_config. Wenn du wirklich eine Shell willst so frage ich mal was er damit soll? Soll er dort mit dem Vim editieren können? Dann wirst du Vim und alle abhängigen Bibliotheken in einer chroot-Umgebung nachbauen müssen. Viel Spaß. Oder soll er Prozesse direkt oder indirekt neu starten können? Da würde ich dann wohl eher eine Art Restricted-Shell mit entsprechenden Befehlen zusammenbauen.

[Marvho]

Danke für eure schnellen Antworten!

Ich habe mich glaube ich etwas vertan was das chrootdirectory angeht. Ich wollte die Benutzer halt soweit einschränken, dass sie nur eine Screen Session aufmachen können um den Server halt im Hintergrund laufen zu lassen und natürlich eventuell abgestürzte Server neustarten können, falls mal eine Screen Session hängen bleibt. Mehr müssen die Benutzer "eigentlich" nicht können. Was mir halt eigentlich am wichtigsten war, dass die Benutzer nicht aus Ihrem Home Directory raus können. Und die Shell ist ja leider notwendig bei Screen, weil ich per "su" nicht auf die Screen Sessions von anderen Benutzern zugreifen kann um mir direkten Zugriff auf die Console zu geben.

[Cae]

Und die Shell ist ja leider notwendig bei Screen, weil ich per "su" nicht auf die Screen Sessions von anderen Benutzern zugreifen kann um mir direkten Zugriff auf die Console zu geben.

Das ist falsch. Man kann sehr wohl den screen eines anderen Users attachen, wenn man per su zu diesem geworden ist. Es scheitert bei dir vermutlich daran, dass die screen-Session (laeuft als userb) nicht auf dein Terminal (was immer noch usera gehoert) schreiben darf. Das Problem kann man aber per chmod oder schoener chmod/chown aus der Welt schaffen.

Gruss Cae

[Marvho]

Das Problem kann man aber per chmod oder schoener chmod/chown aus der Welt schaffen.

Gruss Cae

Hallo Cae,

da hast du natürlich recht. Nur jedesmal das ganze für die User per chmod / chown zu ändern ist auch etwas lästig, und kann das nicht auch ein paar Risiken mit sich bringen?

[uname]

Die Screen-Option ist "-x" bzw. Multiuser. Musst mal nach suchen. su brauchst du dann wirklich nicht.

[Marvho]

Die Screen-Option ist "-x" bzw. Multiuser. Musst mal nach suchen. su brauchst du dann wirklich nicht.

Hey uname,

die Option gilt nur für das attachen an eine bereits vorhandene Screen Session wo sich bereits ein Benutzer aufgeschaltet hat, habe es gerade mal getestet, es gibt wohl auch keinen Startparameter "-x" .


Hier sind meine Versuche (Beispiel anhand eines Minecraft Servers)

User Minecraft gibt folgendes in den Terminal ein: screen -A -m -d -S MCServer java -Xmx1G -Xms1G -jar craftbukkit152.jar

Server startet wie gewohnt im Hintergrund per Screen.

Nun wollte ich als User root, der per su zu minecraft geworden ist, an diesen Screen attachen kommt diese Meldung : Cannot open your terminal '/dev/pts/0' - please check.

Nun will ich per su den Minecraft Server als Benutzer root starten, um eventuell das Problem zu umgehen : su - minecraft -c 'screen -A -m -d -S MCServer java -Xmx1G -Xms1G -jar craftbukkit152.jar'

Dann kommt keine Fehlermeldung, es passiert aber auch zugleich nichts, der Server startet nicht.

[Cae]

Nun will ich per su den Minecraft Server als Benutzer root starten, um eventuell das Problem zu umgehen : su - minecraft -c 'screen -A -m -d -S MCServer java -Xmx1G -Xms1G -jar craftbukkit152.jar'

Nein, das willst du absolut nicht.

Der gescheite Weg waere, sich direkt als der Benutzer einzuloggen, der die screen-Session haelt. Als Workarround koennte man, wie schon erwaehnt, die Berechtigungen des TTY' aendern, damit der unpreviligierte Benutzer es beschreiben darf:

Code: Alles auswählen

# alias mcscreen='chown minecraft $(tty); su -lc "screen -dr MCServer" minecraft'
# mcscreen

Das ist unsauber, aber ein moeglicher Weg.

Aber eigentlich ging's hier mal um deinen kaputten chroot, und an dieser Stelle solltest du weiter forschen. Nochmal meine Frage: Gibt's im chroot eine Shell, funktioniert

Code: Alles auswählen

# chroot /home/minecraft /bin/sh

? Entsprechende Bibliotheken braucht's auch im chroot, plus das Java-Geraffel.

Gruss Cae

[Marvho]

Hey Cae,

ja das stimmt, mein eigentliches Ziel schweift etwas ab, dennoch sind es genau die Faktoren, die mich eigentlich zu diesem Ziel bringen. Ich brauche die Shell nur um mir Consolen Rechte zu verschaffen, oder einen gecrashten / hängen gebliebenen Server neu-/ -zu starten. Soweit ich nun geforscht habe sind ja meine Kentnisse über das implementierte ChrootDirectory etwas falsch gewesen. Weil man damit, soweit wie ich das nun verstanden habe, eine SFTP Verbindung ohne Shell einrichten um einen verschlüsselten Datentransfer ablaufen zu lassen. Da dies nicht mein Ziel ist, werde ich wohl woanders nach einer Lösung zu meinem eingesperrten Home Verzeichnis suchen müssen. Ich bedanke mich für Eure Beiträge und werde mal weiter forschen.

[Cae]

Was mir halt eigentlich am wichtigsten war, dass die Benutzer nicht aus Ihrem Home Directory raus können.

(Zitat aus dem zweiten Post)
Das ist nur a) per chroot oder b) per selbstgestrickter Shell, die gar keinen Dateizugriff zulaesst, zu erreichen. Man kann per chrootDirectory einen Benutzer einsperren, und das koennte man eben auch fuer SFTP machen. SFTP ist aber vollkommen irrelevant fuer deinen Anwendungsfall, du willst keine Dateien durch die Landschaft schieben, sondern Befehle ausfuehren.

Gruss Cae

[uname]

Ich wiederhole mich. Vielleicht eine Restricted-Shell mit wenigen Befehlen und falls nötig mit "screen" und "sudo".

[Marvho]

Hallo zusammen,

Nun versteh ich aber immer noch nicht, ob die eingebaute ChrootDirectory in OpenSSH mir bei meinem Problem helfen könnte? Ich bin etwas verwirrt :S Da ich nicht unbedingt darauf aus bin "nur" befehle ausführen zu wollen, wäre die Möglichkeit ja nicht ausgeschlossen, das per ChrootDirectory von OpenSSH zu machen, falls dies halt möglich ist. Sprich eine Shell erlauben, die aber nur in dem Home Verzeichnis des Users gilt, wie gesagt, eine Art Restricted-Shell.

//edit: Ach so, nun habe ich es glaube ich verstanden, das ChrootDirectory beinhaltet nur SFTP, sprich Dateien verschieben, und keine Möglichkeit Befehle auszuführen, oder?

[uname]

Wenn Chroot-Umgebung musst du alles inkl. Bibliotheken und Programme nachbauen.