SSH resetuje do domyślnego portu przy ponownym uruchomieniu


12

Zmieniłem domyślny port SSH na moim serwerze domowym (w /etc/ssh/sshd_configpliku) na port 54747, a następnie ponownie uruchomiłem usługi sshi sshd(nigdy nie wiem, który z nich, więc zrobiłem oba, aby zachować bezpieczeństwo). Aby przetestować moją konfigurację, wylogowałem się, a następnie wróciłem bez problemu.

Kilka dni później zainstalowałem apt aktualizacje, a następnie ponownie uruchomiłem serwer. Kiedy próbowałem ponownie włączyć SSH (na porcie 54747), otrzymałem błąd odmowy połączenia.

Z jakiegoś powodu próbowałem SSH na domyślnym porcie i zadziałało! Wróciłem, żeby sprawdzić sshd_config, ale nadal miał niestandardowy port. Zrestartowałem więc sshi sshdusługi, i wróciłem do „normalnego” zachowania (ssh na porcie 54747). Próbowałem ponownie uruchomić komputer ponownie, a połączenie odmówiło ponownie ...

Czy ktoś wie, co zrobiłem źle?

Dodatkowe informacje:

  • Ubuntu 16.04.2 LTS
  • Serwer jest również używany przez HTPC z otwartą sesją (ten sam użytkownik co SSH) na moim telewizorze
  • SSH korzystam z klucza RSA mojego laptopa i wyłączyłem autoryzację hasła
  • Kiedyś się restartowałem sudo reboot -h now, ale po wyszukiwaniu odkryłem, że niektórzy ludzie go zniechęcili, więc próbowałem sudo reboot, ale żadnych różnic

EDYCJA Sekwencja wydarzeń:

  1. Zmień port SSH z 22 na 54747 w /etc/ssh/sshd_config
  2. Uruchom ponownie usługi ssh i sshd
  3. Zakończ bieżącą sesję SSH
  4. SSH powrócił pomyślnie na porcie 54747
  5. Restart
  6. Błąd połączenia SSH na porcie 54747, ale powodzenie na porcie 22
  7. Uruchom ponownie usługi ssh i sshd
  8. SSH z powrotem pomyślnie na porcie 54747, błąd połączenia na porcie 22
  9. Uruchom ponownie i wróć do 6

EDYCJA 1: netstat wyjście

rgo@ATLAS:~$ sudo netstat -lntp | grep :54747
rgo@ATLAS:~$ sudo netstat -lntp | grep :22
tcp6       0      0 :::22                   :::*                    LISTEN      1/init  

EDYCJA 2: service sshd status

● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
   Active: inactive (dead)

EDYCJA 3: lsof -i | grep ssh

systemd      1     root   46u  IPv6  42724      0t0  TCP ATLAS:ssh->192.168.1.27:49837 (ESTABLISHED)
systemd      1     root   49u  IPv6  14641      0t0  TCP *:ssh (LISTEN)
sshd      4088     root    3u  IPv6  42724      0t0  TCP ATLAS:ssh->192.168.1.27:49837 (ESTABLISHED)
sshd      4088     root    4u  IPv6  42724      0t0  TCP ATLAS:ssh->192.168.1.27:49837 (ESTABLISHED)
sshd      4202      rgo    3u  IPv6  42724      0t0  TCP ATLAS:ssh->192.168.1.27:49837 (ESTABLISHED)
sshd      4202      rgo    4u  IPv6  42724      0t0  TCP ATLAS:ssh->192.168.1.27:49837 (ESTABLISHED)

W celach informacyjnych ATLAS to nazwa hosta serwera zdalnego, 192.168.1.27 to adres IP LAN mojego laptopa, a polecenie zostało wykonane między krokami 6 i 7

ufw status

Status: inactive

EDYCJA 4: ps -ef |grep sshd

root      4088     1  0 22:40 ?        00:00:00 sshd: rgo [priv]
rgo       4202  4088  0 22:40 ?        00:00:00 sshd: rgo@pts/1 sshd

Nie dyskredytuję cię w żaden sposób. Ale wydaje mi się, że nie wpisujesz poleceń na serwerze ssh zgodnie z żądaniem. Nie możesz mieć aktywnych połączeń ssh, gdy demon ssh nie działa ....... na serwerze ssh, ps -ef | grep sshd powinien zwrócić proces / usr / sbin / sshd -D. Jest kilku ludzi, którzy pomagają, ale wysyłają cię we wszystkich kierunkach. Z przyjemnością porozmawiam z Tobą na czacie, jeśli byłoby to dla Ciebie pomocne.
jones0610

Może to dlatego, że mam już sesję z tym samym użytkownikiem otwartą i wyświetlaną na moim telewizorze za pomocą Kodi?
3rgo

Cześć, @ 3rgo, udało ci się to rozwiązać?
pa4080

Cześć ! Nie, wciąż mam ten problem ... Na szczęście nie muszę co jakiś czas restartować mojego serwera domowego, ale wciąż jest to problem, ponieważ psuje niektóre z moich zautomatyzowanych procesów ...
3rgo

Mam kilka pomysłów. (1) Możesz spróbować zmienić port na wartość domyślną, a następnie ponownie uruchomić cały system. Następnie spróbuj zmienić go ponownie na żądaną wartość. (2) Spróbuj na przykład o innej wartości Port 10285. Google pokazuje kilka wyników dla 54747 ... (3) Również serwer SSH może pracować z kilkoma portami jednocześnie. Utwórz dwie osobne dyrektywy dla każdego portu: Port 22a Port 54747następnie otwórz tylko drugą w zaporze. (4) Możesz wypróbować Match LocalPortdyrektywę umieszczoną na początku sshd_c.
pa4080

Odpowiedzi:


2

ssh może być „aktywowane przez gniazdo” przez systemd w zależności od konfiguracji, co oznacza, że ​​początkowo systemd konfiguruje port nasłuchiwania, a sshd jest uruchamiany tylko przy pierwszym połączeniu klienta. Ma to na celu przyspieszenie czasu uruchamiania: demony usług są uruchamiane tylko na żądanie.

Oznacza to jednak, że należy również skonfigurować systemd do pasującego portu. Znajdziesz konfigurację systemu, w /lib/systemd/system/ssh.socketktórej listy ListenStream=22. Aby to zmienić, utwórz plik /etc/systemd/system/ssh.socket.d/port.conf(w ssh.socket.drazie potrzeby utwórz katalog ) zawierający:

[Socket]
ListenStream=
ListenStream=54747

Zmień numer na żądany port. Pierwszy pusty wpis usuwa poprzednie ustawienie domyślne, a następny wpis dodaje nowy. Zastępuje to domyślnie dostarczone /lib/systemd/system/ssh.socketi musi zostać wykonane oprócz zmiany /etc/ssh/sshd_config.

Następnie uruchom, sudo systemctl daemon-reloadaby poinformować systemd o twoich zmianach i sudo systemctl reload sshczy twój demon ssh był wcześniej uruchomiony.


Ta odpowiedź wygląda bardzo obiecująco, ale /etc/systemd/system/ssh.socket.d/port.confjest ignorowana, a ponowne uruchomienie wciąż resetuje port do 22. Czy nazwa pliku jest odpowiednia? Nie można znaleźć dobrej dokumentacji dotyczącej nadpisań systemowych na Ubuntu .
MestreLion

Nazwa pliku nie ma znaczenia, dopóki się kończy .conf. Zobacz systemd-system.conf (5), aby uzyskać szczegółowe informacje na temat plików konfiguracyjnych zastępujących systemd.
Robie Basak

Możesz także uruchomić, systemctl status ssh.socketaby sprawdzić, czy jest włączony i czego nasłuchuje.
Robie Basak

2
To działa!!! Wreszcie ta tajemnica została rozwiązana! Ale potem zauważyłem, że byłem w stanie uzyskać dostęp za pomocą obu portów: domyślnego 22 i niestandardowego. Dodanie ListenStream=linii przed niestandardowym portem zapobiegło temu, nie jestem pewien, dlaczego. Może to „wyczyści” ListenStream=22ustawienie domyślne /lib/systemd/system/ssh.socket? Dziwny sposób na zastąpienie ustawień. Może warto dodać to do odpowiedzi?
MestreLion

@MestreLion ah tak, to prawda. Zaktualizuję odpowiedź. Dzięki!
Robie Basak,

0

Sprawdź ustawienia portu w /etc/ssh/sshd_configpliku. Upewnij się, że edytujesz jako sudo lub użytkownik w grupie sudo. Wszystko, co musisz zrobić, aby ustawić port, to w jednym typie linii Port 54747.Teraz ponownie uruchom usługę ssh, uruchamiając service sshd restart.Następnie sprawdź, czy ssh nasłuchuje na tym porcie, uruchamiając sudo netstat -lntp | grep ssh.Uruchom ponownie i przetestuj.

Sprawdź także ustawienia sieciowe. Jeśli jesteś w sieci firmowej, upewnij się, że jesteś we właściwej sieci vlan.


Zrobiłem kopię zapasową i edytowałem plik jako sudo, i zmieniłem domyślną Port 22linię Port 54747tylko na. Poza tym netstat, który mi dałeś, nie miał żadnego wyjścia. Dodałem zmodyfikowany w moim OP
3rgo

Czy łączysz się z kluczem, prawda? Tak powinno być podłączenie jak: ssh -i key.txt user@ipaddress -p 54747. Sprawdź także, czy coś innego nasłuchuje na tym porcie. Zrobić sudo lsof -i | grep ssh. Możesz także sprawdzić zaporę ogniową, aby upewnić się, że niczego nie blokuje. Zrobić: sudo ufw status.
G_Style

Żaden port nie jest używany w 54747 (patrz mój OP, dodałem go). Do tego
dodaję

Po głębszym zastanowieniu się nad twoim problemem mam wrażenie, że to nie twoja konfiguracja, ale sposób, w jaki się restartujesz, powoduje ten problem. Podczas ponownego uruchamiania należy użyć polecenia shutdown -r now. Spróbuj i daj nam znać wyniki. Zobacz ten artykuł w celach informacyjnych: askubuntu.com/questions/483670/…
G_Style

Właśnie próbowałem i uzyskałem taki sam wynik jak sudo reboot -h nowlub `` sudo reboot``
3rgo

0

Czasami coś idzie nie tak. Gdybym był na twoim miejscu, spróbowałbym z:

cp /etc/ssh/sshd_config $HOME
sudo apt-get --reinstall install openssh-server

Czy będzie to wymagać fizycznego dostępu do serwera? Jeśli tak, mogę to zrobić tylko jutro wieczorem
3

Cześć @ 3rgo, myślę, że nie potrzebujesz dostępu fizycznego. Po prostu próbuję na moim VPS. Również na moim domowym serwerze Ubuntu, gdy byłem zalogowany przez SSH. Nawet połączenie nie zostało przerwane. cppolecenie jest na wszelki wypadek, zwykle proces ponownej instalacji nie dotyka plików konfiguracyjnych.
pa4080

Cześć! Próbowałem ponownie zainstalować, ale nic się nie zmieniło, nadal mam ten sam problem ...
3rgo

0

ssh jest procesem klienta, który arbitrażuje i utrzymuje połączenie sesji użytkownika z serwerem ssh. sshd to demon działający na serwerze ssh, który nasłuchuje i uwierzytelnia żądania połączenia ssh.

Plik konfiguracyjny na serwerze sshd, który jest odczytywany podczas uruchamiania usługi sshd (wymaga edycji uprawnień sudo) to

/etc/ssh/sshd_config

Usługa powinna zacząć się od

/etc/systemd/system/sshd.service

Aby ponownie uruchomić sshd, co wiązałoby się z ponownym odczytaniem pliku sshd_config

sudo service sshd restart

Aby sprawdzić, jakiego portu nasłuchuje demon sshd, a także inne przydatne informacje na temat typu serwera ssh

sudo service sshd status

Wykonaj następujące kroki w określonej kolejności:

Uruchom ponownie serwer ssh

Otwórz sesję terminala na serwerze ssh (nie połączenie z nim ssh)

Rodzaj hostname

Jeśli nazwa hosta nie zwraca nazwy serwera ssh (w tym przypadku atlasu), powtórz poprawnie poprzedni krok.

grep Port /etc/ssh/sshd_config - zanotuj numer portu. Powinien być ten, który podałeś

sudo service sshd status

Jeśli status zgłasza, że ​​jest aktywny, działa i nasłuchuje na określonym porcie niestandardowym, oznacza to, że jesteś dobry w tym zakresie. Jeśli nie, uruchomienie usługi może nie wywoływać zmodyfikowanego pliku sshd_config, ale inny plik konfiguracyjny zawierający informacje domyślne. Jeśli usługa się nie uruchomiła (mówi, że jest martwa, nie jest aktywna i nie działa, to jest to inny problem niż to, o co prosiłeś.

Kroki te prawdopodobnie określą pierwotną przyczynę problemu, o który pytasz.

Dla celów testowych i dla uproszczenia: po stronie klienta, z sesji terminalowej ssh na serwer ssh w następujący sposób

ssh -l username -p 54747 hostname

Na podstawie informacji zwrotnych OP podejrzewam, że sshd nie uruchamia się podczas uruchamiania, ale uruchamia się poprawnie po ręcznym wywołaniu. Pomyślne połączenia ssh przez port 22 mogą NIE być połączone z serwerem ssh, ale z czymś innym (np. Localhost). Aby to udowodnić lub obalić, po podłączeniu przez ssh

hostname

Na podstawie tego, co mówi OP, domyślam się, że nazwa hosta nie będzie atlasem serwera ssh.

Aby to jeszcze bardziej odizolować, po ponownym uruchomieniu serwera ssh, ale zanim zrobisz cokolwiek więcej , z sesji terminala na serwerze ssh (Atlas)

ssh localhost

Jeśli to się nie powiedzie, tak jak powinno, to

ssh -p 54747 localhost

Jeśli to nie zadziała, potwierdzi to wyniki uzyskane podczas działania

sudo service sshd status

Cześć ! Dodałem sekwencję wydarzeń, aby lepiej zrozumieć. I SSH za pomocą polecenia ssh -p <PORT> <USER>@<IP>, z kluczem prywatnym dodanym do agenta.
3rgo

Bardzo dobre. Wykonaj krok 6a: na serwerze sshd status sshd usługi sudo. Jeśli zgłasza port 22, wówczas wywoływany jest fałszywy plik sshd_config.
jones0610

Mówi: „nieaktywne (martwe)” (zobacz pełne wyjście w mojej OP za sekundę)
3rgo

Więc jeśli jest martwy (nieaktywny i uruchomiony), nie łączysz się z maszyną, którą uważasz za swoją. Na serwerze sshd wpisz ps -ef | grep sshd. Jeśli demon sshd na serwerze sshd jest faktycznie martwy, żadne procesy sshd nie będą działały i tym samym nie wygrasz; t będziesz mógł sshd do niego niezależnie od używanego portu.
jones0610

Znaleziono 2 procesy sshd ... Dodałem szczegółowe wyniki
3rgo

0

Prawdopodobnie właśnie odpowiedziałeś Y, gdy apt wykrył różnice między twoim sshd_config a pakietem. Pyta, czy chcesz zainstalować wersję pakietu mantainer, czy zachować swoją.


1
Nie pamiętam, żeby o coś takiego pytano, ale zakładając, że tak jest, co mogę zrobić, aby to naprawić?
3rgo

0

Możliwe przyczyny, o których mogę myśleć

  1. Podczas uruchamiania uruchamiany jest inny plik binarny sshd lub sshd jest uruchamiany z inną konfiguracją. Być może winowajcą jest tutaj systemd - ma inny sposób zmiany portu, /usr/lib/systemd/system/sshd.socketnajwyraźniej poprzez plik : https://www.vultr.com/docs/how-to-change-ssh-port-on-coreos
  2. Prawidłowy / etc / lub / etc / ssh nie jest jeszcze zamontowany podczas uruchamiania sshd, czy jest to osobny wolumin na twoim komputerze, który jest montowany później podczas uruchamiania?
  3. sshd nie ma uprawnień do odczytu pliku konfiguracyjnego podczas rozruchu, chociaż nie wiem czy sshd w ogóle by się wtedy uruchomił.

2
Myślę, że się w to angażujesz. A jeśli jest to serwer, który przeszedł wiele uaktualnień, może jest tam koktajl skryptów startowych (sysv-init, upstart, systemd). Może proste wyszukiwanie i sprawdzenie wszystkich plików w / etc / w find /etc/ -iname "*ssh*"celu znalezienia dodatkowych wskazówek.
Bazz
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.