소켓이 활성화 된 시스템 사용자 장치를 통한 주문형 SSH Socks 프록시가 원하는대로 다시 시작되지 않음

격리 된 네트워크에 도달하려면 ssh -D socks 프록시를 사용합니다 .

내가 추가 할 때마다 세부 정보를 입력하지 않아도되도록 다음을 추가하십시오 ~/.ssh/config.

$ awk '/Host socks-proxy/' RS= ~/.ssh/config
Host socks-proxy
  Hostname pcit
  BatchMode yes
  RequestTTY no
  Compression yes
  DynamicForward localhost:9118

그런 다음 systemd-user service unit definition 파일을 작성했습니다.

$ cat ~/.config/systemd/user/SocksProxy.service 
[Unit]
Description=SocksProxy Over Bridge Host

[Service]
ExecStart=/usr/bin/ssh -Nk socks-proxy

[Install]
WantedBy=default.target

데몬이 새로운 서비스 정의를 다시로드하고, 새로운 서비스를 활성화하고, 시작하고, 상태를 확인하고, 듣고 있는지 확인했습니다.

$ systemctl --user daemon-reload
$ systemctl --user list-unit-files | grep SocksP
SocksProxy.service   disabled

$ systemctl --user enable SocksProxy.service
Created symlink from ~/.config/systemd/user/default.target.wants/SocksProxy.service to ~/.config/systemd/user/SocksProxy.service.

$ systemctl --user start SocksProxy.service 
$ systemctl --user status SocksProxy.service 
● SocksProxy.service - SocksProxy Over Bridge Host
   Loaded: loaded (/home/alex/.config/systemd/user/SocksProxy.service; enabled)
   Active: active (running) since Thu 2017-08-03 10:45:29 CEST; 2s ago
 Main PID: 26490 (ssh)
   CGroup: /user.slice/user-1000.slice/user@1000.service/SocksProxy.service
           └─26490 /usr/bin/ssh -Nk socks-proxy

$ netstat -tnlp | grep 118
tcp     0    0 127.0.0.1:9118        0.0.0.0:*             LISTEN     
tcp6    0    0 ::1:9118              :::*                  LISTEN

의도 한대로 작동합니다. 그럼 수동으로 서비스를 시작하는 데, 또는 영구적으로 그것을 실행하지 않도록하고 싶었다 autossh 사용하여, systemd 소켓 활성화를 주문형 산란 (재) 대한. 그것은 효과가 없었습니다. (내 버전) ssh소켓 파일 디스크립터를 수신 할 수 없다고 생각 합니다.

나는 문서 (발견 1 , 2 ), 및 예를 들어 사용 systemd-socket-proxyd이 "래퍼"서비스 "서비스"와 "소켓"을 만들 -tool를 :

$ cat ~/.config/systemd/user/SocksProxyHelper.socket 
[Unit]
Description=On Demand Socks proxy into Work

[Socket]
ListenStream=8118
#BindToDevice=lo
#Accept=yes

[Install]
WantedBy=sockets.target

$ cat ~/.config/systemd/user/SocksProxyHelper.service 
[Unit]
Description=On demand Work Socks tunnel
After=network.target SocksProxyHelper.socket
Requires=SocksProxyHelper.socket SocksProxy.service
After=SocksProxy.service

[Service]
#Type=simple
#Accept=false
ExecStart=/lib/systemd/systemd-socket-proxyd 127.0.0.1:9118
TimeoutStopSec=5

[Install]
WantedBy=multi-user.target

$ systemctl --user daemon-reload

이것은 죽거나 죽을 때까지 작동하는 것 같습니다ssh . 그런 다음 다음 연결 시도시 다시 생성되지 않습니다.

질문 :

1. / usr / bin / ssh가 실제로 시스템 전달 소켓을 허용하지 않습니까? 아니면 최신 버전입니까? 광산은 up2date 데비안 8.9에서 나온 것 입니다.
2. 루트 단위 만 BindTodevice옵션을 사용할 수 있습니까?
3. 이전 터널이 종료 된 후 첫 번째 새 연결에서 프록시 서비스가 올바르게 생성되지 않는 이유는 무엇입니까?
4. 이것이 "주문형 ssh 양말 프록시"를 설정하는 올바른 방법입니까? 그렇지 않다면 어떻게합니까?

• / usr / bin / ssh가 실제로 시스템 전달 소켓을 허용하지 않습니까?

나는 다음을 고려할 때 너무 놀라운 것이 아니라고 생각합니다.

• OpenSSH는 OpenBSD 프로젝트입니다
• systemd는 Linux 커널 만 지원합니다
• 선택적 / 빌드 타임 종속성으로 시스템 지원을 OpenSSH에 명시 적으로 추가해야하므로 판매가 어려울 수 있습니다.

• 루트 단위 만 BindTodevice옵션을 사용할 수 있습니까?

사용자 시스템 인스턴스는 일반적으로 격리되어 있으며 예를 들어 기본 pid-0 인스턴스와 통신 할 수 없습니다. 사용자 단위 파일의 시스템 단위에 의존하는 것과 같은 것은 불가능합니다.

BindToDevice언급에 대한 문서 :

이 매개 변수를 설정하면 추가 종속성이 장치에 추가 될 수 있습니다 (위 참조).

위에서 언급 한 제한으로 인해 사용자 시스템 인스턴스에서 옵션이 작동하지 않을 수 있습니다.

• 이전 터널이 종료 된 후 첫 번째 새 연결에서 프록시 서비스가 올바르게 생성되지 않는 이유는 무엇입니까?

내가 이해하는 것처럼 이벤트 체인은 다음과 같습니다.

• SocksProxyHelper.socket 시작됩니다.
• SOCKS 클라이언트는 localhost : 8118에 연결합니다.
• systemd가 시작됩니다 SocksProxyHelper.service.
• 의 의존성으로 SocksProxyHelper.servicesystemd도 시작됩니다 SocksProxy.service.
• systemd-socket-proxyd시스템 소켓을 받아들이고 해당 데이터를로 전달합니다 ssh.
• ssh 죽거나 죽습니다.
• 시스템 통지 및 SocksProxy.service비활성 상태로 설정하지만 아무 것도 수행하지 않습니다.
• SocksProxyHelper.service계속 실행 중이며 연결을 수락하지만 ssh더 이상 실행되지 않으므로 에 연결하지 못했습니다 .

수정은에 추가 BindsTo=SocksProxy.service하는 것 SocksProxyHelper.service입니다. 문서 인용 (강조 추가) :

요구 사항 종속성을 스타일과 매우 유사하게 구성합니다 Requires=. 그러나이 종속성 유형이 더 강력합니다. Requires=이로 인해 바인딩 된 장치가 중지되면이 장치도 중지됩니다 . 즉, 갑자기 비활성 상태가 된 다른 장치에 바인딩 된 장치도 중지됩니다. 서비스 장치 의 기본 프로세스가 자체적으로 종료 되거나 장치 장치의 백업 장치가 분리되거나 마운트 장치의 마운트 지점이 마운트 해제 될 수 있습니다. 시스템 및 서비스 관리자

After=동일한 장치 에서 함께 사용 하면 동작 BindsTo=이 훨씬 더 강해집니다. 이 경우이 장치 가 활성 상태가 되려면 바인딩 된 장치가 엄격하게 활성 상태 여야 합니다. (등이 갑자기 비활성 상태를 입력하는 다른 수단에 결합 된 장치를 의미하지만, 인해 실패 조건 확인을 생략 얻는 다른 수단에 결합 된 하나뿐만 아니라 ConditionPathExists=, ConditionPathIsSymbolicLink=그것을해야 중지한다 - 아래 참조 ...) 실행 중입니다. 따라서 많은 경우 BindsTo=와 결합하는 것이 가장 좋습니다 After=.

• 이것이 "주문형 ssh 양말 프록시"를 설정하는 올바른 방법입니까? 그렇지 않다면 어떻게합니까?

아마도 "올바른 방법"이 없을 것입니다. 이 방법에는 장점 (모든 주문형)과 단점 (시스템에 따라 달라짐, ssh가 아직 청취를 시작하지 않았기 때문에 첫 번째 연결이 이루어지지 않음)이 있습니다. 아마도 autossh에서 시스템 소켓 활성화 지원을 구현하는 것이 더 나은 솔루션 일 것입니다.