Frage Erlaube SCP, aber keine tatsächliche Anmeldung mit SSH


Gibt es eine Möglichkeit, einen Benutzer auf einer Linux-Box (in diesem Fall Centos 5.2) so zu konfigurieren, dass er scp zum Abrufen von Dateien verwenden kann, sich aber nicht mit SSH am Server anmelden kann?


58
2017-11-12 02:44


Ursprung


Ich habe versucht, die Login-Shell auf / bin / false zu setzen, aber das hält den scp einfach an. - DrStalker


Antworten:


sch sch 100 sch 100 100 sch 100 sch 100 sch 100 sch 100 sch 100 sch 100 sch 100 sch sch zwischen 100 100 sch sch sch sch sch sch dieserhttp://pizzashack.org/rssh/) ist genau für diesen Zweck konzipiert.

Da RHEL / CentOS 5.2 kein Paket für rssh enthält, können Sie hier nach einem RPM suchen: http://dag.wieers.com/rpm/packages/rssh/

Um es zu verwenden, legen Sie es einfach als Shell für einen neuen Benutzer fest:

useradd -m -d /home/scpuser1 -s /usr/bin/rssh scpuser1
passwd scpuser1

..oder ändern Sie die Shell für eine bestehende wie folgt:

chsh -s /usr/bin/rssh scpuser1

..und bearbeiten /etc/rssh.conf rssh shell konfigurieren - besonders unkommentiert allowscp Zeile, um den SCP-Zugriff für alle rshsh-Benutzer zu aktivieren.

(Sie können auch chroot verwenden, um die Benutzer in ihren Häusern zu halten, aber das ist eine andere Geschichte.)


41
2017-11-12 03:14



das ist genial - ich habe auch schon so lange nach so etwas gesucht - warren
Die Idee hinter rssh ist nett, aber iirc rssh war nicht gerade ein Programmierwunder. Ein einfacher google on 'rssh Exploit' bringt mehr Ergebnisse als ich mich wohl fühle ... - wzzrd
scponly ist mehr oder weniger dasselbe und scheinbar weniger exploitsanfällig: sublimation.org/scponly/wiki/index.php/Main_Page - François Feugeas
scponly scheint nach Github umgezogen zu sein. Die Sublimationsverbindung ist tot. github.com/scponly/scponly/wiki - spazm


Ich bin viel zu spät, aber Sie könnten SSH-Schlüssel verwenden und den genauen Befehl in ihrer ~ / .ssh / authorized_keys-Datei, z.

no-port-Weiterleitung, no-pty, command = "scp source target" ssh-dss ...

Möglicherweise müssen Sie ps für das Ziel verwenden, um die richtigen Befehlseinstellungen festzulegen.

PS: Wenn Sie einen Test-scp-Befehl mit "-v" ausführen, können Sie etwas Ähnliches sehen

debug1: Sending command: scp -v -t myfile.txt

Sie werden feststellen, dass "-t" eine nicht dokumentierte scp-Option ist, die vom Programm am fernen Ende verwendet wird. Dies gibt Ihnen die Idee, was Sie in authorized_keys eingeben müssen.

BEARBEITEN: Sie können weitere Informationen (mit mehreren Links) in finden diese StackOverflow-Frage.

Hier ist ein Arbeitsbeispiel für einen Benutzer namens backup_user auf der Serverseite.

~backup_user/.ssh/authorized_keys Inhalt auf der Serverseite (mit einigen weiteren Sicherheitseinschränkungen):

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="scp -v -r -d -t ~/CONTENT" ssh-rsa AAAAMYRSAKEY...

Erstellen Sie einen Link in ~ backup_user /, der auf das Verzeichnis verweist, auf das der Inhalt zugreifen soll.

$ ln -s /path/to/directory/with/accessible/content ~backup_user/CONTENT

Nun sollte der folgende Befehl vom Client aus funktionieren:

scp -v  -r  -P 2222 -i .ssh/id_rsa_key_file path/to/data backup_user@SERVER:~/CONTENT

Was dieser Befehl macht:

  • Sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch dieseroptional: Sie können das entfernen -v aus der Datei command und authorized_keys)
  • Es kopiert rekursiv den Inhalt des Pfades / to / data. (optional: Sie können entfernen -r aus der Datei command und authorized_keys, wenn Sie keine rekursive Kopie erstellen möchten.
  • Es verwendet Port 2222, um eine Verbindung zum Server herzustellen (optional: Sie können entfernen -P 2222 aus dem Befehl)
  • Es verwendet und Identitätsdatei, um die Verbindung zu automatisieren (optional: Sie können entfernen -i .ssh/id_rsa_key_file
  • Der Inhalt von path/to/data wird in kopiert werden /path/to/directory/with/accessible/content/

Um eine Kopie einer Datei (oder mehrerer) vom Server zum Client zu erstellen, sollten Sie ein Shell-Skript erstellen, das dies erledigt wie hier beschrieben


35
2017-11-27 17:52



Was soll den Benutzer stoppen, der über ihrer authorized_keys Datei scopping ist? Kann es darauf beschränkt sein, nicht dem Benutzer selbst zu gehören? - Dan
@Dan - Es sollte möglich sein, schreibgeschützte Berechtigungen für die Datei authorized_keys zu setzen, d. chmod 400 ~/.ssh/authorized_keys. - Roger Dueck
Auch solltest du machen ~/.bashrc (und was auch immer Bash ausführt) und ~/.ssh/rc schreibgeschützt. Hat der böswillige Benutzer jedoch Zugriff auf rsync oder sftp, kann er trotzdem entfernen ~/.bashrcund lade einen neuen hoch. Da es schwer zu schützen ist, empfehle ich gegen diese Methode (command="..."). - pts


Ich bin ein bisschen spät auf der Party, aber ich werde vorschlagen, dass Sie einen Blick auf die ForceCommand Richtlinie von OpenSSH.

Subsystem sftp internal-sftp

Match group sftponly
         ForceCommand internal-sftp

Zugegeben, das ist SFTP und nicht SCP, aber es erreicht das gleiche Ziel, sicherer als mit einer eingeschränkten Shell. Darüber hinaus können Sie den Benutzer chroot, wenn Sie möchten.


29
2017-11-12 10:56



Ergänzen Sie die chrootDirectory %h und AllowTcpForwarding no  nach dem Match-Abschnitt, um die sftpony Benutzer zu chroot nach Hause zu zwingen. Bitte beachten Sie, dass die Übereinstimmung (muss!) der letzte Abschnitt in der SSH-Konfiguration sein sollte und die Optionen danach Optionen für die übereinstimmenden Benutzer sind - higuita
ForceCommand internal-sftp -u 0077 -d /uploaddir kann es weiter verhärten, indem eine Umask in einem Upload-Verzeichnis erzwungen wird. In Verbindung mit 'ChrootDirectory' erzeugt es eine sehr kontrollierte, isolierte Upload-Umgebung. Bonusnote: das Standardverzeichnis und die Umask Muss eingestellt sein in der ForceCommandnicht in der Subsystem Richtlinie, wenn Sie möchten, dass sie funktionieren. - Marcin
Ein längerer Artikel, der dies erklärt, ist verfügbar unter debian-administration.org/article/590/... - koppor


Ich würde empfehlen, mit scponly.

Es ist eine eingeschränkte Shell, die es den Benutzern erlaubt, genau das zu tun, was es heißt, SCP-Dateien auf dem Server, aber nicht wirklich einzuloggen. Informationen und Quellcode-Downloads für die Software sind verfügbar Hier und die vorkompilierten RPM-Pakete sind verfügbar über die EPEL YUM-Repositories.

Nach der Installation müssen Sie jedes Benutzerkonto konfigurieren, auf das Sie den Zugriff beschränken möchten, um die neu installierte eingeschränkte Shell zu verwenden. Sie können dies manuell über / etc / passwd tun oder den folgenden Befehl verwenden: usermod -s /usr/bin/scponly USERNAME


5
2018-01-25 20:30



Ich unterstütze das. scponly ist für genau diesen Zweck konzipiert. - UtahJarhead
scponly scheint tot zu sein. debian scheint es entfernt zu haben: packages.debian.org/search?keywords=skonpony und das Code auf GitHub ist auch tot. Folgediskussion: serverfault.com/questions/726519/... - koppor


Ich benutze MySecureShell, um dies zu tun. Sie können auch andere Einschränkungen konfigurieren.

https://github.com/mysecureshell/mysecureshell

Begrenzt nur Verbindungen zu SFTP / SCP. Kein Shell-Zugriff.


5
2017-11-12 07:21





Sehr spät zur Party, aber setze die Shell des git-Benutzers einfach auf / usr / bin / git-shell. Es ist eine eingeschränkte Shell, die keine interaktive Anmeldung zulässt. Du kannst dem Benutzer immer noch mit 'su -s / bin / bash git' oder was auch immer dein git-Benutzername ist.


2
2017-10-01 19:54





Wir benutzen eine Pseudo-Shell namens skonly auf unseren sicheren FTP-Servern für Benutzer wollen wir nur scp Dateien, aber nicht einloggen.


1
2017-11-27 18:05





Ich habe einen netten Weg gefunden, die Funktion command = "..." der Datei authorized_keys zu verwenden. (Vorgeschlagen von mir von diese Seite)

Der Befehl, den Sie ausführen würden, wäre einer, der nach Argumenten sucht, die mit scp (und rsync) beginnen.

Hier ist die Datei authorized_keys:

# authorized_keys
command="/usr/local/bin/remote-cmd.sh" ssh-rsa.....== user@pewpew

Hier ist der Inhalt von remote-cmd.sh:

#!/bin/bash
# /usr/local/bin/remote-cmd.sh
case $SSH_ORIGINAL_COMMAND in
 'scp'*)
    $SSH_ORIGINAL_COMMAND
    ;;
 'rsync'*)
    $SSH_ORIGINAL_COMMAND
    ;;
 *)
    echo "Access Denied"
    ;;
esac

Ich vermute, dass Sie wahrscheinlich noch die Datei authorized_keys des Benutzers schützen müssen, aber mein Ziel war es, einen Schlüssel ohne Passwort zu haben, den ich für Backups verwenden könnte, ohne einen komplett neuen Benutzer erstellen zu müssen und den Schlüssel keine Shell zu geben (ok, leicht)


1
2017-10-13 03:13



Das ist ziemlich cool - aber ich kann mir vorstellen, dass es durch die Ausgabe eines Befehls, der einen scp ausführt, unterlaufen werden kann, und führe danach ein Skript aus! - davidgo
@davidgo, der $ SSH_ORIGINAL_COMMAND mit exec vorwegnimmt, könnte diese Sicherheitslücke schließen, wenn man annimmt, dass scp und rsync selbst nicht versuchen, mehrere Programme auszuführen (in diesem Fall würde dies das Programm kaputt machen). - Phil
Auch solltest du machen ~/.ssh/authorized_keys, ~/.bashrc (und was auch immer Bash ausführt) und ~/.ssh/rc schreibgeschützt für den Benutzer Hat der böswillige Benutzer jedoch Zugriff auf rsync oder sftp, kann er trotzdem entfernen ~/.bashrcund lade einen neuen hoch. Da es schwer zu schützen ist, empfehle ich gegen diese Methode (command="..."). - pts
@pts Sie könnten sowohl die RC-Dateien, und die Verzeichnisse, die sie enthalten, von jemand anderem als dem Benutzer (niemand?) gehört und nicht durch den Benutzer beschreibbar sein. Aber an diesem Punkt verwenden Sie besser etwas wie rssh. Wow, ich habe gerade gemerkt, dass dies meine Antwort ist! Es ist alt! Haha! - Phil
Vergiss das nicht scp -S ... und rsync -e ... lässt den Benutzer beliebige Befehle ausführen. Sie sollten also die Argumente in überprüfen $ SSH_ORIGINAL_COMMAND bevor es ausgeführt wird. Mehr Infos hier: exploit-db.com/exploits/24795 - pts