Jak ograniczyć użytkownika SSH, aby zezwalał tylko na tunelowanie SSH?

Jak mogę ograniczyć użytkownika na serwerze SSH, aby zezwolić mu tylko na uprawnienia do SSH TUNNELING ? tzn. nie mogą uruchamiać poleceń, nawet jeśli logują się przez SSH.

Moje serwery Linux to Ubuntu 11.04 i OpenWrt.

linux ssh account-restrictions

— LanceBaynes
źródło

Odpowiedzi:

Po stronie serwera można to ograniczyć, ustawiając jego powłokę użytkownika na /bin/true. Pozwoli im to na uwierzytelnienie, ale nie uruchomią niczego, ponieważ nie dostaną powłoki do uruchomienia. Oznacza to, że będą ograniczeni do dowolnej części rzeczy, które SSH może im zaoferować. Jeśli oferuje przekierowanie portów, nadal będą mogli to zrobić.

Po stronie klienta prawdopodobnie będziesz chciał połączyć się z -N. To powstrzymuje klienta od ZADANIA o zdalne polecenie, takie jak powłoka, po prostu zatrzymuje się po zakończeniu części uwierzytelniania. _{Dzięki komentatorom za zwrócenie na to uwagi.}

— Caleb
źródło

Spróbuję tego: P thx!

— LanceBaynes

Aby dodać do odpowiedzi Caleba, może być również konieczne poinformowanie klienta, aby nie wykonywał powłoki. W wierszu polecenia openssh odbywa się to za pomocą flagi -N. Istnieje podobna opcja w PuTTY, ale nie pamiętam dokładnej nazwy.

— Bill B

hmm, to w zasadzie bezpieczeństwo po stronie klienta, nie? Szukam ustawienia zabezpieczeń po stronie serwera, ale dziękuję!

— LanceBaynes,

Przepraszam, nie byłem jasny - miałem na myśli w połączeniu z ustawieniem serwera. Z mojego doświadczenia wynika, że jeśli ustawisz powłokę na coś, co nie jest powłoką, nie możesz się w ogóle połączyć, ponieważ próbuje otworzyć powłokę, ale nie może. Zabezpieczenia są więc wymuszane po stronie serwera (metodą Caleba), ale jeśli masz później problemy z połączeniem, może być konieczne ustawienie przełącznika po stronie klienta.

— Bill B

Taki użytkownik tworzysz za pomocą useradd sshtunnel -m -d /home/sshtunnel -s /bin/true.

— fracz

Zaletą tego jest to, że przekazywanie gniazd agentów X11 i SSH jest również niedozwolone, co nadal może być dozwolone w sposób Calebsa. Kolejną zaletą jest to, że jeśli użytkownik będzie mógł zmienić domyślną powłokę w jakikolwiek inny sposób, nadal ograniczy to dostęp SSH tylko do przekazywania dalej TCP.

Umieść w swoim /etc/ssh/sshd_config:

Match User that-restricted-guy
  AllowTcpForwarding yes
  X11Forwarding no
  AllowAgentForwarding no
  ForceCommand /bin/false

aby umożliwić użytkownikowi that-restricted-guyprzekazywanie wszelkich połączeń TCP za pośrednictwem komputera obsługującego SSH (połączenie z tym komputerem, localhosta nawet połączenie z tym komputerem z innymi komputerami).

Jeśli chcesz, aby był jeszcze bardziej restrykcyjny (co jest dobrym pomysłem), możesz również wykonać następujące czynności:

Match User even-more-restricted-guy
  PermitOpen 127.0.0.1:12345
  X11Forwarding no
  AllowAgentForwarding no
  ForceCommand /bin/false

Umożliwi to użytkownikowi even-more-restricted-guyprzekazywanie połączeń tylko do portu TCP 12345.0.0.1 127.0.0.1 (tak jak jest to widoczne na komputerze z włączonym SSH).

Gdy użytkownik normalnie się łączy, zostanie on natychmiast rozłączony, ponieważ /bin/falsepolecenie zostanie uruchomione, co spowoduje jedynie natychmiastowe wyjście z kodem 1. Jeśli chcesz tego uniknąć i pozostawić otwarte połączenie przekazujące, dodaj -Nflagę do sshpolecenia. To nie będzie próbowało wykonać żadnego polecenia, ale nadal pozwoli skonfigurować przekazywanie TCP.

Przykład polecenia do przodu, które powinno działać w tej ostatniej konfiguracji:

ssh -L 12345:127.0.0.1:12345 -N even-more-restricted-guy@insert-your-machine

— aef
źródło

Przeformułowałem odpowiedź jako ulepszone rozwiązanie w stosunku do odpowiedzi Calebsa.

— aef

Pewnie. Ja też posprzątałem. Dobrze widzieć nieporozumienie rozwiązane. Dobranoc.

— Jakuje

Możesz kontrolować, co ludzie mogą robić w ssh, dopasowując grupy, zakładając, że twoja wersja ssh jest wystarczająco nowa, aby ją obsługiwać (openssh 5.x +).

Zasadniczo traktujemy ich jak użytkowników sftp, ale zezwalamy na przekazywanie tcp i opcjonalnie określamy miejsca docelowe, do których mogą oni przekierowywać. Jeśli podasz im katalog domowy, ale nie utworzysz w nim żadnych katalogów, nie będą mogli przesyłać żadnych plików, ponieważ nie będą mieli na to pozwolenia.

Match Group                     nicepeople
    PubkeyAuthentication        yes
    PasswordAuthentication      yes
    PermitEmptyPasswords        no
    GatewayPorts                no
    ChrootDirectory             /opt/dummy_location/%u
    ForceCommand                internal-sftp
    AllowTcpForwarding          yes
        PermitOpen              192.168.0.8:22
        PermitOpen              192.168.0.5:8080
    # Or leave out the PermitOpen to allow forwarding to anywhere.
    HostbasedAuthentication     no
    RhostsRSAAuthentication     no
    AllowAgentForwarding        no
    Banner                      none

Możesz powtórzyć te bloki grup dopasowania dla każdej grupy, dla której chcesz zastosować inne zachowanie lub ograniczenia.

Możesz dalej kontrolować, gdzie ta osoba może wejść do sieci za pomocą iptables

/sbin/iptables -I OUTPUT -m owner --gid-owner 500 -j REJECT
/sbin/iptables -I OUTPUT -m owner --gid-owner 500 -m tcp -p tcp -d 192.168.0.0/24 -j ACCEPT

Zakłada się, że GID grupy „nicepeople” wynosi 500.

Niektóre z powyższych opcji ssh są dostępne w starszych wersjach openssh, ale nie w sekcji Dopasuj grupę. Grupa meczów jest bardzo ograniczona w OpenSSH 4.xi wcześniejszych.

— Aaron
źródło