scponly ...
Für den Fall, dass es mal gebraucht wird. Ich war heute in der Not, einem User scp-Kopierrechte auf einen Server zu geben. Mit der Shell sollte sich der Benutzer nicht anmelden können. Genau dafür gibt es scponly, das Tool ist in gängigen Distributionen direkt in den Paketquellen.
Die Installation ist einfach, man braucht aber nicht nur das Paketmanagement.
Und die Frage, ob man chroot einsetzen möchte ("Install the chrooted binary /usr/sbin/scponlyc SUID root?"), mit "Yes" oder "Ja" beantworten. Mit chroot wird ein User in einem bestimmten Verzeichnis eingesperrt, ohne dass er in den Verzeichnissen "wildern" kann.
Mit disem Shellskript kann man einen User anlegen, der ins "Gefängnis" gesperrt wird.
Ich nenne den User mal "a":
Ohne die folgenden beiden Befehle wird aber nichts daraus, da kommt es sonst zu Problemen.
Jetzt gibt es den User "a", dem es nur erlaubt ist per scp oder sftp Dateien hoch- und runterzuladen.
Die Installation ist einfach, man braucht aber nicht nur das Paketmanagement.
aptitude install scponly
Und die Frage, ob man chroot einsetzen möchte ("Install the chrooted binary /usr/sbin/scponlyc SUID root?"), mit "Yes" oder "Ja" beantworten. Mit chroot wird ein User in einem bestimmten Verzeichnis eingesperrt, ohne dass er in den Verzeichnissen "wildern" kann.
cd /usr/share/doc/scponly/setup_chroot
gzip -cd setup_chroot.sh.gz > setup_chroot.sh
gzip -cd setup_chroot.sh.gz > setup_chroot.sh
Mit disem Shellskript kann man einen User anlegen, der ins "Gefängnis" gesperrt wird.
bash setup_chroot.sh
Ich nenne den User mal "a":
Next we need to set the home directory for this scponly user. please note that the user's home directory MUST NOT be writeable by the scponly user. this is important so that the scponly user cannot subvert the .ssh configuration parameters. for this reason, a writeable subdirectory will be created that the scponly user can write into. Username to install [scponly]a home directory you wish to set for this user [/home/a] name of the writeable subdirectory [incoming] creating /home/a/incoming directory for uploading files Your platform (Linux) does not have a platform specific setup script. This install script will attempt a best guess. If you perform customizations, please consider sending me your changes. Look to the templates in build_extras/arch. - joe at sublimation dot org please set the password for a: Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully if you experience a warning with winscp regarding groups, please install the provided hacked out fake groups program into your chroot, like so: cp groups /home/a/bin/groups
Ohne die folgenden beiden Befehle wird aber nichts daraus, da kommt es sonst zu Problemen.
cp -av /lib/libnss_* /home/a/lib/
cp -av /lib64/libnss_* /home/a/lib64/
cp -av /lib64/libnss_* /home/a/lib64/
Jetzt gibt es den User "a", dem es nur erlaubt ist per scp oder sftp Dateien hoch- und runterzuladen.
Trackbacks
Dirks Logbuch am : scponly-full ...
Vorschau anzeigen
Zusätzlich zu scponly gibt es auf Debian basierten Systemen auch das Paket scponly-full, dass man ganz analog zu scponly einrichten kann. Die volle Variante bietet auch Unterstützung für rsync, unison und svn. Für mich war die rsync-Unterstützung wichtig,
ysbsqaaksp1yd1.shikshik.org am : PingBack
Vorschau anzeigen
www.deimeke.net am : PingBack
Vorschau anzeigen
Dirks Logbuch am : SFTP chroot mit Bordmitteln ...
Vorschau anzeigen
Nachdem ich ein bisschen mit scponly und scponly-full wie auch rssh herumgespielt habe, habe ich mich entschieden, den Dateizugriff mit Bordmitteln unter Linux zu bewerkstelligen. Mir haben die anderen Lösungen nicht gefallen. In Anlehnung an scponly habe
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
Sven Hartge am :
Hierzu in der /etc/ssh/sshd_config folgendes definieren:
Subsystem sftp internal-sftp
Match User username
ChrootDirectory /var/chroot/sonstwas
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp -u 0002
(wobei das -u 0002 die umask definiert)
/var/chroot/sonstwas muss nur existieren, es braucht dort keine weiteren Verzeichnisse, Device-Nodes oder Libraries.
Will man externe Verzeichnisse dort haben, z.B. /srv/apache/website_X, dann bindet man dieses am Besten via bind-mount in das chroot() ein.
Vorteil des Ganzen: Intern zu SSH, braucht keine manuell ins chroot kopierten Dateien, ist durch das ForceCommand nicht zu umgehen.
Dirk Deimeke am :
Das kannte ich noch nicht! Kannst Du dem User dann /bin/false als Shell geben?
Sven Hartge am :
Wobei ich /usr/sbin/nologin bevorzuge, weil dies den Login-Versuch mitloggt, was /bin/false nicht macht.
Dirk Deimeke am :
Sven Hartge am :
Bei mir zumindest geht kein Server ohne installiertes und konfiguriertes logcheck live.
Und selbst wenn man es nicht direkt auswertet, ist es doch gut, diese Daten für die nachträgliche Analyse im Log stehen zu haben, IMHO.
Dirk Deimeke am :
Bis jetzt habe ich logwatch benutzt. Vielleicht sollte ich mir logcheck auch einmal anschauen.
Sven Hartge am :
logcheck mailt nur, wenn bestimmte vorab definierte Events auftreten.
D.h. nicht oder falsch konfiguriert bekommt man gar nicht mit, wenn ungewöhnliche Events auftreten. Dies kann z.B. nach einem Versions-Update eines Programmes auftreten, bei dem sich der Log-Output ändert. Und plötzlich sitzt man im Dunkeln und merkt gar nicht, das Dumme Dingeâ„¢ passieren.
Bei logcheck dagegen definiert man die Events, die es ignorieren soll. Alles andere wird gemailt.
Dies führt zwar dazu, das man am Anfang ein wenig Anpassungsarbeit machen muss, aber dafür bekommt man sofort mit, wenn etwas nicht stimmt.
Beide Tools haben ihre Berechtigung, aber mir gefällt logcheck aus den genannten Gründen wesentlich besser.
Sven Hartge am :
Das muss natürlich "logwatch mailt nur, wenn bestimmte vorab definierte Events auftreten." heißen, sonst ergibt das Ganze keinen Sinn.
Dirk Deimeke am :
Dirk Deimeke am :
Vielen Dank für den Tipp!
Philipp Beckers am :
Dirk Deimeke am :