Pozwól użytkownikowi skonfigurować tunel SSH, ale nic więcej

Chciałbym zezwolić użytkownikowi na skonfigurowanie tunelu SSH do określonej maszyny na określonym porcie (powiedzmy, 5000), ale chcę ograniczyć tego użytkownika tak bardzo, jak to możliwe. (Uwierzytelnianie będzie odbywać się za pomocą pary kluczy publiczny / prywatny).

Wiem, że muszę edytować odpowiedni plik ~ / .ssh / allowed_keys, ale nie jestem pewien, jaką dokładnie zawartość tam umieścić (poza kluczem publicznym).

W Ubuntu 11.10 stwierdziłem, że mogę blokować polecenia ssh, wysyłane z i bez -T oraz blokować kopiowanie scp, jednocześnie pozwalając na przekazywanie portów.

W szczególności mam serwer redis na "somehost" powiązany z localhost: 6379, który chcę bezpiecznie udostępniać przez tunele ssh do innych hostów, które mają plik klucza i ssh ssh za pomocą:

$ ssh -i keyfile.rsa -T -N -L 16379:localhost:6379 someuser@somehost

Spowoduje to, że serwer redis, „localhost”, port 6379 na „somehost”, pojawi się lokalnie na hoście wykonującym polecenie ssh, przemapowany na port „localhost” 16379.

Na zdalnym „jakimś hoście” Oto czego użyłem do autoryzacji kluczy:

cat .ssh/authorized_keys   (portions redacted)

no-pty,no-X11-forwarding,permitopen="localhost:6379",command="/bin/echo do-not-send-commands" ssh-rsa rsa-public-key-code-goes-here keyuser@keyhost

No-pty wyzwala większość prób ssh, które chcą otworzyć terminal.

Zezwolenie otwarte wyjaśnia, które porty mogą być przekierowywane, w tym przypadku port 6379 jest portem serwera redis, który chciałem przekierować.

Polecenie = "/ bin / echo do-not-send-commands" odbija echo "do-not-send-commands", jeśli komuś lub czemuś udało się wysłać polecenia do hosta przez ssh -T lub w inny sposób.

Z najnowszego Ubuntu man sshd, Authorized_keys / command jest opisane w następujący sposób:

command = "polecenie" Określa, że ​​polecenie jest wykonywane zawsze, gdy ten klucz jest używany do uwierzytelniania. Polecenie podane przez użytkownika (jeśli istnieje) jest ignorowane.

Próby użycia bezpiecznego kopiowania plików scp również kończą się niepowodzeniem z echem „nie wysyłaj-polecenia”. Odkryłem, że sftp również nie działa w tej konfiguracji.

Myślę, że sugestia powłoki ograniczonej, przedstawiona w niektórych poprzednich odpowiedziach, jest również dobrym pomysłem. Zgadzam się również, że wszystko, co tu wyszczególniono, można ustalić czytając „man sshd” i wyszukując w nim „author_keys”

Prawdopodobnie będziesz chciał ustawić powłokę użytkownika na powłokę z ograniczeniami . Usuń ustawienie zmiennej PATH w ~ / .bashrc lub ~ / .bash_profile użytkownika, a użytkownik nie będzie mógł wykonywać żadnych poleceń. Później, jeśli zdecydujesz, że chcesz zezwolić użytkownikowi (użytkownikom) na wykonywanie ograniczonego zestawu poleceń, na przykład lesslub tailna przykład, możesz skopiować dozwolone polecenia do oddzielnego katalogu (takiego jak /home/restricted-commands) i zaktualizować ścieżkę PATH, aby wskazywała na ten katalog.

Oprócz opcji authorised_keys, takiej jak no-X11-forwarding, jest dokładnie taka, o którą prosisz: allowopen = "host: port". Korzystając z tej opcji, użytkownik może skonfigurować tunel tylko do określonego hosta i portu.

Aby uzyskać szczegółowe informacje na temat formatu pliku AUTHORIZED_KEYS, zobacz man sshd.

Moim rozwiązaniem jest zapewnienie użytkownikowi, który może tylko tunelować, bez interaktywnej powłoki , aby ustawić tę powłokę w / etc / passwd na / usr / bin / tunnel_shell .

Po prostu utwórz plik wykonywalny / usr / bin / tunnel_shell z nieskończoną pętlą .

#!/bin/bash
trap '' 2 20 24
clear
echo -e "\r\n\033[32mSSH tunnel started, shell disabled by the system administrator\r\n"
while [ true ] ; do
sleep 1000
done
exit 0

W pełni wyjaśnione tutaj: http://blog.flowl.info/2011/ssh-tunnel-group-only-and-no-shell-please/

Mogę skonfigurować plik authorised_keys z kluczem publicznym, aby się zalogować. Nie jestem pewien co do dodatkowych informacji, których potrzebuję, aby ograniczyć uprawnienia tego konta. Na przykład wiem, że mogę umieścić polecenia takie jak:

no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding

Chciałbyś, aby wiersz w pliku authorised_keys wyglądał następująco.

permitopen="host.domain.tld:443",no-pty,no-agent-forwarding,no-X11-forwardi
ng,command="/bin/noshell.sh" ssh-rsa AAAAB3NzaC.......wCUw== zoredache 

Jeśli chcesz zezwolić na dostęp tylko dla określonego polecenia - takiego jak svn - możesz również określić to polecenie w pliku kluczy autoryzowanych:

command="svnserve -t",no-port-forwarding,no-pty,no-agent-forwarding,no-X11-forwarding [KEY TYPE] [KEY] [KEY COMMENT]

Z http://svn.apache.org/repos/asf/subversion/trunk/notes/ssh-tricks

Tutaj masz fajny post, który uznałem za przydatny: http://www.ab-weblog.com/en/creating-a-restricted-ssh-user-for-ssh-tunneling-only/

Pomysł jest następujący: (z nową zastrzeżoną nazwą użytkownika „sshtunnel”)

useradd sshtunnel -m -d /home/sshtunnel -s /bin/rbash
passwd sshtunnel

Zauważ, że używamy rbash (limited-bash), aby ograniczyć to, co może zrobić użytkownik: użytkownik nie może cd (zmieniać katalogu) i nie może ustawiać żadnych zmiennych środowiskowych.

Następnie edytujemy zmienną env użytkownika PATH /home/sshtunnel/.profilena nic - sztuczka, która sprawi, że bash nie znajdzie żadnych poleceń do wykonania:

PATH=""

Na koniec nie zezwalamy użytkownikowi na edycję jakichkolwiek plików, ustawiając następujące uprawnienia:

chmod 555 /home/sshtunnel/
cd /home/sshtunnel/
chmod 444 .bash_logout .bashrc .profile

Zrobiłem program w C, który wygląda następująco:

#include <stdio.h>
#include <unistd.h>
#include <signal.h>
#include <stdlib.h>
void sig_handler(int signo)
{
    if (signo == SIGHUP)
        exit(0);
}

int main()
{
    signal(SIGINT, &sig_handler);
    signal(SIGTSTP, &sig_handler);

    printf("OK\n");
    while(1)
        sleep(1);
    exit(0);
}

Ustawiłem powłokę użytkownika z ograniczeniami na ten program.

Nie sądzę, żeby użytkownik z ograniczeniami mógł cokolwiek wykonać, nawet jeśli to robi ssh server command, ponieważ polecenia są wykonywane przy użyciu powłoki, a ta powłoka niczego nie wykonuje.

Zobacz ten post na temat uwierzytelniania kluczy publicznych .

Dwie główne rzeczy, o których musisz pamiętać, to:

1. Upewnij się, że chmod 700 ~/.ssh
2. Dołącz blok kluczy publicznych do kluczy autoryzowanych

Wygenerujesz klucz na maszynie użytkownika za pośrednictwem dowolnego używanego przez nich klienta ssh. Na przykład PUTTY ma narzędzie do robienia dokładnie tej rzeczy. Wygeneruje zarówno klucz prywatny, jak i publiczny.

Zawartość wygenerowanego pliku klucza publicznego zostanie umieszczona w pliku Authorized_keys.

Następnie należy upewnić się, że klient ssh jest skonfigurowany do używania klucza prywatnego, który wygenerował klucz publiczny. Jest to dość proste, ale nieco różni się w zależności od używanego klienta.