SCP przez połączenie bramy SSH

Mój układ sieci wygląda mniej więcej tak:

Teraz Alice ma dostęp do bramy SSH (tylko brama od teraz) dzięki:

ssh alice@external.ip

i plik autoryzowanych kluczy w bramie wygląda następująco

#/home/Alice/.ssh/authorized_keys
command="ssh -t alice@web" ssh-rsa ABCD...E== alice@somehost

więc kiedy Alice próbuje połączyć się z Bramą za pomocą swojego klucza prywatnego, faktycznie łączy się z serwerem sieciowym (komputer bramy może nawiązać połączenie z serwerem WWW za pomocą klucza prywatnego bez hasła, aby zachować przejrzystość).

Pytanie

1. Jak mogę to skonfigurować, aby Alice mogła również scpować różne rzeczy na serwerze WWW?

2. Wiem, że tworzy to osobne połączenie, ale czy jest jakiś sposób, aby działało to jak zwykły ssh, aby nawet coś takiego -R12345:localhost:22działało?

Jeśli chcesz uzyskać dostęp do serwera ssh za innym serwerem ssh, po prostu użyj „ProxyCommand”. Przykład: dodaj do .ssh / config

Host Alice  
   User myLoginAtAlice # optional 
   ProxyCommand ssh -o Compression=no gateway netcat -w 90 %h %p
   ServerAliveInterval 30
   Compression yes

Host gateway
   HostName gateway.public.ip
   User myLoginAtTheGateway # optional 
   Compression yes

Następnie możesz po prostu „ssh Alice”, „rsync” lub „scp” bezpośrednio, używając „Alice” jako nazwy hosta. Magia jest ukryta dla klienta.

Pozwala to szybko zmienić konfigurację ssh na wypadek zmiany topologii / konfiguracji sieci i po prostu zmienić .ssh / config, zamiast zmieniać każdy skrypt.

Objaśnienie: ssh używa polecenia podanego jako „polecenie proxy” jako transportu zamiast bezpośredniego połączenia TCP. Netcat to narzędzie sieciowe, które (spośród milionów innych funkcji) po prostu przekierowuje swoje stdin / stdout do określonego zdalnego hosta. Zatem „ssh gateway nc sshserver 22” łączy cię z serwerem ssh tego komputera. % h to nazwa hosta, a% p to port. Taka konfiguracja pozwala określić „Port N”, aby zmienić port bez zmiany linii ProxyCommand.

Aktywuję kompresję na końcowym komputerze i wyłączam zewnętrzną kompresję, ponieważ kompresja zaszyfrowanych lub skompresowanych danych nie zmniejsza już objętości danych. Wszelkie manipulowanie przy ustawieniach kompresji jest oczywiście opcjonalne.

Miałem dokładnie taki sam problem jak ten, ale udało mi się działać bez radykalnej zmiany wszystkiego.

Wszystko, co zrobiłem, to dodać $ SSH_ORIGINAL_COMMAND do bramy uprawnionych kluczy, aby przekazać wszystko przez łańcuch do końcowego serwera.

Więc to:

#/home/Alice/.ssh/authorized_keys
command="ssh -t alice@web" ssh-rsa ABCD...E== alice@somehost

Staje się:

#/home/Alice/.ssh/authorized_keys
command="ssh -q -t alice@web $SSH_ORIGINAL_COMMAND" ssh-rsa ABCD...E== alice@somehost

-Q służy do pomijania komunikatu o zamknięciu połączenia z maszyny punktu końcowego, więc nie kończy się na lokalnym wyjściu, jeśli używasz przekierowania lokalnie.

Następnie możesz użyć scp w następujący sposób:

scp localFileName alice@exernal.ip:/path/on/end/point/remoteFileName

Ma to tę dodatkową zaletę, że pozwala użytkownikom przekazywać polecenia za pomocą poleceń do serwera punktu końcowego i uzyskiwać wyniki z powrotem w lokalnej sesji, aby mogli przekierować je do pliku lub potokować do innego programu.

Na przykład:

ssh -t alice@external.ip "ls -l" > tmp

Działa to, ponieważ wydaje się, że sshd zapełnia zmienną środowiskową $ SSH_ORIGINAL_COMMAND za pomocą polecenia określonego przez klienta ssh, ale nie jestem pewien, dlaczego to cudownie pozwala scp przejść do komputera końcowego, a także poleceń.

Niestety przekierowanie portów nie pomogłoby skopiować plików bezpośrednio ze stacji roboczej Alicji na serwer sieciowy przy użyciu scp. W tym poście SO wyjaśniłem, dlaczego ssh (i scp, ponieważ wykorzystuje te same mechanizmy uwierzytelniania) nie będzie działać dla połączeń przekazywanych przez port za pomocą ssh.

Opcją byłoby skonfigurowanie serwera VPN na komputerze działającym teraz jako brama SSH, połączenie się z nim, a następnie bezpośredni dostęp do dowolnej maszyny za zaporą ogniową.