SSH bez pozyskiwania .bashrc
Eksperymentowałem z moim .bashrcplikiem, logując się zdalnie na serwer przez SSH. Nieumyślnie zostawiłem exittam znak, który spowodował natychmiastowe rozłączenie wszystkich kolejnych logowań. Zostałem skutecznie zablokowany. Udało mi się odzyskać dostęp dzięki interwencji osoby z uprawnieniami roota, ale czy byłoby to możliwe bez pomocy kogoś innego?
Próbowałem robić rzeczy, jak działa ssh <server> 'bash --norc --noprofile'i ssh <server> 'mv .bashrc bashrc-backup', a nawet starają się zastąpić ją siłą scp empty-file <server>:.bashrc. Wydaje się jednak, że wszystkie te opcje polegają na pozyskaniu uszkodzonych plików .bashrcprzed uruchomieniem polecenia, więc żadna z nich nie zadziałała.
Może się zdarzyć, że nie ma wyjścia z tego rodzaju sytuacji. Ale czy to jest zgodne z projektem? Czy jest powód, dla którego tak łatwo jest zablokować sobie system, np. Po prostu biegając ssh <server> 'echo exit > .bashrc'? Czy istnieją sposoby na złagodzenie tego rodzaju błędów?
Odpowiedzi
Jak omówiono w drugiej odpowiedzi, gdy klient SSH łączy się z serwerem OpenSSH, serwer OpenSSH zazwyczaj uruchamia sesję powłoki w imieniu klienta, używając powłoki logowania użytkownika:
- Jeśli klient zażąda sesji interaktywnej, serwer uruchomi powłokę logowania użytkownika.
- Jeśli klient zażąda wykonania polecenia, serwer użyje powłoki logowania użytkownika, aby wykonać polecenie jako polecenie powłoki.
- Narzędzia takie jak
scp,rsynci,gitktóre używają ssh do transportu, zażądają polecenia do uruchomienia w systemie zdalnym, więc należą do # 2.
Jeśli masz coś w plikach startowych powłoki zdalnego użytkownika, co powoduje jej zamknięcie, będziesz miał problemy z wejściem.
SFTP jest jednak przypadkiem szczególnym. Serwer OpenSSH można skonfigurować do obsługi SFTP bez uruchamiania zewnętrznego polecenia. W takim przypadku możesz użyć protokołu sftp, aby połączyć się z serwerem i usunąć, zmienić nazwę lub zmienić .bashrcplik, który powoduje problem.
To zależy od konfiguracji serwera do obsługi protokołu sftp. Może obsługiwać sesje sftp, uruchamiając zewnętrzny program (nazwany sftp-server). W takim przypadku będziesz miał ten sam problem z dostaniem się do programów takich jak scp. Lub serwer może obsługiwać sesję sftp przez coś, co nazywa się „internal-sftp” , co nie wymaga wywoływania powłoki. Zależy to tylko od konfiguracji konkretnego serwera SSH.
Dzieje się tak sshd, ponieważ składnik po stronie serwera wywołuje procesy przy użyciu powłoki. Jeśli tworzy powłokę interaktywną, tworzy ją jako powłokę logowania; w przeciwnym razie używa -cargumentu do tworzenia powłoki nieinteraktywnej w celu uruchomienia określonego polecenia.
Wszystkie operacje, które podałeś (określone polecenia i scp) są operacjami nieinteraktywnymi, więc normalnie bash nie ładuje się .bashrc, ale bash ma specjalną wielkość liter, gdy jest wywoływany przez, sshdwięc i tak go wywołuje. Gdybyś używał zsh, to .zshenv(które jest wywoływane dla wszystkich powłok) zostałoby załadowane, ale .zshrc(które jest przeznaczone tylko dla powłok interaktywnych) nie byłoby, chyba że ładujesz sesję powłoki.
W takim przypadku, jeśli używasz basha, nie masz szczęścia. Nie ma sposobu, aby wywołać polecenie SSH po stronie serwera bez użycia powłoki; dotyczy to nawet scp i sftp. W większości przypadków chcesz używać powłoki, ponieważ konfiguruje ona takie rzeczy, jak PATHdla różnych programów i pozwala na rozsądną liczbę skryptów złożonych poleceń, więc OpenSSH zawsze jej używa.
Ma to również pewne korzyści w zakresie bezpieczeństwa: jeśli spróbujesz zalogować się na koncie systemowym, które w jakiś sposób ma poprawne hasło, lecz skorupę /usr/sbin/nologinlub /bin/false, to nie można nic zrobić, co jest chyba to, co przeznaczone administrator systemu.
Istnieją sposoby na złagodzenie tego. Wiele osób utrzymuje repozytorium Git swoich plików dotfiles i tworzy je w jednym systemie, a następnie wdraża w innych. Na przykład, zawsze tworzę pliki dotfile na moim laptopie. Prawdopodobnie zauważysz ten problem nieco wcześniej, jeśli za każdym razem, gdy otworzysz nowe okno terminala, zostanie ono natychmiast zamknięte i możesz mieć uprawnienia administratora, aby naprawić to samodzielnie.
Jeśli chcesz przetestować konfigurację, która może Cię zablokować, na przykład konfigurację powłoki lub sudoerszmianę, możesz zostawić jedną powłokę (odpowiednio normalną lub root) otwartą, a następnie przeprowadzić testy, więc jeśli coś zepsujesz, nadal masz sposób, aby to cofnąć.