Zezwalaj SCP, ale nie faktyczne logowanie przy użyciu SSH

Czy istnieje sposób skonfigurowania użytkownika na komputerze z systemem Linux (w tym przypadku Centos 5.2), aby mógł używać scp do pobierania plików, ale nie może zalogować się do serwera za pomocą SSH?

Powłoka rssh ( http://pizzashack.org/rssh/ ) została zaprojektowana właśnie do tego celu.

Ponieważ RHEL / CentOS 5.2 nie zawiera pakietu dla rssh, możesz zajrzeć tutaj, aby uzyskać RPM: http://dag.wieers.com/rpm/packages/rssh/

Aby go użyć, po prostu ustaw go jako powłokę dla nowego użytkownika:

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

.. lub zmień powłokę na istniejącą taką jak ta:

chsh -s /usr/bin/rssh scpuser1

... i edytuj, /etc/rssh.confaby skonfigurować powłokę rssh - szczególnie allowscplinię odkomentowania , aby umożliwić dostęp SCP wszystkim użytkownikom rssh.

(Możesz także użyć chroot, aby zatrzymać użytkowników w ich domach, ale to inna historia).

Spóźniłem się z tym, ale możesz użyć kluczy ssh i podać dokładne polecenie dozwolone w ich pliku ~ / .ssh / Author_keys, np.

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

Może być konieczne użycie ps do celu, aby ustawić właściwe ustawienia poleceń.

PS: Jeśli uruchomisz testowe polecenie scp z „-v”, zobaczysz coś takiego

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

Zauważysz, że „-t” jest nieudokumentowaną opcją scp, używaną przez program na drugim końcu. To daje wyobrażenie o tym, co należy umieścić w uprawnionych kluczach.

EDYCJA: Możesz znaleźć więcej informacji (z kilkoma linkami) w tym pytaniu StackOverflow .

Oto działający przykład tego dla użytkownika o nazwie backup_userpo stronie serwera.

~backup_user/.ssh/authorized_keys treść po stronie serwera (z pewnymi dodatkowymi ograniczeniami bezpieczeństwa):

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

Utwórz link w ~ backup_user /, który prowadzi do katalogu, w którym zawartość powinna być dostępna.

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

Teraz po stronie klienta powinno działać następujące polecenie:

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

Co robi to polecenie:

• Wyświetla pełne informacje ( opcja : możesz usunąć -vzarówno z pliku polecenia, jak i pliku autoryzowanych_kluczy)
• Rekurencyjnie kopiuje zawartość ścieżki / do / danych. ( opcjonalnie : możesz usunąć -rzarówno plik polecenia, jak i plik autoryzowanych_kluczy, jeśli nie chcesz tworzyć kopii rekurencyjnej)
• Używa portu 2222 do łączenia się z serwerem ( opcja : możesz usunąć -P 2222z polecenia)
• Wykorzystuje i plik tożsamości do automatyzacji połączenia ( opcjonalnie : można usunąć-i .ssh/id_rsa_key_file
• Treść path/to/datazostanie skopiowana do/path/to/directory/with/accessible/content/

Aby utworzyć kopię pliku (lub kilku) z serwera na klienta, należy utworzyć skrypt powłoki, który obsługuje to w sposób opisany tutaj

Jestem trochę spóźniony na imprezę, jednak zasugeruję, abyś przyjrzał się ForceCommanddyrektywie OpenSSH.

Subsystem sftp internal-sftp

Match group sftponly
         ForceCommand internal-sftp

To prawda, że ​​jest to SFTP, a nie SCP, ale osiąga ten sam cel, bezpieczniej niż w przypadku ograniczonej powłoki. Dodatkowo możesz chrootować użytkownika, jeśli chcesz.

Poleciłbym używać scponly.

Jest to ograniczona powłoka, która pozwala użytkownikom robić tak, jak to brzmi, pliki SCP na serwerze, ale nie logować się. Informacje i pliki do pobrania kodu źródłowego dla oprogramowania są dostępne tutaj, a wstępnie skompilowane pakiety RPM są dostępne za pośrednictwem Repozytoria EPEL YUM .

Po zainstalowaniu będziesz musiał skonfigurować każde konto użytkownika, do którego chcesz ograniczyć dostęp, aby korzystać z nowo zainstalowanej ograniczonej powłoki. Możesz to zrobić ręcznie za pomocą / etc / passwd lub użyć następującego polecenia: usermod -s /usr/bin/scponly USERNAME

Używam do tego MySecureShell. Możesz także skonfigurować inne ograniczenia.

https://github.com/mysecureshell/mysecureshell

Ogranicza połączenia tylko z SFTP / SCP. Brak dostępu do powłoki.

Bardzo późno na imprezę, ale po prostu ustaw powłokę użytkownika git na / usr / bin / git-shell. To ograniczona powłoka, która nie pozwala na interaktywne logowanie. Nadal możesz zalogować się do użytkownika za pomocą polecenia „su -s / bin / bash git” lub dowolnej innej nazwy użytkownika git.

Używamy powłoki psudo o nazwie scponly na naszych bezpiecznych serwerach ftp dla użytkowników, którzy chcą tylko móc skanować pliki, ale nie logować się.

Znalazłem dobry sposób na użycie funkcji command = "..." w pliku autoryzowanych_kluczy. (Sugerowane mi przez tę stronę )

Polecenie, które uruchomisz, to polecenie sprawdzające argumenty rozpoczynające się od scp (i rsync).

Oto plik autoryzowanych_kluczy:

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

Oto zawartość pliku 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

Wydaje mi się, że prawdopodobnie nadal musisz chronić plik autoryzowanych_kluczy użytkownika, ale moim celem było posiadanie klucza bez hasła, którego mógłbym użyć do tworzenia kopii zapasowych, bez konieczności tworzenia nowego użytkownika, i aby klucz nie dawał powłoki (ok, łatwo)

Zmień powłokę logowania użytkownika na coś ograniczającego, co pozwala użytkownikowi uruchamiać tylko scp , sftp-server i rsync , a także sprawdza, czy niebezpieczne argumenty nie są dozwolone (np. Scp -S ... i rsync -e .. . są niebezpieczne, zobacz tutaj: http://exploit-db.com/exploits/24795 ). Przykład takiej restrykcyjnej powłoki logowania:

• rssh
• scponly (nie tylko scp, pozwala także na sftp, svn itp., jeśli tak skonfigurowano)
• transfer_shell

Możesz uruchomić jeden z nich w chroot lub w innym ograniczonym środowisku (np. Nsjail w systemie Linux), aby wyłączyć dostęp do sieci i ułatwić (na białej liście) kontrolę, które katalogi mogą być odczytywane i / lub zapisywane.

Nie polecam korzystania command="..."z ~/.ssh/authorized_keys, bo bez starannej dodatkowej ochrony (takich jak chmod -R u-w ~na użytkownika) złośliwy użytkownik może przesłać nową wersję ~/.ssh/authorized_keys, ~/.ssh/rclub ~/.bashrc, a zatem może zawierać i wykonywanie dowolnych poleceń.

To nie jest najbardziej wdzięczne rozwiązanie, ale możesz wrzucić coś takiego do .bashrc użytkowników

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

Przekonałem się, że użytkownicy SCP otrzymują TERM „głupi”, a inni zwykle otrzymują vt100.

Wyobrażam sobie, że użytkownik może prawdopodobnie przeskanować nowy plik .bashrc, co sprawia, że ​​nie jest to najlepsze rozwiązanie, ale w przypadku szybkiego i brudnego rozwiązania to zadziała