LINUX: scponly und /etc/shells

[Tom]

Hello,

ich hatte da im Mai 2008 schon mal eine Runde eingelegt in einer ähnlichen Angelegenheit. Damals sollte ein Server so abgesichert werden, dass die User eine Shell bekommen können, aber in einer gesicherten chroot-Umgebung (Jail) gefangen bleiben. Hintergrund war die Abschaffung ds unsicheren ftp-Protokolls, weil sensible Daten übertragen werden.

Nun habe ich den Fall, dass nur ein Filetransfer notwendig ist. Aus dem damaligen Thread habe ich den Tipp von Jens behalten: scponly.

Nun bin ich in diesem Zusammenhang erst auf die

/etc/shells: valid login shells

/bin/csh
/bin/sh
/usr/bin/es
/usr/bin/ksh
/bin/ksh
/usr/bin/rc
/usr/bin/tcsh
/bin/tcsh
/usr/bin/esh
/bin/bash
/bin/rbash
/usr/bin/scponly

gestoßen. Hier eine von einem unserer Testserver im College.

Welche Shells kann oder sollte ich rausschmeißen?
Die User auf meinem Server verwenden ausschließlich die bash. Das ist so vorgeschrieben, damit die Scripte einheitlich bleiben, auch wenn man vielleicht ein paar Möglichkeiten verschenkt. Bisher hat das gereicht.

Die scponly-Kandidaten brauch nun zusätzlich die scponly, das ist klar.

Aber welche Gründe könnte es noch für die übrigen Shells geben?
Irgendwelche Dienste, die da was verlangen dürfen?

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[Multi]

Mahlzeit,

Aber welche Gründe könnte es noch für die übrigen Shells geben?

Keinen, wenn die bash für Scripte vorgeschrieben ist.

Irgendwelche Dienste, die da was verlangen dürfen?

Ich wüsste keinen, ausser besondere Shellscripte. Die fallen aber, nach deiner Aussage, aus.

[Tom]

Hello,

Ich wüsste keinen, ausser besondere Shellscripte. Die fallen aber, nach deiner Aussage, aus.

Also schaue ich vorher in die /etc/passwd, was für die wichtigen User als Shell eingetragen ist und wenn dann dort nicht dummerweise eine ander Shell steht, als die vorgeschriebene, dann kommentiere ich die anderen Shells aus und starte neu oder rufe Source auf. Spätestens danach sollten die "falschen" Shells abgelehnt werden.

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[Jens Holzkämper]

Tach,

Welche Shells kann oder sollte ich rausschmeißen?

alle von denen du nicht willst, dass die User mit chsh sie als Login-Shell festlegen.

Aber welche Gründe könnte es noch für die übrigen Shells geben?

Das übliche "it's all about choices", wenn jemand lieber korn statt bash mag, soll er sie halt bekommen.

Irgendwelche Dienste, die da was verlangen dürfen?

Nein, es könnte allerdings Programme geben, die versuchen, ob der ausführende User eine gültige Login-Shell nutzt indem sie die aktuell laufende mit denen in /etc/shells abgleichen.

mfg
Woodfighter

[Tom]

Hello Jens,

ich hoffe, Du liest das nochmal hier.
Ich stelle mich hoffentlich nur zu blöd an, wenn ich die scponly-Geschichte nicht zum Laufen bringe.

Kannst Du mir ein paar Meilensteine geben?
Also mit apt-get lässt sich das Paket scponly sogar inzwischen installieren, aber was muss ich die Shell auch benutzen kann?

Was muss ich noch alles im Home-Dir des Users unterbringen?

Am liebsten wäre mir, wenn die scponly-User ein gemeinsames "Home" haben, in dem aber jeder noch ein Verzeichnis hat, auf das nur er (und die Dozenten) Zugriff haben.

Dann benötigen wir ein Upload-Dir, in dem man keine Dateien überschreiben darf und eins, was ganz odden für alle User ist, sowie ein Download-Dir, das für alle nur lesbar ist.

Lässt sich das mit verhältnismäßig geringen Mitteln einrichten mit scponly?

Es steht zur Ergänzug ja auch immer noch der Webserver zur Verfügung zum Downloaden...

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[Multi]

Mahlzeit,

ich heisse zwar nicht Jens, antworte aber trotzdem mal.

Am liebsten wäre mir, wenn die scponly-User ein gemeinsames "Home" haben, in dem aber jeder noch ein Verzeichnis hat, auf das nur er (und die Dozenten) Zugriff haben.

Dann gib diesen Usern als Home eben das eigene Unterverzeichnis. Und der Dozent hat dann als Homeverzeichnis das Verzeichnis darüber.

Dann benötigen wir ein Upload-Dir, in dem man keine Dateien überschreiben darf

Dann lass nach dem Upload die Rechte entsprechend setzen.

und eins, was ganz odden für alle User ist, sowie ein Download-Dir, das für alle nur lesbar ist.

Das ist alles nur eine Sache der richtigen Rechte

Lässt sich das mit verhältnismäßig geringen Mitteln einrichten mit scponly?

Hat mit scponly nicht wirklich was zu tun. Diese Shell hat nur den Effekt, dass die einzige Loginmethode per SCP möglich ist. Alles andere ist Serversache unabhängig von der verwendeten Shell.

http://www.cargal.org/drupal/node.php?id=414
http://b0rken.de/index.php?/archives/7-scponly-im-chroot-unter-Debian-Etch.html
http://basler.netsession.info/wordpress/2008/10/scponly-mit-chroot-unter-debian-etch

Das sind die ersten drei Links, wenn ich bei Google nach "scponly debian" suche und die sollten die alle helfen können ;)

Das ist aber keine Arbeit auf 5 Minuten. Serversicherheit ist immer Zeitraubend.

[Tom]

Hello,

warum es nicht funktioniert, habe ich nun entdeckt.

Die scponly Shell muss mit der Option --enable-chrooted-binary kompiliert werden.
Das Paket von Debian berücksichtigt dies aber nicht.

Serversicherheit ist immer Zeitraubend.

Das sieht so aus. Man muss nämlich erst herausfinden, ob das Pekt brauchbar ist und es dann doch selber kompilieren. Dazu muss ich es jetzt erstmal suchen. Und ich dachte, das Konzept sei so ausgereift, dass Debian daraus eine "Fünfminutenlösung" gemacht hätte, so wiw man es von anderen Modulen gewohnt ist.

Ich schreibe nochmal, wenn es geklappt hat!

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[Tom]

Hello,

Ich schreibe nochmal, wenn es geklappt hat!

Neu kompiliert mit Optionen, gejlappt hat es noch nicht. Aber zumindest bekomme ich jetzt kurzzeitig Kontakt.

Leider kann sich der User noch noch nicht wirklich anmelden.
Ich muss erst mal die zugehörigen Logs suchen, ob man daraus erkennen kann, was ich vergesse habe.

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[Tom]

Hello,

Leider kann sich der User noch noch nicht wirklich anmelden.
Ich muss erst mal die zugehörigen Logs suchen, ob man daraus erkennen kann, was ich vergesse habe.

Ich habe weder in /var/log/syslog, noch in /var/log/messages, noch in /var/log/daemon.log Eintragungen  gefunden...

Stattdessen bekomme ich am Client (WinSCP)immer die Meldung

"Die Verbindung wurde unerwartet geschlossen. Der Server sendete den Befehlsbeendigungsstatus 1."

Ich finde den Fehler nicht, den ich gemacht habe. Dabei hörte isch alles soooo einfach an.
Da war ja unter dem Strich das Patchen des sshd einfacher, wonach man dann durch einfaches Einsetzen eines Punktes /./ in den Pfad des Homedirs die Chroot-Umgebung festlegen konnte...

Leider habe ich die Unterlagen dafür zuhause im Harz gelassen ;-((

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[Multi]

Mahlzeit,

Ich finde den Fehler nicht, den ich gemacht habe. Dabei hörte isch alles soooo einfach an.

Starte mal den SSH-Server im Terminal im Verbose-Mode. Dann hast du die Debugmeldungen direkt am Monitor.
Wenn du per inetd oder init-Script startest, werden oft Meldungen nach /dev/null geleitet und nicht ins Syslog.

Also einfach mal ein

/etc/init.d/ssh stop

dann ein

/usr/sbin/sshd -d

voller Pfad ist nötig, sonst meckert der sshd ;)
Wenn du da keine Ausgabe beim Verbinden bekommst, dringt WinSCP schon gar nicht dahin durch sondern wird vorher schon geblockt.

[Tom]

Hello,

Ich finde den Fehler nicht, den ich gemacht habe. Dabei hörte isch alles soooo einfach an.

Starte mal den SSH-Server im Terminal im Verbose-Mode. Dann hast du die Debugmeldungen direkt am Monitor.
Wenn du per inetd oder init-Script startest, werden oft Meldungen nach /dev/null geleitet und nicht ins Syslog.

Also einfach mal ein

/etc/init.d/ssh stop

dann ein

/usr/sbin/sshd -d

voller Pfad ist nötig, sonst meckert der sshd ;)
Wenn du da keine Ausgabe beim Verbinden bekommst, dringt WinSCP schon gar nicht dahin durch sondern wird vorher schon geblockt.

OK. Das versuche ich nachher mal.
Mich verwundert, dass ich überhaupt keine Meldungen in den Logs finden konnte bisher.

Wenn ich mich mit einem User anmelde, der die bash benutzt, komme ich mit WinSCP und/oser dem SSH-Client zum Ziel. Aber DER kann dann ja über die ganze Platte eiern und außerdem Befehle absetzen.

Ich muss also irgendwas mit der scponlyc-Shell falsch gemacht haben, obwohl ich es inzwischen dreimal nach drei verschiedenen Anleitugen nachvollzogen habe. Die sind im Prinzip auch alle gleich; es hat nur jeder irgendetwas vergessen... Vielleicht brauche ich jetzt einfach noch die vierte Anleitung dazu ;-)

Kommt mir langsam vor, wie ein Puzzlespiel.

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[Multi]

Mahlzeit,

Kommt mir langsam vor, wie ein Puzzlespiel.

Das gibt es im Serverbereicht, vorallem, wenn es um Sicherheit geht, sehr oft.
Da ist Debian keine Ausnahme, eher ist es so, dass bei Debian die HowTos noch am besten sind ;)

Ich hatte ein ähnliches Problem mit ner Chroot-Umgebung. Da war der Fehler in einer Zwischenschicht, dass er nicht beim Starten angezeigt wurde aber auch nicht im Syslog landete. Da wird das Debugging extrem schwer.

[Tom]

Hello,

Kommt mir langsam vor, wie ein Puzzlespiel.

Das gibt es im Serverbereicht, vorallem, wenn es um Sicherheit geht, sehr oft.

Deinen Tipp mit dem Debug habe ich nun befolgt. Das sah auf den ersten Blick ganz klasse aus. Ich dachte, *hups* da habe ich doch galtt wieder mal vergessen, den sftp-server in die chroot-Umgebung zu kopieren. Nachgeholt, nochmal probiert, aber es läuft immer noch nicht...

Ich stelle nun doch mal das Debug-Log hier herein, weil ich einfach nicht weiß, wo ich noch suchen soll.

debian4:~# nl ssh_debug
     1  debian4:/# /etc/init.d/ssh stop
     2  Stopping OpenBSD Secure Shell server: sshd.
     3  debian4:/# /usr/sbin/sshd -d
     4  debug1: sshd version OpenSSH_4.3p2 Debian-9etch3
     5  debug1: read PEM private key done: type RSA
     6  debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
     7  debug1: private host key: #0 type 1 RSA
     8  debug1: read PEM private key done: type DSA
     9  debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
    10  debug1: private host key: #1 type 2 DSA
    11  debug1: rexec_argv[0]='/usr/sbin/sshd'
    12  debug1: rexec_argv[1]='-d'
    13  debug1: Bind to port 22 on ::.
    14  Server listening on :: port 22.
    15  debug1: Bind to port 22 on 0.0.0.0.
    16  debug1: Server will not fork when running in debugging mode.
    17  debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7
    18  debug1: inetd sockets after dupping: 3, 3
    19  Connection from 192.168.178.48 port 1477
    20  debug1: Client protocol version 2.0; client software version WinSCP_release_4.1.8
    21  debug1: no match: WinSCP_release_4.1.8
    22  debug1: Enabling compatibility mode for protocol 2.0
    23  debug1: Local version string SSH-2.0-OpenSSH_4.3p2 Debian-9etch3
    24  debug1: permanently_set_uid: 106/65534
    25  debug1: list_hostkey_types: ssh-rsa,ssh-dss
    26  debug1: SSH2_MSG_KEXINIT sent
    27  debug1: SSH2_MSG_KEXINIT received
    28  debug1: kex: client->server aes256-ctr hmac-sha1 none
    29  debug1: kex: server->client aes256-ctr hmac-sha1 none
    30  debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received
    31  debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
    32  debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
    33  debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
    34  debug1: SSH2_MSG_NEWKEYS sent
    35  debug1: expecting SSH2_MSG_NEWKEYS
    36  debug1: SSH2_MSG_NEWKEYS received
    37  debug1: KEX done
    38  debug1: userauth-request for user jsteffen service ssh-connection method none
    39  debug1: attempt 0 failures 0
    40  debug1: PAM: initializing for "jsteffen"
    41  Address 192.168.178.48 maps to pc48.local, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
    42  debug1: PAM: setting PAM_RHOST to "192.168.178.48"
    43  debug1: PAM: setting PAM_TTY to "ssh"
    44  Failed none for jsteffen from 192.168.178.48 port 1477 ssh2
    45  Failed none for jsteffen from 192.168.178.48 port 1477 ssh2
    46  debug1: userauth-request for user jsteffen service ssh-connection method password
    47  debug1: attempt 1 failures 1
    48  debug1: PAM: password authentication accepted for jsteffen
    49  debug1: do_pam_account: called
    50  Accepted password for jsteffen from 192.168.178.48 port 1477 ssh2
    51  Accepted password for jsteffen from 192.168.178.48 port 1477 ssh2
    52  debug1: monitor_child_preauth: jsteffen has been authenticated by privileged process
    53  debug1: PAM: reinitializing credentials
    54  debug1: permanently_set_uid: 1004/1004
    55  debug1: Entering interactive session for SSH2.
    56  debug1: server_init_dispatch_20
    57  debug1: server_input_channel_open: ctype session rchan 256 win 65536 max 16384
    58  debug1: input_session_request
    59  debug1: channel 0: new [server-session]
    60  debug1: session_new: init
    61  debug1: session_new: session 0
    62  debug1: session_open: channel 0
    63  debug1: session_open: session 0: link with channel 0
    64  debug1: server_input_channel_open: confirm session
    65  debug1: server_input_channel_req: channel 0 request subsystem reply 1
    66  debug1: session_by_channel: session 0 channel 0
    67  debug1: session_input_channel_req: session 0 req subsystem
    68  subsystem request for sftp
    69  debug1: subsystem: exec() /usr/lib/openssh/sftp-server
    70  debug1: Received SIGCHLD.
    71  debug1: session_by_pid: pid 3600
    72  debug1: session_exit_message: session 0 channel 0 pid 3600
    73  debug1: session_exit_message: release channel 0
    74  debug1: session_by_channel: session 0 channel 0
    75  debug1: session_close_by_channel: channel 0 child 0
    76  debug1: session_close: session 0 pid 0
    77  debug1: channel 0: free: server-session, nchannels 1
    78  Connection closed by 192.168.178.48
    79  debug1: do_cleanup
    80  debug1: PAM: cleanup
    81  Closing connection to 192.168.178.48
    82  debug1: PAM: cleanup
    83  debian4:/#

Spannend sind mMn erst die Zeilen ab Zeile 67.
Was soll ich von einem SIGCHLD halten?

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[Multi]

Mahlzeit,

Was soll ich von einem SIGCHLD halten?

Ist jetzt ne pure Vermutung.
Das Startscript des SSHd startet per exec() den sftp-Server, der damit ein Child ist.
Das SIGCHLD ist dann das Signal des sftp an den sshd, vermutlich weil irgendwas nicht passt.

Ich weiss nicht, wo du anfangen solltest zu suchen, aber ich würde sagen, der sftpd nimmt keine Verbindungen an und deshalb trennt der sshd die Verbindung wieder.

Versuch doch mal, den sftpd als Daemon zu starten und nicht per sshd oder inetd. Dann kannst du ihn ebenfalls im Debugmode starten und die Bildschirmmeldungen verfolgen.

[Tom]

Hello,

kleine Zwischennachricht:

Der LPI-II-Kurs aus dem Haus hat es zumindest auf Linux-2-Linux-Ebene hinbekommen, dass es funktionioert, allerdings auch nicht nach den üblichen Anleitungen aus dem Internet, sondern mit einigen eigenen Anstengungen... Scheint also doch nicht so trivial zu sein, wie es beschrieben wird.
Es fehlten diverse Bibliotheken in der chroot-Umgebung.

Ich habe nun die entstandenen Verzeichnisse und Files als Tarball.

Wenn ich die verglichen habe mit meinen Anstrengungen und dem offiziellen Installationsscript für scponly-User, und es auch bei mir funktioniert zwischen Linuxserver und Windows-SCOP-Client, dann werde ich versuchen, das notwendige Vorgehen hier nochmal zu dokumentieren.

Liebe Grüße aus Syburg bei Dortmund
Ab Sonntag erstmal Region Hamburg für ein paar Wochen...

Tom vom Berg