14.04 서버를 재부팅 한 후 SSH 문제의 원인은 무엇입니까?

Ubuntu 14.04를 실행하는 서버를 재부팅하면 왜 '연결 거부'오류가 발생합니까?

내가 볼 ssh: connect to host <IP-address-here> port 22: Connection refused만 14.04을 위해 만 재부팅 한 후하지만. 집에서 12.04 Desktop을 사용하고 있습니다. 이 문제를 어떻게 해결합니까?

질문을 명확하게하기 위해 다음과 같은 것이 나에게 효과적이지 않습니다.

• 12.04의 새 설치에 SSH> 로그 아웃> SSH 다시 다시> 작동
• 12.04를 새로 설치 한 SSH로 재부팅> 재부팅> SSH를 다시 ​​입력> 작동
• 14.04의 새 설치에 SSH> 로그 아웃> SSH 다시 다시> 작동
• 14.04의 새로 설치로 SSH 연결> 재부팅> SSH 다시 입력> 연결 거부

내가 겪고있는 문제는 14.04에 고유하며 재부팅 후에 만 ​​발생합니다. 이 전에 12.04를 실행하는 여러 서버가 있으며 모든 것이 여전히 완벽하게 작동합니다. 14.04를 사용하려는 새 서버가 있는데 무엇이 잘못되었는지 이해하고 싶습니다. 어떤 제안?

지금까지 시도한 내용은 다음과 같습니다.

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

Traceroute가 제대로 작동합니다. SSH 포트 22의 서버에서 응답을 얻습니다.

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

14.04 서버의 ssh가 부팅시 시작되도록 설정되어 있습니다 (예상대로).

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

편집 : 다음은 새로 생성 된 시스템 의 전체 syslog입니다 . SSH를 작성하고 reboot now명령을 발행 한 다음 재부팅을 기다렸다가 두 번째로 SSH를 시도한 후 연결 거부 오류가 발생했습니다. 호스팅 제어판을 통한 하드 재부팅 및 이제 SSH 연결이 다시 작동합니다.

빠른 답변 :

SSH는 문제가 아닙니다. 당신이 다시 부팅하는 데 사용하는 명령은 문제 :하지 않는다 reboot now수행 reboot하거나 shutdown -r now시스템을 재부팅 할 수 있습니다.

명령 구문 ( 13.04 이후 )은 다음과 같습니다.

reboot [OPTION]...  [REBOOTCOMMAND]

REBOOTCOMMAND전에 존재하지 않았다. 12.04에서, 당신 now은 방금 무시되었지만 이제는 사용되고 있습니다 ... 그리고 그것은 모든 것을 깨고 있습니다.

내 테스트 결과 및 설명과 함께 긴 대답 :

14.04를 실행하고 VPS (프랑스어 OVH 공급자에서 호스팅-OpenVZ 실행) 및 reboot now서버 자체 내부에서 일부 서버와 비슷한 문제가 있습니다.

당신처럼 reboot now콘솔 에서 명령 을 내 렸습니다 (SSH를 사용하여 로그인 함). 를 누른 후 몇 초 후에 RETURN세션이 자동으로 끊어집니다. 당신처럼 나는이 명령을 발행 한 후 SSH를 통해 서버에 다시 연결할 수 없었습니다.

그래서 OVH에서 제공하는 KVM 콘솔을 열기로 결정했습니다. (이러한 종류의 가상 서버에 대해 실제 서버에서 키보드와 화면을 사용하여 직접 액세스를 모방).

내 컴퓨터에 연결할 수 있었고, 그녀가 단일 사용자 모드로 들어가서 CTRL+ D를 눌러 계속하거나 루트 암호를 입력하여 유지 관리 모드 로 들어가기를 기다리는 것을 보았습니다 . 키 조합을 눌러 프로세스를 계속 진행 한 다음 시스템에 다시 SSH를 연결할 수있었습니다. uptime가동 후 가동 시간이 2 ~ 3 분이 아니라 아직 많은 일 reboot now이라는 것을 알기 위해 놀랍게도 Ubuntu 14.04 VPS 내에서 실행 된 것은 실제로 재부팅되지 않지만 단일 사용자 모드로 들어가기를 요청하는 것입니다!

이로부터 VPS 내에서 재부팅을 요구하지 않고 호스트의 관리 인터페이스에 제공된 명령으로 요청하는 법을 배웠습니다.

따라서 SSH 설치에 문제가 없습니다. 문제는 입력 할 때 reboot now입니다. 사실, 나는 나중에 그것을 테스트했는데, 당신이 입력 한 경우 reboot(단어, 옵션 없음), 당신이하려는 의도를 수행했을 것입니다 : 서버 재부팅.

reboot매뉴얼 페이지에서 인수와 함께 사용 shutdown하면 주어진 인수와 함께 명령 을 호출합니다 . 실제로을 실행 shutdown now하면 동일한 동작이 발생합니다. 시스템이 재부팅되지 않고 단일 사용자 모드로 전환됩니다.

비고 : 이 명령을 실행 한 후 화면에 나타나는 메시지가 다음과 같이 의도 된 동작 인 것 같습니다.

시스템이 유지 보수 모드로 전환됩니다

유지 관리 모드 또는 단일 사용자 모드는 쉘 이상, 네트워크 없음, 네트워크 프로세스 없음 등을 나타내는 런레벨을 나타냅니다.

혼란 스러울 수 있지만 올바른 사용법은 shutdown예를 들어 shutdown -h now시스템을 정지 시키거나 shutdown -r now재부팅하는 것입니다. shutdown now시스템을 단일 사용자 모드로만 가져올 것임을 알지 못했습니다 . 나는 보통 init S이것을 달성하기 위해한다.

늦었을 수도 있고 명백 할 수도 있지만, 나를 위해 일한 것은 구성 파일을 확인하는 것이 었습니다 /etc/ssh/sshd_config. 데몬을 실행 /etc/init.d/ssh start하거나 다른 조합을 사용하면 서비스가 실행되지 않았어도 서비스가 실행되고 있음을 알 수 있었지만 절대 경로 (내 경우 /usr/sbin/sshd) 구성 파일 끝에 "0B"가 추가되어 시작시 오류가 발생하여 제거하면 문제가 해결되는 것을 알았습니다.

또 다른 잠재적 원인은 ufwSSH 포트 규칙 구성 이 유실 된 것입니다. 업데이트를 적용하고 재부팅 한 후 방화벽 구성으로 인해 서버에 대한 액세스 권한이 차단되는 상황이 적어도 한두 번은 발생했습니다. 호스팅 제공 업체의 VPS 콘솔 기능을 사용하여 시스템에 접속하여 문제를 진단 할 수있었습니다. 문제를 보여주는 아래 예 (예 : 포트 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)

다음과 같이 포트를 다시 활성화하면 트릭이 수행됩니다.

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

내 시스템의 문제는 ssh init 스크립트 /etc/init.d/ssh가 init 의 시작 버전이 있는지 확인하는 유일한 스크립트 라는 것입니다.

로 /etc/init.d/ssh시작 ssh,한다고 생각하기 때문에 시작하지 않습니다 upstart.

필자의 경우 특정 구성으로 인해 upstart가 시작되지 않습니다.

에 올바른 구성이 /etc/init/ssh.conf있었지만을 /etc/init/ssh.override포함 하는 파일 도있었습니다. manual즉, ssh수동으로 시작해야합니다.

이 파일은 get-remnux.sh설치 스크립트에 의해 작성되었습니다 .

수동으로 시작하거나 /etc/init/ssh.override파일을 제거하면 문제가 해결됩니다.