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 jedoch nicht über SSH beim Server anmelden kann?

Die rssh-Shell ( http://pizzashack.org/rssh/ ) wurde genau für diesen Zweck entwickelt.

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

Um es zu benutzen, setze es einfach als Shell für einen neuen Benutzer wie folgt:

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

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

chsh -s /usr/bin/rssh scpuser1

..und bearbeiten /etc/rssh.conf, um die rssh-Shell zu konfigurieren - insbesondere die Kommentarzeile allowscp, um den SCP-Zugriff für alle rssh-Benutzer zu ermöglichen.

(Vielleicht möchten Sie auch chroot verwenden, um die Benutzer in ihren Häusern zu behalten, aber das ist eine andere Geschichte.)

Ich bin viel zu spät dran, aber Sie könnten ssh-Schlüssel verwenden und den genauen Befehl angeben, der in der Datei ~ / .ssh / authorized_keys zulässig ist, z

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

Möglicherweise müssen Sie ps to auf dem Ziel verwenden, um die richtigen Befehlseinstellungen festzulegen.

PS: Wenn Sie einen scp-Testbefehl mit "-v" ausführen, können Sie so etwas sehen

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

Sie werden feststellen, dass "-t" eine undokumentierte scp-Option ist, die vom Programm am anderen Ende verwendet wird. Dies gibt Ihnen die Vorstellung, was Sie in authorized_keys ablegen müssen.

BEARBEITEN: Weitere Informationen (mit mehreren Links) finden Sie in dieser StackOverflow-Frage .

Hier ist ein funktionierendes Beispiel für einen backup_userauf der Serverseite genannten Benutzer .

~backup_user/.ssh/authorized_keys Inhalt auf der Serverseite (mit einigen weiteren Sicherheitsbeschrä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, in dem auf den Inhalt zugegriffen werden soll.

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

Auf der Clientseite sollte nun der folgende Befehl funktionieren:

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

Was dieser Befehl bewirkt:

• Es werden ausführliche Informationen angezeigt ( optional : Sie können -vsowohl die Datei command als auch authorized_keys entfernen ).
• Der Inhalt des Pfads / to / data wird rekursiv kopiert. ( Optional : Sie können -rsowohl die Datei command als auch die Datei authorized_keys entfernen, wenn Sie keine rekursive Kopie erstellen möchten.)
• Es verwendet Port 2222, um eine Verbindung zum Server herzustellen ( optional : Sie können -P 2222aus dem Befehl entfernen )
• 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/datawird in kopiert/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 wie hier beschrieben handhabt

Ich bin ein bisschen zu spät zur Party, aber ich schlage vor, Sie werfen einen Blick auf die ForceCommandDirektive von OpenSSH.

Subsystem sftp internal-sftp

Match group sftponly
         ForceCommand internal-sftp

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

Ich würde empfehlen, scponly zu verwenden.

Es handelt sich um eine eingeschränkte Shell, mit der Benutzer nur das tun können, was sich anhört: SCP-Dateien auf dem Server, aber keine Anmeldung. Informationen und Quellcode-Downloads für die Software finden Sie hier. Die vorkompilierten RPM-Pakete erhalten Sie über EPEL YUM-Repositorys .

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

Ich benutze dazu MySecureShell. Sie können auch andere Einschränkungen konfigurieren.

https://github.com/mysecureshell/mysecureshell

Beschränkt die Verbindungen nur zu SFTP / SCP. Kein Shell-Zugriff.

Sehr spät zur Party, aber setze die Shell des Git Users auf / usr / bin / git-shell. Es ist eine eingeschränkte Shell, die keine interaktive Anmeldung erlaubt. Sie können den Benutzer weiterhin mit 'su -s / bin / bash git' oder einem beliebigen git-Benutzernamen anmelden.

Wir verwenden eine Psudo-Shell namens scponly auf unseren sicheren FTP-Servern für Benutzer, die nur in der Lage sein möchten, scp-Dateien zu speichern, sich jedoch nicht anzumelden.

Ich habe eine gute Möglichkeit gefunden, die Funktion command = "..." der authorized_keys-Datei zu verwenden. (Empfohlen von dieser Seite )

Der Befehl, den Sie ausführen würden, testet auf Argumente, die mit scp (und rsync) beginnen.

Hier ist die authorized_keys-Datei:

# 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

Vermutlich müssten Sie die Datei "authorized_keys" des Benutzers noch schützen, aber mein Zweck war es, einen kennwortlosen Schlüssel zu haben, den ich für Sicherungen verwenden konnte, ohne einen neuen Benutzer erstellen zu müssen und den Schlüssel keine Shell geben zu müssen (ok, leicht)

Ändern Sie die Anmelde-Shell des Benutzers in etwas Einschränkendes, wodurch der Benutzer nur scp , sftp-server und rsync ausführen kann und auch prüft, ob unsichere Argumente nicht zulässig sind (z. B. scp -S ... und rsync -e .. . sehen sind unsicher, hier: http://exploit-db.com/exploits/24795 ). Beispiel für eine solche restriktive Login-Shell:

• rssh
• scponly (nicht nur scp, sondern erlaubt auch sftp, svn usw., wenn dies konfiguriert ist)
• transfer_shell

Möglicherweise möchten Sie eines dieser Verzeichnisse in einer Chroot-Umgebung oder einer anderen eingeschränkten Umgebung (z. B. nsjail unter Linux) ausführen , um den Netzwerkzugriff zu deaktivieren und die Kontrolle darüber zu erleichtern, welche Verzeichnisse gelesen und / oder geschrieben werden können.

Ich empfehle , nicht mit command="..."in ~/.ssh/authorized_keys, weil ohne sorgfältigen zusätzlichen Schutz (wie chmod -R u-w ~für den Benutzer) ein böswilliger Benutzer eine neue Version hochladen ~/.ssh/authorized_keys, ~/.ssh/rcoder ~/.bashrc, und somit kann beliebige Befehle enthalten und ausführen.

Es ist nicht die eleganteste Lösung, aber Sie könnten so etwas in die .bashrc-Datei des Benutzers werfen

if [ "$TERM"  != "dumb" ]; then
  exit
fi

Ich habe festgestellt, dass SCP-Benutzer eine "dumme" Laufzeit haben und andere normalerweise vt100.

Ich stelle mir vor, der Benutzer könnte wahrscheinlich einen neuen .bashrc scp überarbeiten, was dies nicht zur besten Lösung macht, aber für eine schnelle und schmutzige Lösung wird dies funktionieren