Co powoduje problemy z SSH po ponownym uruchomieniu serwera 14.04?

Dlaczego ponowne uruchomienie serwera z systemem Ubuntu 14.04 powoduje błędy „Odmowa połączenia”?

Widzę, ssh: connect to host <IP-address-here> port 22: Connection refusedale tylko 14.04 i dopiero po ponownym uruchomieniu. Używam komputera stacjonarnego 12.04. Jak rozwiązać ten problem?

Aby wyjaśnić pytanie, oto, co działa lub nie działa dla mnie:

• SSH do nowej instalacji 12.04> wyloguj się> SSH ponownie> działa
• SSH do nowej instalacji 12.04> uruchom ponownie> SSH ponownie> działa
• SSH do nowej instalacji 14.04> wyloguj się> SSH ponownie> działa
• SSH do nowej instalacji 14.04> uruchom ponownie> SSH ponownie> Połączenie odrzucone

Problem, który mam, jest unikalny dla 14.04 i występuje tylko po ponownym uruchomieniu. Mam kilka serwerów wcześniejszych niż 12.04 i wszystko nadal działa idealnie. Mam nowy serwer, na którym chcę używać 14.04 i chcę zrozumieć, co się dzieje. Jakieś sugestie?

Oto, co próbowałem do tej pory:

sudo traceroute -p 22 -T <IP-address-here>

Traceroute działa dobrze, otrzymuję odpowiedź z serwera na porcie SSH 22.

initctl list
...
ssh start/running, process 23371
...

Wygląda na to, że ssh na serwerze 14.04 jest ustawiony na start przy starcie (zgodnie z oczekiwaniami).

tom@Desktop:~$ ssh -vvv root@<IP-address-here>
OpenSSH_5.9p1 Debian-5ubuntu1.4, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to <IP-address-here> [<IP-address-here>] port 22.
debug1: connect to address <IP-address-here> port 22: Connection refused
ssh: connect to host <IP-address-here> port 22: Connection refused

Edycja: Oto cały syslog ze świeżo utworzonej maszyny . Utworzyłem go, SSH wpuściłem i wydałem reboot nowpolecenie, a następnie dostałem błąd odmowy połączenia po tym, jak czekałem na ponowne uruchomienie i próbę SSH po raz drugi. Twardy restart za pośrednictwem panelu sterowania hosta, a teraz połączenie SSH znów działa.

Szybka odpowiedź:

SSH nie stanowi problemu. Polecenie użyte do ponownego uruchomienia jest problemem: nie rób reboot now, róbreboot anishutdown -r now restartuj systemu.

Składnia polecenia ( od 13.04 ) to:

reboot [OPTION]...  [REBOOTCOMMAND]

The REBOOTCOMMANDWcześniej nigdy nie istniał. W 12.04 twój nowzostał po prostu zignorowany, ale teraz jest używany ... I wszystko psuje.

Długa odpowiedź, z wynikami moich testów i wyjaśnieniem:

Mam podobny problem z niektórymi serwerami z uruchomionym 14.04 ORAZ w VPS (hostowanym u francuskiego dostawcy OVH - z uruchomionym OpenVZ) ORAZ podczas pracy reboot nowwewnątrz samego serwera.

Tak jak ty wydałem polecenie reboot nowz konsoli (zalogowałem się za pomocą SSH). Kilka sekund po naciśnięciu RETURNmoja sesja jest automatycznie rozłączana. Tak jak ty nigdy nie byłem w stanie połączyć się ponownie z serwerem za pośrednictwem SSH po wydaniu tego polecenia.

Postanowiłem więc otworzyć konsolę KVM dostarczoną przez OVH. (emulowanie bezpośredniego dostępu za pomocą klawiatury i ekranu na serwerze fizycznym dla tego rodzaju serwera wirtualnego).

Byłem w stanie połączyć się z moją maszyną i zobaczyłem, że wchodzi w tryb pojedynczego użytkownika, czekając, aż naciśniesz CTRL+, Daby kontynuować lub wprowadź hasło roota, aby przejść do trybu konserwacji. Nacisnąłem kombinację klawiszy, aby kontynuować proces, a następnie mogłem ponownie włączyć SSH do mojego systemu. Jaka była moja niespodzianka po zobaczeniu, uptimeże czas działania nie wynosił 2 lub 3 minuty, ale jeszcze dużo dnia:reboot now wykonany w systemie Ubuntu 14.04 VPS tak naprawdę nie uruchamia się ponownie, ale po prostu prosi o przejście w tryb pojedynczego użytkownika!

Na podstawie tego nauczyłem się nigdy nie prosić o ponowne uruchomienie z poziomu mojego VPS, ale prosić o to z polecenia podanego w interfejsie zarządzania hosta.

Dlatego nie ma problemu z instalacją SSH. Problem polega na pisaniu reboot now. W rzeczywistości przetestowałem go później, jeśli wpiszesz reboot(tylko słowo, brak opcji), zrobiłoby to, co chciałeś zrobić: zrestartować serwer.

Używanie rebootz argumentem (ze strony podręcznika) wywołuje polecenie shutdownz podanymi argumentami. I rzeczywiście, jeśli wykonam shutdown now, mam takie samo zachowanie: system nie jest restartowany, przechodzi w tryb pojedynczego użytkownika.

Uwaga: wygląda na to, że jest to zamierzone zachowanie, ponieważ komunikat pojawiający się na ekranie po usłyszeniu wykonania tego polecenia mówi:

System przejdzie w tryb konserwacji

Tryb konserwacji lub tryb pojedynczego użytkownika, reprezentują to samo, poziom działania z zapisem więcej niż powłoki, bez sieci, bez procesów sieciowych, ...

Może to być mylące, ale należy pamiętać, że poprawne użycie shutdownto na przykład: shutdown -h nowzatrzymanie systemu teraz lub shutdown -r nowjego ponowne uruchomienie. Nie wiedziałem, że system shutdown nowprzejdzie tylko w tryb pojedynczego użytkownika. Zazwyczaj robię to, init Saby to osiągnąć.

Mogę się spóźnić i może to być oczywiste, ale działało dla mnie sprawdzenie pliku konfiguracyjnego /etc/ssh/sshd_config: uruchomienie demona z /etc/init.d/ssh startdowolną inną kombinacją pokazało, że usługa działała, chociaż tak nie było, ale jeśli uruchomię plik wykonywalny z jego bezwzględna ścieżka (w moim przypadku /usr/sbin/sshd) Widziałem, że na końcu pliku konfiguracyjnego było dołączone „0B”, które powodowało błąd podczas uruchamiania, usunięcie go rozwiązało problem.

Inną potencjalną przyczyną jest ufwutrata konfiguracji reguły portu SSH. Zdarzyło mi się to co najmniej raz lub dwa razy, gdy po zastosowaniu aktualizacji i ponownym uruchomieniu komputera konfiguracja zapory blokowała dostęp do serwera. Korzystanie z funkcji konsoli VPS mojego dostawcy hostingu pozwoliło mi dostać się na maszynę i zdiagnozować problem. Przykład poniżej pokazujący problem (tj. Brak wpisu dla portu 22):

user@host:~$ sudo ufw status verbose
[sudo] password for user:
Status: active
Logging: on (low)
    Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
80,443/tcp (Nginx Full)    ALLOW IN    Anywhere
25/tcp                     ALLOW IN    Anywhere
143                        ALLOW IN    Anywhere
110                        ALLOW IN    Anywhere
993/tcp (Dovecot Secure IMAP) ALLOW IN    Anywhere
995/tcp (Dovecot Secure POP3) ALLOW IN    Anywhere
25/tcp (Postfix)           ALLOW IN    Anywhere
465/tcp (Postfix SMTPS)    ALLOW IN    Anywhere
80,443/tcp (Nginx Full (v6)) ALLOW IN    Anywhere (v6)
25/tcp (v6)                ALLOW IN    Anywhere (v6)
143 (v6)                   ALLOW IN    Anywhere (v6)
110 (v6)                   ALLOW IN    Anywhere (v6)
993/tcp (Dovecot Secure IMAP (v6)) ALLOW IN    Anywhere (v6)
995/tcp (Dovecot Secure POP3 (v6)) ALLOW IN    Anywhere (v6)
25/tcp (Postfix (v6))      ALLOW IN    Anywhere (v6)
465/tcp (Postfix SMTPS (v6)) ALLOW IN    Anywhere (v6)

Ponowne włączenie portu w następujący sposób rozwiązuje problem:

user@host:~$ sudo ufw allow ssh
Rule added
Rule added (v6)

W moim systemie problem polegał na tym, że skrypt inicjujący ssh /etc/init.d/sshbył jedynym sprawdzającym obecność nowszej wersji init.

Więc /etc/init.d/sshsię nie zaczyna, ssh,bo uważa, że ​​to się zacznieupstart .

W moim przypadku upstart nie uruchamia się z powodu mojej konkretnej konfiguracji:

Konfiguracja była prawidłowa /etc/init/ssh.conf, ale był też /etc/init/ssh.overrideplik zawierający manual, co oznaczassh że należy uruchomić ręcznie.

Ten plik został utworzony przez get-remnux.sh skrypt instalacyjny.

Uruchomienie ręczne lub usunięcie /etc/init/ssh.overridepliku rozwiązuje problem.