przesłać informacje o połączeniu z klienta ssh do serwera ssh

1

Załóżmy, że mam następującą sesję ssh:

userA@boxA -> userB@boxB -> userC@boxC

teraz, boxCjako userC, chciałbym mieć informację, że pochodzi połączenie ssh, z userB@boxBktórego z kolei pochodzi userA@boxA.

teraz mam następującą sesję ssh wraz z pierwszą sesją ssh:

userD@boxD -> userB@boxB

od boxB, ponieważ userBchciałbym mieć informację, że połączenie pochodzi userD@boxDi że nadchodzi druga sesja ssh userA@boxA.

czy te informacje są dostępne i dostępne dla użytkownika? czy to w ogóle jest dostępne?

jeśli nie, to czy istnieje „łatwy” sposób na udostępnienie tych informacji? z easy mam na myśli bez hakowania i ponownej kompilacji sshd i bez konieczności posiadania uprawnień roota na komputerach.

ssh sshd lesmana
źródło
Jeśli masz współpracę użytkownika A i użytkownika B, zobacz Kiedy podczas ssh'ing, jak mogę ustawić zmienną środowiskową na serwerze, która zmienia się między sesjami?
Gilles

Odpowiedzi:

2

Oficjalnym sposobem wysyłania zmiennych środowiskowych z klienta na serwer jest SendEnvi AcceptEnv. Problem polega na tym, że do skonfigurowania potrzebujesz dostępu do roota na serwerze AcceptEnv. Większość serwerów jest skonfigurowana tak, aby nie przyjmować żadnych określonych zmiennych lub tylko kilka z nich.

Znalazłem dwie sztuczki, aby przesłać zmienne środowiskowe z klienta na serwer, obie działają bez potrzeby dostępu do konta root na serwerze.

sztuczka pierwsza:

ssh -t server SSH_ORIGIN=$USERNAME@$HOSTNAME bash

to połączy się z serwerem, a następnie wykona polecenie SSH_ORIGIN=$USERNAME@$HOSTNAME bash, z $USERNAMEi $HOSTNAMEjuż zastąpione po stronie klienta. następnie po stronie serwera możesz dalej przetwarzać informacje zawarte w zmiennej SSH_ORIGIN.

-tpotrzebna jest inaczej bash zostanie uruchomiony na serwerze bez tty (spróbuj go widać).

niewielka modyfikacja pozwoli na tranzyt informacji w dłuższym łańcuchu ssh.

ssh -t server SSH_ORIGIN=$USERNAME@$HOSTNAME:$SSH_ORIGIN bash

dyskusja:

  • bash jest uruchamiany jako interaktywna powłoka niezalogowana ( .profilenie jest czytana).
  • bash jest uruchamiany dwukrotnie ( .bashrcjest odczytywany dwukrotnie). raz przez sshd i raz przez polecenie użytkownika.
  • zawsze zacznie bash, ignorując domyślną powłokę na serwerze.

sztuczka druga:

najpierw musisz wygenerować klucz ssh i przenieść go ~/.ssh/authorized_keysna serwer. następnie dodaj linię za pomocą command="$SHELL". zobacz stronę man sshd, aby uzyskać więcej informacji na ten temat.

połącz się z serwerem ssh za pomocą polecenia:

ssh -t server SSH_ORIGIN=$USERNAME@$HOSTNAME

połączy się to z serwerem, ale tym razem przypisanie zmiennej nie zostanie wykonane. zamiast tego ciąg jest przechowywany w zmiennej środowiskowej $SSH_ORIGINAL_COMMAND. następnie ~/.ssh/authorized_keyswykonywane jest polecenie podane w . gdy znajdziesz się w powłoce, możesz przetwarzać informacje zawarte w $SSH_ORIGINAL_COMMAND.

jak wyżej, możesz zrobić to przechodnie:

ssh -t server SSH_ORIGIN=$USERNAME@$HOSTNAME:$SSH_ORIGIN

dyskusja:

  • uruchomi domyślną powłokę na serwerze.
  • zawsze uruchomi domyślną powłokę na serwerze. każde polecenie, które podasz ssh, zostanie zignorowane i zapisane w $SSH_ORIGINAL_COMMAND. jeśli chcesz wykonać polecenie za pomocą ssh, możesz użyć innego klucza ssh lub mieć plik inicjujący powłoki w celu wykrycia i wykonania $SSH_ORIGINAL_COMMAND.
lesmana
źródło
Wiele serwerów jest skonfigurowanych do przepuszczania LC_*zmiennych (są one zwykle używane przez ustawienia narodowe, ale można je obalić). Na przykład LC_FOO=bar ssh localhost 'echo $LC_FOO'wyświetla się barna moim komputerze w domyślnej konfiguracji (na ściśnięciu Debiana).
Gilles
@Gilles Tak, jeśli serwer to zaakceptuje LC_*, możesz użyć tego do wkradnięcia się do zmiennej. Spotkałem naprawdę paranoicznych sysadminów, których serwery nie akceptują nawet standardowych LC_*zmiennych, po prostu w ogóle nie akceptują żadnych zmiennych.
lesmana
1

To polecenie whoinformuje, kto jeszcze jest zalogowany na tym samym komputerze i skąd się zalogował. Komenda lastpodaje te same informacje dla poprzednich sesji. W zależności od konfiguracji komputera i metod logowania informacje nie zawsze są kompletne, aktualne lub dostępne dla użytkowników innych niż root.

W twoim scenariuszu A @ A-> B @ B-> C @ C z maszyny C nie można wiedzieć, że B @ B był zalogowany do B za pośrednictwem sesji ssh z A. W latach 80., kiedy wszyscy ufali wszystkim, ty mógł próbować fingerlub ident, ale w dzisiejszych czasach maszyna B prawdopodobnie nie uruchomi nawet demona finger lub ident.

Gilles
źródło
1

Myślę, że możesz zmusić zmienną środowiskową na hoście B do napisania adresu hostA. Następnie na hostC użyj AcceptEnv, aby uzyskać środowisko z hostB, voila :)

przeczytaj trochę sshd_config, części dotyczące środowiska.

damir
źródło
działałoby to tylko w przypadku pełnej współpracy B. W żaden sposób C nie może sprawdzić, czy wartość wysłana przez B jest dokładna, czy sfabrykowana.
Gilles,
AcceptEnv może służyć do przekazywania potrzebnych informacji. niestety tylko root może ustawić AcceptEnv i domyślnie nie przyjmuje żadnych zmiennych środowiskowych. nie mam dostępu root do większości maszyn, do których ssh.
lesmana,
0

Ze skrzynki C, bez dostępu do skrzynki B, nie będziesz w stanie powiedzieć, że użytkownik przyszedł ze skrzynki A. W rzeczywistości możesz nie być w stanie powiedzieć, w jaki sposób użytkownik dotarł do skrzynki C. To po prostu zależy od tego, jak administrator skonfigurował ustawienia.

Ta sama odpowiedź na pytanie „przypuśćmy dalej”. Zależy to od uprawnień udzielonych przez administratora systemu i zainstalowanych przez niego programów.

Odpowiednie polecenia, które mogłyby ci pomóc, gdybyś miał uprawnienia (ale prawdopodobnie nie masz):

finger - http://www.manpagez.com/man/1/finger/

last - http://www.manpagez.com/man/1/last/
dggoldst
źródło