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

62

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?

DrStalker
źródło
Próbowałem ustawić powłokę logowania na / bin / false, ale to po prostu przestaje działać scp.
DrStalker,

Odpowiedzi:

44

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).

Anonimowy
źródło
to niesamowite - szukałem też czegoś takiego od dłuższego czasu
ostrzega
6
pomysł za rssh jest fajny, ale iirc rssh nie był cudem bezpieczeństwa pod względem programowania. Proste google na „rssh exploit” daje więcej wyników, niż jestem w stanie ...
wzzrd
7
scponly jest mniej więcej tym samym i najwyraźniej mniej podatnym na exploity: sublimation.org/scponly/wiki/index.php/Main_Page
François Feugeas
scponly prawdopodobnie przeniósł się na github. Link do sublimacji nie działa. github.com/scponly/scponly/wiki
spazm 13.09.2013
38

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

Społeczność
źródło
1
Co powstrzyma użytkownika przed przeszukaniem pliku uprawnionych kluczy? Czy można ograniczyć fakt, że użytkownik nie jest właścicielem?
Dan
1
@ Dan - Powinno być możliwe ustawienie uprawnień tylko do odczytu dla pliku autoryzowanych_kluczy, tj. chmod 400 ~/.ssh/authorized_keys.
Roger Dueck,
Powinieneś także zrobić ~/.bashrc(i cokolwiek innego, co Bash wykonuje) i ~/.ssh/rctylko do odczytu. Ale jeśli złośliwy użytkownik ma dostęp do rsync lub sftp, nadal może go usunąć ~/.bashrci przesłać nowy. Ponieważ jest trudny do ochrony, odradzam tę metodę ( command="...").
pkt
31

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.

François Feugeas
źródło
2
dodaj sekcję „ chrootDirectory %hi” AllowTcpForwarding nopo meczu, aby zmusić użytkowników sftponly do chrootowania w swoim domu. należy pamiętać, że mecz powinien (musi!) być ostatnią sekcją konfiguracji ssh, a opcje to opcje tylko dla dopasowanych użytkowników
higuita
4
ForceCommand internal-sftp -u 0077 -d /uploaddirmoże jeszcze bardziej je zahartować, wymuszając umask w katalogu do przesyłania. W połączeniu z „ChrootDirectory” tworzy bardzo kontrolowane, izolowane środowisko przesyłania. Uwaga dodatkowa: jeśli chcesz, aby działały, domyślny katalog i umask muszą być ustawione w ForceCommand, a nie w Subsystemdyrektywie.
Marcin
Dłuższy artykuł wyjaśniający to jest dostępny na debian-administration.org/article/590/…
koppor
7

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

syn-
źródło
Popieram to. scponlyjest specjalnie zaprojektowany do tego celu.
UtahJarhead,
1
scponly wydaje się martwy. wygląda na to, że debian go usunął: packages.debian.org/search?ke words=scponly, a kod na github też nie działa. Dalsza dyskusja: serverfault.com/questions/726519/…
koppor
3

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.

Ian Ellis
źródło
2

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ę.

Zypher
źródło
2

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)

Phil
źródło
3
To całkiem fajne - ale wyobrażam sobie, że można to obalić, wydając polecenie, które wykonuje scp, a następnie uruchom skrypt!
davidgo,
@davidgo przygotowując $ SSH_ORIGINAL_COMMAND z exec może rozwiązać tę lukę, zakładając, że scp i rsync nie próbują uruchamiać wielu programów (w takim przypadku to by to zepsuło)
Phil
Również należy zrobić ~/.ssh/authorized_keys, ~/.bashrc(i co tam jeszcze Bash wykonuje) i ~/.ssh/rctylko do odczytu dla użytkownika. Ale jeśli złośliwy użytkownik ma dostęp do rsync lub sftp, nadal może go usunąć ~/.bashrci przesłać nowy. Ponieważ jest trudny do ochrony, odradzam tę metodę ( command="...").
pkt
1
@pts możesz sprawić, że zarówno pliki rc, jak i zawierające je katalogi będą własnością kogoś innego niż użytkownik (nikt?) i nie będą zapisywane przez użytkownika. Ale w tym momencie lepiej użyć czegoś dedykowanego, takiego jak rssh. Wow, właśnie zdałem sobie sprawę, że to moja odpowiedź! To jest stare! Ha ha!
Phil
Nie zapominaj, że scp -S ... i rsync -e ... pozwalają użytkownikowi wykonywać dowolne polecenia. Więc powinieneś sprawdzić argumenty w $ SSH_ORIGINAL_COMMAND przed jego wykonaniem. Więcej informacji tutaj: exploit-db.com/exploits/24795
pts
1

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:

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ń.

pkt
źródło
0

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

jizaymes
źródło
1
Zdecydowanie odradzam proponowane rozwiązanie, ponieważ złośliwy użytkownik jest zbyt łatwy do obejścia (np. Poprzez przesłanie innego ~/.bashrc). Jest także niestabilny w tym sensie, że być może nowsze wersje OpenSSH ustawiłyby TERMzmienną inaczej, lub niektóre ustawienia konfiguracji sshd mogą mieć wpływ TERM.
pkt
1
Ehhh ... ssh -o SetEnv TERM=dumb yourserver bash??
ulidtko