☰

상태 설명

tag-icon • tag-icon ssh systemd sshd systemd-unit
상태 설명

상태 설명

Ubuntu 18.04.3 LTS에서 systemd 및 ssh를 사용할 때 이상한 상황이 발생했습니다.

장치 의 상태를 확인했습니다 ssh.socket.

$ systemctl status ssh.socket
● ssh.socket - OpenBSD Secure Shell server socket
   Loaded: loaded (/lib/systemd/system/ssh.socket; disabled; vendor preset: enabled)
   Active: inactive (dead)
   Listen: [::]:22 (Stream)
 Accepted: 0; Connected: 0

그리고 그것은 비활성 상태였지만 동시에 ssh로 로그인했고 서비스 자체가 실행 중이었고 SSH의 소켓과 해당 포트가 열려 있었습니다.

$ lsof -P -i -n | grep sshd
sshd      26785            root    3u  IPv4 14858764      0t0  TCP 10.200.130.28:22->10.100.40.141:42188 (ESTABLISHED)
sshd      26875          xxx_root    3u  IPv4 14858764      0t0  TCP 10.200.130.28:22->10.100.40.141:42188 (ESTABLISHED)
sshd      63859            root    3u  IPv4   238437      0t0  TCP *:22 (LISTEN)
sshd      63859            root    4u  IPv6   238439      0t0  TCP *:22 (LISTEN)

그래서 다음에서 ssh.socket의 단위 파일을 살펴보았습니다 /lib/systemd/system/ssh.socket.

[Unit]
Description=OpenBSD Secure Shell server socket
Before=ssh.service
Conflicts=ssh.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

[Socket]
ListenStream=22
Accept=yes

[Install]
WantedBy=sockets.target

지시어 때문에 Before=ssh.serviceSSH 서비스가 시작되기 전에 시작되어야 하며 Conflicts=ssh.service지시어는 SSH 서비스가 시작될 때 중지되도록 합니다.

이는 단위 파일 측면에서 발생하는 이유를 설명하지만 다른 질문이 제기됩니다.

질문

ssh.socket 장치의 비활성 상태가 실제 SSH 소켓에 영향을 주지 않는 이유는 무엇입니까?

관리자가 Conflict지시문을 추가한 이유는 무엇입니까? 예를 들어, 해당 유닛 파일 docker.socket이 docker.service. sshd의 경우는 어떻게 다릅니까?

추가 정보

나는 또한 오래된 Fedora 30 워크스테이션에서 이것을 확인했습니다. 조건은 동일하지만 약간의 차이가 있습니다. sshd.service및 를 유닛 이름으로 사용 하고 유닛 파일 에 지시어 sshd.socket가 없습니다 .Beforesshd.socket

두 시스템 모두에서 이 조건으로 인해 발생하는 문제를 발견하지 못했고 어떤 목적이 있는 것으로 의심되지만 찾을 수 없습니다.

답변1

systemd 소켓은 systemd가 포트(또는 Unix 도메인 소켓 파일 경로와 같은 다른 리소스)에 바인딩하고 모든 연결에 대해 서비스의 새 인스턴스를 생성하도록 하는 특별한 유형의 장치입니다. ssh.service가 활성화되면 lsof에 표시된 것처럼 지속적으로 실행되고 소켓에 바인딩되는 sshd입니다. 대신 ssh.socket을 켜면 sshd가 지속적으로 실행되지 않고 오히려 해당 인스턴스가 하나의 클라이언트를 처리하기 위해서만 호출된다는 의미입니다. 대조적으로 이는 포트 22에서 systemd 수신 대기를 표시합니다. systemd와 sshd가 모두 동일한 포트에서 수신 대기할 수 없기 때문에 ssh.socket은 ssh.service를 충돌로 지정합니다.

답변2

이해해야 할 중요한 점은 당신이 보고 있는 것이 "소켓" 단위의 특정 용도라는 것입니다.삼:http://0pointer.de/blog/projects/inetd.html

따라서 의 특정 경우에는 ssh.socket이전 스타일과 동일합니다.inetd와 유사한 호출(코어 소켓 장치 설정: Accept=yes), 포트 22(systemd에 의해 관리됨)에서 들어오는 모든 요청은 별도의 시작을 유발합니다.[email protected] 사례.

systemd.socket 매뉴얼 페이지도 참조하십시오.https://www.freedesktop.org/software/systemd/man/systemd.socket.html

Accept=yes로 설정된 경우 서비스 템플릿[이메일 보호됨]각 수신 연결에 대해 서비스가 인스턴스화되는 소스가 있어야 합니다.

따라서 sshd를 시작하는 방법에는 총 두 가지가 있습니다.

  • ssh.service( sshd.service별칭일 뿐임)은 기본 sshd 프로세스를 시작하고 거기서부터 프로세스는 들어오는 모든 연결을 처리하고 하위 프로세스를 생성하는 등의 작업을 수행합니다.
  • ssh.socket+ [email protected], 여기서 systemd는 소켓 관리 포트에서 들어오는 모든 연결을 새 인스턴스에 연결합니다.[이메일 보호됨], inetd 스타일. 이것이 템플릿 서비스에 , StandardInput=socket및 옵션이 ExecStart=/usr/sbin/sshd있는 이유입니다 -i.

분명히 한 번에 하나의 접근 방식만 사용할 수 있으므로 Conflicts=두 접근 방식이 동시에 실행되지 않도록 해야 합니다. (그런데 스탠자의 실제 배치 Conflicts=는 중요하지 않습니다. 동등한 스탠자가 ssh.service에 작성될 수도 있지만 하나만 있으면 충분합니다.)

관련 정보