sprawdź konfigurację sshd

19

Jak mogę zweryfikować konfigurację sshd?

Na przykład chcę się upewnić, że te ustawienia są ustawione i zastosowane:

AllowUsers user1 user2 
PasswordAuthentication no
PermitRootLogin no

Czy jest to jedyny sposób ręcznej weryfikacji zawartości pliku sshd_config, czy też mogę sprawdzić, czy mam sshdpewność?

ssh configuration

— JuanPablo
źródło

2

Co rozumiesz przez weryfikację? Czy pytasz, jak upewnić się, że dokonana zmiana konfiguracji jest poprawna? Czy pytasz, czy istnieje narzędzie takie jak kłaczek , które sprawdza poprawność konfiguracji?

— Zoredache,

2

Nie sądzę, by pytanie było niejasne: po prostu nie ma możliwości sprawdzenia, jaka jest wartość opcji konfiguracji. Jeśli widzisz #UseLogin now swoim pliku ssd_config, oznacza to, że UseLogin to yes lub UseLogin is no? Musisz więc odnieść się do instrukcji, aby znaleźć wartość domyślną, którą można zmienić podczas kompilacji. Jak na razie bezużyteczne pytanie ...

— Xorax,

27

Istnieje rozszerzony tryb testowy, wywoływany z opcją wiersza poleceń -T, która to robi. Na przykład:

% sudo sshd -T | egrep -i 'allowusers|passwordauth|permitroot'
permitrootlogin yes
passwordauthentication yes

Opcja istnieje w Portable OpenSSH od 2008 r., Por. zatwierdzić e7140f2 . Zostało to wydane w wersji 5.1p1, wyprodukowanej w lipcu 2008 r., Por. informacje o wersji 5.1 , więc istnieje ona w prawie wszystkich obsługiwanych obecnie instalacjach serwerów OpenSSH.

— Josip Rodin
źródło

3

Zauważ jednak, że pokaże to ustawienia domyślne + ustawienia z /etc/ssh/sshd_configpliku. Ustawienia z pliku mogą jeszcze nie być aktywne, dopóki sshdnie zostaną ponownie załadowane z czymś podobnym /etc/init.d/ssh reloadlub równoważnym w twoim systemie.

— mivk 30.10.16

2

@mivk dobra uwaga, ale jest to prawie takie samo, jak w przypadku kursu, ponieważ typowe jest, że używamy tego rodzaju poleceń dokładnie po wprowadzeniu zmian, ale przed ich faktycznym zastosowaniem, ponieważ chcemy sprawdzić, co się stanie. Na przykład apache2ctl -Szachowuje się w ten sam sposób.

— Josip Rodin

4

Chociaż nie zrzuci wszystkie definicje serwerze, można spróbować połączyć się z serwerem z gadatliwym flagi debugowania: ssh -v user@server. To da ci wiele informacji, które odzwierciedlą opcje włączone w konfiguracji sshd.

Na przykład spójrz na wynik tego połączenia za pomocą przełącznika -v (celowo ukryte podpisy kluczy, domeny i adresy IP):

OpenSSH_6.0p1, OpenSSL 0.9.8w 23 Apr 2012
debug1: Reading configuration data /home/claudio/.ssh/config
debug1: /home/claudio/.ssh/config line 13: Applying options for serv01
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to somedomain.com [185.113.29.221] port 22.
debug1: Connection established.
debug1: identity file /home/claudio/.ssh/id_dsa type 2
debug1: identity file /home/claudio/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9
debug1: match: OpenSSH_5.9 pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 3a:0d:b8:18:ca:67:4c:54:0f:c8:b2:1e:48:53:69:28
debug1: Host '[somedomain.com]:22' is known and matches the ECDSA host key.
debug1: Found key in /home/claudio/.ssh/known_hosts:7
Warning: Permanently added the ECDSA host key for IP address '[185.113.29.221]:22' to the list of known hosts.
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering DSA public key: /home/claudio/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 433
debug1: Authentication succeeded (publickey).
Authenticated to somedomain.com ([185.113.29.221]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.

Z tego widać, że dozwolone metody uwierzytelniania to: klucz publiczny, hasło, interaktywna klawiatura. Możesz także zobaczyć, że roaming nie jest dozwolony przez ten serwer i że użytkownik claudio może połączyć się przy użyciu swojego klucza publicznego.

Możesz zwiększyć poziom wyjściowej informacji, określając więcej liter „v”, ale wtedy możesz uzyskać znacznie więcej informacji na niskim poziomie, niż prawdopodobnie chcesz.

— Claudio
źródło

3

konfiguracja sshd jest zwykle znajduje się w poniższym pliku: /etc/ssh/sshd_config.

Aby wysłać zapytanie o konfigurację środowiska wykonawczego, można użyć rozszerzonego trybu testowego, sshd -Tktóry pozwala również przetestować dopasowanie ustawień klienta.

— rodzic
źródło

1

Nie sądzę, że to odpowiada na pytanie, które zadaje, ale jego pytanie nie jest całkowicie jasne.

— Zoredache,

1

Wygląda na to, że pyta, jak zweryfikować konfigurację. O ile mi wiadomo, nie ma możliwości sprawdzenia konfiguracji sshd w czasie wykonywania. Tak więc konfigurację można znaleźć tylko we wspomnianym pliku.

— rodzic

Jak powiedziałeś, pytanie nie ma sensu, więc pomyślałem, że OP nie wiedział, gdzie jest plik ani jaka jest jego dokładna nazwa.

— rodzic

Jeśli zamierzasz głosować za mną bez żadnego ważnego powodu po 4 latach, zastosuj zdrowy rozsądek i sprawdź historię pytań, a następnie zasugeruj edycję.

— gparent

@ rodzic, pierwotne pytanie było nieco niejasne i zawierało literówkę w ścieżce pliku konfiguracyjnego, więc zamiast tego należy użyć funkcji edycji, aby naprawić ten ciąg w pytaniu; i tak czy inaczej, odpowiedź na pytanie weryfikacyjne jest teraz pokazana powyżej

— Josip Rodin

2

myślę, że nie ma znanego sposobu na sprawdzenie konfiguracji działającej instancji sshd, jeśli odwołujesz się do serwera openssh. w zależności od tego, co chcesz zrobić, możesz użyć flagi -t do przetestowania pliku konfiguracyjnego, aby upewnić się, że jest poprawny przed zrestartowaniem serwera, abyś nie został wyrzucony, szczególnie. jeśli nie masz dostępu do serwera poza pasmem.

— johnshen64
źródło

2

Problem z przeglądaniem pliku / etc / ssh / sshd_config, jak sugerują inne odpowiedzi, polega na tym, że niekoniecznie zawiera on całą konfigurację. Ten plik zawiera wartości dowolnych zmiennych konfiguracyjnych, które chcesz ustawić w celu zastąpienia wartości domyślnych, a w dostarczonej postaci zawiera jako komentarze domyślne wartości wbudowane w sshd.

Jeśli zamiast dostarczonej wersji zostanie zainstalowany niestandardowy plik konfiguracyjny, tracisz z oczu domyślne wartości skompilowane w sshd, a jeśli jest to kompilacja niestandardowa, wartości domyślne mogą nie pasować do widocznych komentarzy w sshd_config.

Dodatkowo jest całkowicie możliwe uruchomienie sshd z alternatywnym plikiem konfiguracyjnym z opcją -f, więc plik przechowywany w / etc / ssh / sshd_config może nie odzwierciedlać bieżących ustawień.

To sprawia, że pytanie jest dość ważne i o ile mi wiadomo, nie można na nie odpowiedzieć z całą pewnością.

— Peter Gathercole
źródło

Wszystko to jest prawdą, ale nie dotyczy 99% serwerów, które będą uruchamiały sshd zainstalowane z pakietu, który ma wkompilowaną domyślną konfigurację.

— Andrew Schulman

Twoja odpowiedź jest przydatna, ale na pytanie można odpowiedzieć z całą pewnością, już od dłuższego czasu, proszę zobaczyć moją odpowiedź poniżej.

— Josip Rodin