서버에서 이유없이 ssh / su 이 느릴 때

※ 해당 문제는 CentOS 7 에서 발생한 문제이고, 다른 버전에서도 동일한 문제가 발생 될 수 있으며 아래 명령어는 CentOS 7 기준으로 작성했습니다.

 

· 현상

개발자로부터 Ansible을 통해 여러 서버에 작업을 하는데, 하나의 서버에서만 ssh 연결이 timeout이 발생하며 작동되지 않는다고 제보 받음

 

· 문제 확인

Ansible 서버에서 직접 ssh 로 접근 했을 때 오랜 시간의 지연이 발생했고 접근 후 su 명령어 또한 지연이 발생했다.

일단 Ansible 문제는 아니라고 판단을 했고 서버 리소스를 확인 했을 때 자원은 충분했다.

 

서비스 중인 서버이므로 부하가 가지 않을 정도로 CPU, 메모리, 디스크 등 성능 테스트를 했을 때 문제가 없었으며 물리적인 소모품 또한 정상이였다. 

 

그렇다면 왜 느릴까? 생각하던 도중 ssh / su 는 모두 로그인과 관련된 내용이다.

아마 PAM 설정에 문제가 있을까 확인을 해봤지만, 다른 서버와 특별한 점을 찾지 못했고.. /var/log/message 를 확인했지만 이상 로그는 없었다. (실제로 존재했지만 너무 많은 메시지로 제대로 보질 못했다.)

 

커널 수준에서 어떤 부분이 문제가 있는지 확인하기 위해 strace ssh <대상 서버 IP> 를 입력했고, 특정 메시지에서 오랫동안 머무는 것을 확인 할 수 있었다.

debug1: pledge: network

위와 같은 내용을 확인했을 때 어떤 문제인지 정확히 판단하기 힘들었고, 해당 메시지를 구글링 했을 때 아래와 같은 내용을 확인했었다.

Connection to one of my servers using ssh takes more than 20 seconds to initiate.
This is not related to LAN or WAN conditions, since connection to itself takes the same (ssh localhost). After connection is finally establised, it is super fast to interract with the server.
Using -vvv shows that the connection is stuck after saying "pledge: network". At this point, authentication (here using key) is already done, as visible here :
...
debug1: Authentication succeeded (publickey).
Authenticated to myserver.mydomain.com ([xx.xx.xx.xx]:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
(...stuck here for 15 to 25 seconds...)
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
...
Server is Ubuntu 16.04. It already happened to me in the past with another server (was Ubuntu 12.04) , nerver found the solution and the problem disapeared after a while...
sshd_config is the default one provided by Ubuntu.
So far I have tried :
	• using -o GSSAPIAuthentication=no in the ssh command
	• using password instead of a key
	• using UsePrivilegeSeparation no instead of yes, in sshd_config
----------------------------------------------------------------------------------------------
This is probably an issue with D-Bus and systemd. If the dbus service is restarted for some reason, you will also need to restart systemd-logind.

You can check if this is the issue by opening the ssh daemon log (on Ubuntu it should be /var/log/auth.log) and check if it has these lines:
sshd[2721]: pam_systemd(sshd:session): Failed to create session: Connection timed out

If yes, just restart systemd-logind service:
systemctl restart systemd-logind

I had this same issue on CentOS 7, because the messagebus was restarted (which is how the D-Bus service is called on CentOS).

동일한 문제를 가진 내용이였고, 답변은 D-Bus 와 systemd에 이슈가 있으며 어떤 이유로 dbus 서비스가 재시작이 될 경우 systemd-logind 서비스를 재시작을 해줘야 된다는 내용이다.

 

일단 저널 명령어로 통해 확인했을 때 아래와 같은 메시지를 확인 할 수 있었다.

[root@seob log]#journalctl  -u dbus
Sep 10 15:28:07 seob systemd[1]: dbus.service failed.
Sep 10 15:28:14 seob systemd[1]: Started D-Bus System Message Bus.
Sep 10 15:28:14 seob dbus[22475]: [system] Activating systemd to hand-off: service name='org.freedesktop.login1' unit='dbus-org.freedesktop.login1.service'
Sep 10 15:28:14 seob dbus[22475]: [system] Successfully activated service 'org.freedesktop.systemd1'
Sep 10 15:28:39 seob dbus[22475]: [system] Failed to activate service 'org.freedesktop.login1': timed out
Sep 10 15:28:39 seob dbus[22475]: [system] Activating via systemd: service name='org.freedesktop.login1' unit='dbus-org.freedesktop.login1.service'

[root@seob log]#journalctl -u systemd-logind   
Sep 10 16:01:48 seob systemd-logind[12775]: Failed to abandon session scope: Transport endpoint is not connected

09월 10일 15:28분에 dbus 서비스가 재시작이 되었고 이에 따라 timed out이 발생한 것이다.

 

· 문제 해결

문제 해결은 간단했다. 구글링 했던 답변처럼 systemd-logind만 재시작해주면 되는 모든게 해결이 되었다.

systemctl restart systemd-logind 

이후 ssh, su 접근 시 평소와 동일한 속도로 지연없이 접근되는 것을 확인했다.

또한 systemd-logind 은 로그인과 관련된 데몬으로 서비스 중인 서버에서 login 관련 서비스를 실시간으로 사용하지 않는다면 언제든지 구동해도 문제는 없다.

 

· 마무리

무엇보다 동일한 문제 재발방지를 위해 확인을 했지만 개발자에게 확인했을 때 dd 명령어로 성능 테스트를 했었다고 답변을 받았다. 동일한 명령어로 실행했지만 dbus 서비스가 failed 되는 현상은 발생하지 않았고 서비스에 치명적인 문제는 아니라 일단 넘겼다.

 

혹시 이와 비슷한 내용으로 어떤 원인으로 dbus 서비스가 failed 되었는지 아시는 분이 있다면.. 답변을 해주시길 바란다.