Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: Linux Forum Linux-Web.de. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

1

12.06.2009, 09:03

mehrfach sftp / ssh installieren ?

Hallo,

ich habe es geschafft, eine funktionierende chroot anzulegen.
Der normale Login (direkt an der Konsole) und der Login via SSH (PW) funktionieren ebenfalls.

Nun dachte ich, kann ich auch bequem per SFTP (WinSCP) zugreifen, aber es wird keine Verbindung aufgebaut.

WinSCP meint "ist auf der anderen Seite ein SFTP-Server aktiv ?"-

Hmm, am Rechner selbst: ja ! Andere SFTP-Logins (in normaler Shell) funktionieren auch.

Dann fiel mir ein "klar, kann ja nicht gehen, habe ja in der chroot nur limitierte Libs/Binaries drinnen.

Jetzt ist mir nicht klar, ob ich in der chroot so einfach einen sftp-Dienst installieren kann, weil

- Bash ja nicht wissen kann, welchen sftp es für welchen Login nehmen soll
- die beide evtl. auf unterschiedlichen Ports lauschen müssten
- ob ich bei der Installation eines zweiten sftp mein System (die Konfig) so schrotten kann, das gar nichts mehr geht

und last but not least

a) muss ich den -wenns möglich ist - in den /bin /etc des chrootet shell installieren und dann über das init.d mit hochfahren lassen, oder
b) ebenfalls in die Haupt bin-Verzeichnisse und über init.d starten ?

Was Brauchbares dazu habe ich im Netz leider nicht gefunden, daher mal wieder eine Bitte:

Geht es prinzipiell,
ist Option a) oder Option b) der richtige Weg ?

Vielen Dank
Mike

linuxerr

Prof. Dr. Schlaumeier

  • »linuxerr« ist männlich

Beiträge: 8 557

Wohnort: Mecklenburg, zur Entwicklungshilfe in Chemnitz/Sachsen ;-)

  • Nachricht senden

2

12.06.2009, 13:02

RE: mehrfach sftp / ssh installieren ?

eine mehrfache installation ist eigentlich unnötig. es müsste ausreichen, wenn du links (am besten hardlinks) auf die installierten binaries und libs legst. das mache ich zb für diskless-clients genauso. das system wird einmal installiert und dann in die chroot-umgebung des jeweiligen clienten hineingelinkt. hardlinks sind da auf alle fälle geeigneter, da softlinks in der chroot-umgebung wohl nicht funktionieren. dazu muss jedoch alles auf einem plattendevice liegen, sonst funktionieren hardlinks nicht.
Die Rechtschreibfehler in diesem Beitrag sind nicht urheberrechtlich geschützt.
Jeder der einen findet darf ihn behalten und in eigenen Werken weiterverwenden.

3

12.06.2009, 13:35

Hallo,

leider kein Erfolg :-(
Ich habe in den /usr/bin des chroots hardlinks zu
/usr/bin/sftp
und in den /lib-Verzeichnis hardlinks zu den von ldd angegebenen Dateien gemacht.

Keine Änderung beim Loginverhalten via winSCP. Erkennt imemr noch keinen entspr. Server.

Habe dann zwecks Übung die Originalfiles exakt 1:1 (Locations) in die chroot kopiert.
Dto. - no login.

Auffallend war: es wird rein gar nichts in die Logfiles geschrieben, beim Loginversuch.
Bei anderen - nicht gechrooteten Usern - sind die Infos ganz normal im Log.

Gleiches Spiel nochmal mit dem Kopieren, diesmal aber einen anderen Namen vergeben (ch_sftp) - der lässt sich komischerweise starten, ist aber via ps nicht in der Prozessliste drinnen, nicht mal als zombie.

Ja, gleiches Spiel wie mit den Email-Zertifikaten:
über selbst generierte Zerts funktioniert mit openssl alles einwandfrei, nur bei den Verisign klappt es einfach nicht.

Hab scheinbar kein glückliches Händchen .

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »MIKE bt« (12.06.2009, 13:36)


linuxerr

Prof. Dr. Schlaumeier

  • »linuxerr« ist männlich

Beiträge: 8 557

Wohnort: Mecklenburg, zur Entwicklungshilfe in Chemnitz/Sachsen ;-)

  • Nachricht senden

4

12.06.2009, 13:57

mir ist ja nicht ganz klar, was du machst, aber grundsätzlich mal:
wenn du auf einem server mehrere (virtuelle) umgebungen zu laufen hast und jede soll einen sftp zugang (oder was auch immer haben), dann gibt es nur zwei möglichkeiten
1. jede umgebung hat ihren eigenen serverprozess, dann müssen die jedoch alle auf unterschiedlichen ports laufen und ständig aktiv sein. das ist nicht besonders effizient.
2. es läuft auf dem gerät ein serverprozess und der zwingt die user nach ihrem login in ihre chroot umgebung. das ist wohl die sinnvollere alternative. die binaries müssen dann auch nict teil der chroot-umgebung sein.
Die Rechtschreibfehler in diesem Beitrag sind nicht urheberrechtlich geschützt.
Jeder der einen findet darf ihn behalten und in eigenen Werken weiterverwenden.

5

12.06.2009, 14:59

Ist ein ganz normales LAMP-System.

Konsolenlogin für alle Benutzer, ganz normale Shell.
FTP-Login über eine gechrootete Shell,
SSH-Login via sshd, auf eine Benutzergruppe beschränkt, aber normale Shell
SFTP (meist via WinSCP) analog zu SSH - gleiche Rechte/Einschränkungen.

Mein Vorhaben:
nur einer dedizierten Usergruppe sftp erlauben, diese in eine chroot setzen.
Chroot-Installation klappt, ssh-Login und Konsolenlogin führt in die chroot, mit allen dort vorhandenen Bins.
Nun - so mein Gedankengang - sollten diese User, wenn sie nicht per SSH sondern SFTP kommen, die gleiche Prozedur durchlaufen.
Aber: WinSCP connected nicht - "kein SFTP-Server aktiv"

Meine Lösung: Aha, kann nicht gehen, sftp wird ja (wahrscheinlich) erst nach der SSH-Loginprüfung aktiviert, da dann die User aber schon in der chroot sind, brauchen sie dort einen sftp-dienst.

Dein Hinweis:
habe dann a) Hardlinks der sftp-Komponenten b) die files 1:1 direkt kopiert, c) wie b aber unter anderem Namen kopiert.
Methode a+b: keine Änderung
Methode c: ch_sftp startet, aber wird scheinbar nicht aktiv (ps-Prüfung).
Ebenfalls kein Login, zusätzlich keine Einträge in den Logfiles.

Da setzt es jetzt von der Logik bei mir aus, denn die originalen Dienste sftp und ssh sind ja nach wie vor aktiv und sollten dann doch wenigstens beim SSH-Logfile einen Eintrag generieren.

Das Verhalten kommt mir vor wie:
ich mache ls -l -> alles geht
ich kopiere die /bin/cat in das gleiche Verzeichnis, ls -l => command not found.
Das kann es aus meiner Sicht nicht geben, aber eben das mit dem sftp-Verhalten auch nicht.

:+++: :keineahnung:
sshd_conf: Subsystem sftp /usr/lib/ssh/sftp-server

kann es sein, dass ich hier noch zusätzlich den 2. sftp-server in der chroot eintragen muss ?
aber unter welcher Kennung ? Subsystem ist ja schon vergeben ?

6

12.06.2009, 15:07

hab da noch was geunden:

sshd_conf:

...
#Match Group sftponly
# ChrootDirectory /JAIL/%u
# ForceCommand /usr/bin/ch_sftp
# X11Forwarding no
# AllowTcpForwarding no

Das hörte sich gut an, aber mein sshd startet dann nicht mehr, er kennt MATCH nicht.
Lt. Google sollte aber schon seit den späteren 3er Versionen diese Direktive bekannt sein.
Ich habe OpenSSH_4.2p1.

strcat

Unix Gladiator

  • »strcat« ist männlich

Beiträge: 2 331

Wohnort: /Earth/Germany/Bavaria/Regensburg

  • Nachricht senden

7

12.06.2009, 15:33

Zitat

Original von MIKE bt
hab da noch was geunden:

sshd_conf:

...
#Match Group sftponly
# ChrootDirectory /JAIL/%u
# ForceCommand /usr/bin/ch_sftp
# X11Forwarding no
# AllowTcpForwarding no

Das hörte sich gut an, aber mein sshd startet dann nicht mehr, er kennt MATCH nicht.
Lt. Google sollte aber schon seit den späteren 3er Versionen diese Direktive bekannt sein.
Ich habe OpenSSH_4.2p1.

"Match Group sftponly" ist ein Kommentar und keine Directive; lies sshd_config(5).
Christian 'strcat' Schneider <http://www.strcat.de/>
/* When all else fails, read the instructions. */

8

12.06.2009, 15:52

in meinen ganzen man sshd und man sshd_config finde ich nichts zu Match.
lediglich Subsystem ist erklärt.

Die Kommentarzeichen im posting stammen von mir, habe es in meiner _conf wieder auskommentiert, nachdem es sshd startffehler gegeben hat.

strcat

Unix Gladiator

  • »strcat« ist männlich

Beiträge: 2 331

Wohnort: /Earth/Germany/Bavaria/Regensburg

  • Nachricht senden

9

12.06.2009, 16:23

Die sshd_config(5) gibt es auch online; was wirklich helfen wuerde, waere die exakte Fehlermeldung. Ich tippe mal darauf das "Match" nicht als letzte Direktive aufgefuehrt wurde bzw. die Gruppe "sftponly" nicht existiert.
Christian 'strcat' Schneider <http://www.strcat.de/>
/* When all else fails, read the instructions. */

10

13.06.2009, 05:55

Als letzte Anweisung war es nicht - das stimmt.

Habe das geändert:

Quellcode

1
2
3
4
5
6
sys.011: / # /etc/init.d/sshd start
Starting SSH daemon/etc/ssh/sshd_config: line 120: Bad configuration option: Match
/etc/ssh/sshd_config: line 121: Bad configuration option: ChrootDirectory
/etc/ssh/sshd_config: line 122: Bad configuration option: ForceCommand
/etc/ssh/sshd_config: terminating, 3 bad configuration options
startproc:  exit status of parent of /usr/sbin/sshd: 255


die sshd_conf im Original: (nur Einträge die nicht default sind)

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
#	$OpenBSD: sshd_config,v 1.72 2005/07/25 11:59:40 markus Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.

Port <myport>
#Protocol 2,1
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# Authentication:
#LoginGraceTime 2m
#PermitRootLogin yes
StrictModes yes
#MaxAuthTries 6
AllowGroups sftponly dc03process

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
#PermitEmptyPasswords no

UsePAM yes

#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding no 

#X11DisplayOffset 10

# override default of no subsystems
Subsystem	sftp	/usr/lib/ssh/sftp-server
#Subsystem	sftp	internal-sftp

# This enables accepting locale enviroment variables LC_* LANG, see sshd_config(5).
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES 
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT 
AcceptEnv LC_IDENTIFICATION LC_ALL

Match Group sftponly
        ChrootDirectory /home/chroot/testuser/home/%u
        ForceCommand /home/chroot/testuser/usr/lib/ssh
        X11Forwarding no
        AllowTcpForwarding no


Struktur der chroot:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
/home/chroot/testuser = Root
drwxr-xr-x 2 root     root       1024 2009-06-12 08:02 bin
drwxr-xr-x 2 root     root       1024 2009-06-12 08:07 dev
drwxr-xr-x 2 root     root       1024 2009-06-12 08:07 etc
drwxr-xr-x 3 root     root       1024 2009-06-12 08:25 home
drwxr-xr-x 3 root     root       1024 2009-06-12 08:35 lib
drwxrwxrwt 2 testuser sftponly 1024 2009-06-12 07:41 tmp
drwxr-xr-x 4 root     root       1024 2009-06-12 15:24 usr
drwxr-xr-x 3 root     root       1024 2009-06-12 07:41 var 

Struktur unter /home/chroot/testuser/home
/user1
/user2
...


sshd startet nicht, auskommentieren der Einträge unter Match [..]: geht

11

13.06.2009, 06:10

Ungeachtet dessen: Annahme: er kennt Match [..]

wenn die sshd_conf linear bei Start des sshd abgearbeitet wird, kann es logisch ja gar nicht funktionieren:

Allow-Prüfung: user ist in group sftponly: darf rein
...
Subsystem: sftp-server wird gewählt, wenn Anfrage über Protokoll sftp kommt
...
Match:
im vorliegenden Fall würde er diese Bedingungen/Anweisungen abarbeiten, aber immer noch das für sftp definierte Subsystem starten.
Da dieses weiter oben mit absolutem Pfad definiert wird, wird er genau dieses
auch im Falle eines positiven Matches starten.

da der User aber nach positivem Login sofort in die chroot kommt, kann er den sftp-server nicht erreichen (daher wahrscheinlich die WinSCP-Fehlermeldung "kein SFTP-Server running".

Zwar wird das mit Kopieren oder Hardlinken der sftp/sftp-server Komponenten in die Root schon funktionieren, aber wer sagt dann, dass exakt dieser sftp-server gestartet werden soll.

Somit muss imho zwangsläufig das Subsystem nochmal innerhalb der Match-Anweisungen definiert werden.

Oder liege ich da falsch ?

Ich kanns nur nicht ausprobieren, weil er bei mri das Match nicht kennt (die Gruppe sftponly existiert natürlich).

12

13.06.2009, 07:18

noch ein Test:

in der sshd_config ((ohne Match) habe ich den Eintrag

Subsystem sftp /home/chroot/testuser/usr/lib/ssh/sftp-server

als einzige Anweisung drinnen.

Somit sollte generell nur noch der sftp-server im chroot aktiviert werden.

Login WinSCP mit normalem User: ok
lt. ps wird auch hier /usr/lib/ssh/sftp-server aktiv

Login WinSCP mit gechrootetem User: Fehler wie bisher

SSH-Login: alle User einwandfrei

Also: ungeachtet dieser Anweisungen in der sshd_config wird scheinbar IMMER ein fester Aufrufbefehl für sftp benutzt, der fix auf /usr/lib/ssh geht.
Und bei gechrootet Usern sollte das ja auch funktionieren, weil die relative AUfrufzeile ja identisch ist, aber scheinbar wird hier irgendwo noch eine Verknüpfung parat gehalten, die absolute-Pfade verwendet.

Hmm ... :keineahnung:

13

14.06.2009, 19:49

ein Entfernen und anschliessende Neuinstallation von openSSH hat das bestehende Problem gelöst.

SFTP/SSH-Login ist jetzt in chroot möglich.

Bei einer "Installation" von sftp-Server und Komponenten in der chroot kann in der originären sshd_config sogar auf die Match-Direktive verzichtet werden, es wird nach dem Login, dem change in das chroot-Environment die dortige Shell gestartet und diese aktiviert den im chroot vorhandenen sftp-server, bei Login mit "normalem" User wird der default sftp-server gestartet.

Also scheint bei der Installation / aufsetzen des Systems irgendwas nicht funktioniert zu haben.

Danke für die Hilfe.

Gruss
Mike

/Nachtrag/:

es macht - zumindest auf meinem System - einen Unterschied, wie man nach Änderungen in der sshd_config verfährt:

stop sshd (sftp-server)
start sshd

oder

start System (boot)

Das Match in der sshd_config wurde bei mir erst nach einem Rechnerstart anerkannt, nicht nach normalem Dienstneustart.

Mag ein Sonderfall sein - keine Ahnung - aber vielleicht hat jemand mal ein ähnliches Problem und dem mag dieser Hinweis evtl. weiterhelfen.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »MIKE bt« (14.06.2009, 19:53)


Thema bewerten