Problem mit scponly

[/dev/null_Peter]

Hi Freunde des Tux,

ich möchte meine ssh-Nutzer etwas in ihrem Bewegungsdrang beschränken und habe dazu gestern mal scponly installiert. (SUSE 10.1)
Aber irgendwo habe ich da ein Problem ... .

- Installation problemlos (gemäß Anleitung aus dem Forum, aber auch das Original und weitere verglichen ...)
- scponly und scponlyc liegen im Pfad
- Testnutzer "scponly" mit setup_chroot.sh angelegt (also alle Vorgaben einfach bestätigt)
- seine Daten stehen auch sauber in der /etc/passwd (incl. /usr/local/sbin/scponlyc)
- in /home/scponly stehen auch sämtliche geforderten Ordner und Dateien
- mit .ssh/ und authorized_keys ergänzt
- die publickey-gesicherte Authentisierung ist kein Thema ...
==> Nov 10 18:58:32 pluto sshd[12007]: Accepted publickey for scponly from 192.168.178.25 port 26752 ssh2
- selbiges Ergebnis auch mit der bash als Login-shell (testweise geändert)
- nur per scp (fish:// oder auch mit WinSCP) keine Verbindung ...
Auszug aus /var/log/messages:
Nov 10 17:58:32 pluto scponly[12010]: bad request: echo FISH:;exec /bin/sh -c "if env true 2>/dev/null; then env PS1= PS2= TZ=UTC LANG=C LC
_ALL=C LOCALE=C /bin/sh; else PS1= PS2= TZ=UTC LANG=C LC_ALL=C LOCALE=C /bin/sh; fi" [username: scponly(1006), IP/port: 192.168.178.25 26752 22]


Er scheint also die neue Shell nicht zu nehmen.
Habe sie ihm auch zusätzlich in sein /home kopiert (/home/scponly/usr/sbin/scponlyc) und auch in der passwd darauf verwiesen. => Fehlanzeige.
Ja, wo ist mein Denkfehler ?

MfG Peter

[caspartroy]

scponly ist doch gerade dafür gedacht, dass man /bin/sh nicht ausführt, da FISH das aber offensichtlich benötigt, funktioniert fish nicht.
was ist daran jetzt falsch? ist doch so, wie es sein sollte.

[/dev/null_Peter]

Hi caspartroy,

du hast ja völlig Recht, ich will ja gerade, dass nicht bin/sh oder die bash usw., sondern eben die dafür besser geeignete /sbin/scponlyc als shell genutzt wird. Und das "c" am Ende bedeutet ja chrooted. Selbst im HowTo von cane steht fast am Ende unter GUIs für Linux: "Unter KDE im Konqueror: fish://server".

Vielleicht noch eine Info:
Beim Anlegen des Testusers mittels des Scriptes kam am Ende eine Fehlermeldung, dass für mein Betriebssystem nicht das geeignete Script vorliegt, es aber das Beste versucht. Da muss ich ansetzen. Ich muss dem System irgendwie mitteilen, dass es bei einem per ssh kommenden User scponlyc verwenden muss.

Was mich eben wundert ist, dass ich davon eben noch nirgendwo gelesen habe ... .

Oder anders: wie würdest du die Anmeldung machen? Nutzt du ssh und scponly?
Habe ja auch geschrieben "... wo ist MEIN Denkfehler ...?"

Mfg Peter

[caspartroy]

ich nutze scponly nicht, ich hab es mal benutzt (ohne c am ende) und fand es relativ unbrauchbar, da viele dienste, die ssh benutzen (z.B. darcs) damit nicht funktionieren.
scponly ist doch eine loginshell, die wird einfach (in /etc/passwd) einem user zugeordnet und der kann dann nur noch scp nutzen und nicht mehr ssh. also keine shell mehr. weisst du eigentlich was scp ist?

[/dev/null_Peter]

> weisst du eigentlich was scp ist?
ja!

Und ich will auch genau das, was du bemängelt hast, erreichen.
Meine ssh-Nutzer, welche sich bei mir mit fish:// oder WinSCP oder anderen SCP-Clients einloggen (per ausschließlicher gestatteter publickkey-Authentifikation) sollen sich auch nur ausschließlich in ihrem eigenen /home/user und auch nur per scp bewegen dürfen. Die Shell habe ich ihnen vorher schon lange mit /bin/false weg genommen. Und das alles läuft ja auch schon sehr lange stabil und zu unserer größten Zufriedenheit. Nur, die Nutzer können trotzdem lesend durch den Dateibaum spazieren. Und genau das möchte ich einschränken.
Und genau für dieses Vorgehen wurde scponlyc entwickelt. Und dass ich selbige dem Testnutzer in der /etc/passwd vorgeschrieben habe, habe ich ja schon erwähnt.
Nur, warum wird immer versucht, auf die /bin/sh zuzugreifen?

Ich habe immer noch Hoffnung, dass cane als der Verfasser des HowTo meinen Beitrag sieht ... .

MfG Peter"

[Roger Wilco]

Konqueror bzw. fish KIO-Slave benötigt eine Bourne-Shell bzw. eine dazu kompatible Shell. Die ist mit scponly(c) nicht gegeben.

Benutze stattdessen den SFTP KIO-Slave. Einfach sftp:// anstatt fish://

[/dev/null_Peter]

Danke für den Tipp, werde ich heute Abend gleich mal testen.
Aber das widerspricht doch canes how-to, wo direkt auf fish:// hingewiesen wird.

[/dev/null_Peter]

Hi Roger Wilco,

dein Tipp mit dem sftp hat den Durchbruch gebracht. Jetzt macht er es so, wie er es soll.
Wobei mich immer noch wundert, wieso cane so direkt auf fish:// hinweist ... .
Andererseits habe ich jetzt nach intensivem Studium der Originaldokumente (Features) auch gesehen, dass es dort auch die Option "--enable-scp-compat" gibt.

Aber das Wichtigste ist, dass es funktioniert - und meine WinDOSen-Nutzer merken es mit WinSCP nicht einmal.

MfG Peter

[caspartroy]

> weisst du eigentlich was scp ist?
ja!

Die Shell habe ich ihnen vorher schon lange mit /bin/false weg genommen.
ne!

scponly ist die shell.
/bin/false ist false.

[/dev/null_Peter]

Ich glaube, wir reden aneinander vorbei.

Die Shell habe ich meinen Nutzern VOR dem Einatz von scponly weggenommen, indem ich ihnen /bin/false in /etc/passwd eingetragen habe.

Und mit scponlyc haben sie nun wieder eine "neue" Shell. Eine, die ihnen reicht und mich erfreut.

OK?

Ich bin - wie vorher schon geschrieben - auf canes Beschreibung ausgerutscht, welcher da eben explizid auf fish:// hinweist. Und das scheint eben nicht zu funktionieren. Und mit sftp:// habe ich einfach nicht getestet. War zu sehr auf fish:// fixiert.

Nun habe ich alle meine Zugänge umgestellt, von den WinDOSen-Nutzern hat es keiner bemerkt (diejenigen, die es bemerkt haben, werden wohl nix sagen ...) alles funktioniert bestens und ich bin zufrieden.

Vielen Dank an alle, die mir geholfen haben.

MfG Peter