☰

gpg-agent가 이상하게 작동을 멈췄습니다. 원격 시스템의 에이전트가 더 이상 SSH 소켓에 연결되지 않습니다.

tag-icon • tag-icon linux ssh osx gpg-agent yubikey
gpg-agent가 이상하게 작동을 멈췄습니다. 원격 시스템의 에이전트가 더 이상 SSH 소켓에 연결되지 않습니다.

원격 시스템의 암호화/암호 해독/서명 및 SSH 에이전트 전달을 위해 로컬 시스템에서 yubikey nano를 사용하고 있습니다. 설정하기가 정말 힘들었던 기억이 나지만 몇 달 동안은 문제 없이 작동했습니다. 갑자기 고장이 났습니다. 내 검색은 모두 설정할 때 읽은 것과 동일한 링크를 반환하지만 멈춰 있습니다.

SSH 에이전트 전달은 어떻게든 작동합니다. 원격 시스템에 다음이 표시됩니다.

REMOTE:$ ssh-add -L
ssh-rsa blahblah cardno:123

SSH를 사용하여 원격 시스템에서 다른 서버에 로그인할 수 있으며 인증을 위해 nano를 사용합니다(프록시 서명을 활성화하려면 터치가 필요하기 때문에 이것을 알고 있습니다). 내 로컬 시스템의 gpg-agent 로그에서 SSH 서명에 대한 로그를 볼 수 있습니다.

그러나 GPG 서명/암호화가 작동하지 않습니다. 원격 시스템에서 다음 명령을 실행하면:

REMOTE:$ echo "$(uname -a)" |  gpg2 --armor --clearsign --default-key 0x1234
gpg: all values passed to '--default-key' ignored
gpg: no default secret key: No secret key
gpg: [stdin]: clearsign failed: No secret key

로컬 gpg-agent 로그에는 이 시도에 대한 로그가 없습니다. 이 명령을 실행하면 로컬 gpg-agent 로그에서 로그 항목을 볼 수 있습니다.

REMOTE:$ $ netcat  -U /home/user/.gnupg/S.gpg-agent
OK Pleased to meet you
RESET
OK
GETINFO PID
ERR 67109115 Forbidden <GPG Agent>
POOP
ERR 67109139 Unknown IPC command <GPG Agent>

그러면 로컬 에이전트에 다음 로그가 생성됩니다.

2018-01-05 16:38:32 gpg-agent[865] DBG: chan_10 -> OK Pleased to meet you
2018-01-05 16:38:35 gpg-agent[865] DBG: chan_10 <- RESET
2018-01-05 16:38:35 gpg-agent[865] DBG: chan_10 -> OK
2018-01-05 16:38:45 gpg-agent[865] DBG: chan_10 <- GETINFO PID
2018-01-05 16:38:45 gpg-agent[865] DBG: chan_10 -> ERR 67109115 Forbidden <GPG Agent>
2018-01-05 16:39:01 gpg-agent[865] DBG: chan_10 <- POOP
2018-01-05 16:39:01 gpg-agent[865] DBG: chan_10 -> ERR 67109139 Unknown IPC command <GPG Agent>

원격 시스템의 gpg-connect-agent에서 strace -f -F를 실행하면 로컬 시스템에서 전달되는 ~/.gnupg/의 소켓이 아닌 /var/run의 소켓에 연결되는 것 같습니다. 두 소켓을 모두 삭제하고 모든 gpg-agent 프로세스를 종료하고 SSH 원격 전달을 /var/run 위치 또는 ~/.gnupg 위치로 변경하려고 시도했지만 소용이 없었습니다. 제가 단계를 망쳤을 수도 있고 다시 해보겠지만, 혹시 아시는 분 계시면 다음번에 이런 일이 생기면 쉽게 찾으실 수 있었으면 좋겠습니다.

로컬 시스템:

Mac OS X 10.11.6
gpg installed with brew
gpg (GnuPG) 2.2.1
libgcrypt 1.8.1

원격 시스템:

ubuntu 17.10
gpg (GnuPG) 2.1.15
libgcrypt 1.7.8

편집: 좋아, 무엇이 바뀌었는지 잘 모르겠지만 잠시 동안 그대로 두었다가 다시 소켓 전환을 시도했는데 이제 작동합니다.

REMOTE:$ $ echo "$(uname -a)" |  strace -f -F gpg2 --armor --clearsign --default-key 0x1234
...
a bunch of garbage
...
stat("/run/user/1000/gnupg/S.gpg-agent", {st_mode=S_IFSOCK|0600, st_size=0, ...}) = 0
socket(AF_UNIX, SOCK_STREAM, 0)         = 5

SSH 원격 전달을 이 새 위치로 변경했습니다. 나는 운없이 gpgconf --list-dir Agent-ssh-socket에서 제공하는 소켓 경로를 사용하기 전에 이것을 시도했다고 맹세합니다. 아마도 기존 요원을 죽이는 것을 잊었을 것입니다. 공교롭게도 저는 이것이 변경되었음을 보고하는 블로그 게시물을 발견했습니다. https://blog.kylemanna.com/linux/gpg-213-ssh-agent-socket-moved/

답변1

업데이트: 소켓 연결을 해제하세요. 하단의 편집 내용을 참조하세요.

분명히 여기에는 간헐적인 버그가 있거나 이러한 모든 시스템이 상호 작용하는 방식에 따른 부작용이 있습니다. 나는 너무 많은 세부사항/추측에 들어가고 싶지 않지만 다음을 고려할 것입니다.

  • 두 번째 SSH 세션은 첫 번째 세션의 파이프에 연결됩니다(이런 일이 발생해야 합니까?)
  • REMOTE의 SSHD에 있는 StreamLocalBindUnlink가 파이프를 올바르게 가져오지 못합니다(원격 측의 프록시가 여전히 열려 있기 때문일까요?).

좋은 해결 방법은 gpg 에이전트 전달을 위해 .ssh/config에서 별도의 특수 호스트를 사용하고 해당 호스트 이름에 한 번만 로그인하는 것입니다!

파이프라인/실행 중인 에이전트와 인스턴스의 조합으로 인해 몇 번이나 발생했지만 매우 실망스러웠습니다.새 sshd 세션은 어디에 있나요아니요새 소켓 만들기모든 종류의 혼란을 야기합니다(아마도 실행 중인 에이전트가 오래된 소켓 파일을 열어두기 때문일 것입니다). 일반적으로 이런 문제를 해결하려고 노력할 시간이 없습니다.

마침내 이 문제가 발생하여 문제를 해결하고 수정할 수 있었습니다. 문제를 안정적으로 재현하고 해결 방법을 보여줄 수 있습니다.

업무 시스템

REMOTE:$ echo "$(uname -a)" | gpg --armor --clearsign --default-key 0x1234
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Linux pooter 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE/0lJ/t51agRvvTILdQ2kyDf6wDYFAl9JgSYACgkQdQ2kyDf6

-----END PGP SIGNATURE-----

로컬 시스템에서 다른 SSH 또는 Rsync를 실행하세요.

LOCAL: $ rsync -avze ssh test.txt pooter:
bind [127.0.0.1]:5901: Address already in use

SCP는 문제를 일으키지 않지만 파일이 복사될 때 포트 전달이 실패하는 것을 확인하기 때문에 RSYNC는 분명히 ssh 로그인을 수행합니다.

이제 원격 암호화/암호 해독이 실패합니다.

REMOTE:$ echo "$(uname -a)" | gpg --armor --clearsign --default-key 0x1234
gpg: all values passed to '--default-key' ignored
gpg: no default secret key: No secret key
gpg: [stdin]: clear-sign failed: No secret key

고치다

  1. 소켓 전달을 사용하여 모든 SSH 세션에서 로그아웃
  2. 원격 시스템의 모든 GPG 에이전트를 종료합니다.
  3. /var/run/xxxx/gnupg의 파이프가 제자리에 있는지 확인하십시오.
  4. 파이프가 사라지면 소켓 전달을 사용하여 로그인하고 다시 생성되었는지 확인하세요.

3단계와 4단계에서는 양방향으로 진행되는 것을 볼 수 있습니다. 파이프가 남아 있을 때도 있고 적절하게 사라지는 경우도 있습니다. 파이프라인 파일을 삭제하고 다시 로그인하여 다시 생성되었는지 확인해야 할 수도 있습니다.

이제 모든 것이 다시 암호화/복호화될 수 있습니다.

업데이트 - 더 간단한 수정

오늘 이유도 없이 이런 일이 일어나서 짜증이 난다. 이 게시물을 찾으러 와야 했지만 원래 게시물에서 알려준 모든 작업을 수행하기에는 너무 게으릅니다. 나는 위의 추측의 관점에서 이 상황을 고려합니다. 간단히 말해서, 이것은 작동합니다:

  1. Killall gpg-agent && 종료
  2. CTRL^C # 전달 포트 연결 끊기
  3. 1분 정도 기다리세요
  4. 재등록

모든 것이 다시 정상으로 돌아왔습니다

편집: 이런 일이 다시 발생하여 한 단계를 더 추가했습니다. Unix 도메인 소켓 파일을 찾아 다른 쉘/로그인에서 다음 명령을 실행하십시오: unlink /path/to/socket

관련 정보