gpg-agent mysteriously stopped working - agent on remote system no longer connecting to ssh socket [closed]

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
1
down vote

favorite












I am using a yubikey nano on my local system to do encrypt/decrypt/sign on remote systems, plus SSH agent forwarding. I recall this being a bear to setup, but it has worked flawlessly for several months now. Suddenly it broke. My searches all return the same links I read when I set it up, but I am stuck.



SSH agent forwarding inexplicably works. Remote system shows this:



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


I can login to other servers using SSH from the remote system and it uses the nano for auth (I know this because it requires touch to enable agent signing). I can see logs about the SSH signing in the gpg-agent log on the local system.



However, I can't get GPG sign/encrypt to work at all. If I run the following on the remote system:



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


In the local gpg-agent log I see no logs about the attempt. If I run this command, I can see log entries in the local gpg-agent log:



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>


Which results in these logs in the local 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>


If I run strace -f -F on gpg-connect-agent on the remote system, it seems to be connecting to a socket in /var/run, but not the one forwarded from the local system in ~/.gnupg/. I have tried removing both sockets, killing all gpg-agent processes and changed the SSH remote forward to go to either the /var/run location or the ~/.gnupg location to no avail. It is possible I screwed these steps up and I will try them again, but I want to know if someone knows the answer, and I would like to have an easy to find post for the next time this breaks.



LOCAL SYSTEM:



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


REMOTE SYSTEM:



ubuntu 17.10
gpg (GnuPG) 2.1.15
libgcrypt 1.7.8


EDIT:
Ok, no idea what changed, but I left it alone for a bit and came back and tried to switch the socket again and it now works:



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) = 0
socket(AF_UNIX, SOCK_STREAM, 0) = 5


Changing my SSH remote forward to this new location worked. I swear I tried this earlier using the socket path provided by gpgconf --list-dir agent-ssh-socket, without any luck. Probably forgot to kill the existing agent. And by happenstance, I just chanced upon a blogpost reporting that this changed:
https://blog.kylemanna.com/linux/gpg-213-ssh-agent-socket-moved/







share|improve this question














closed as off-topic by B Layer, G-Man, Jeff Schaller, George Vasiliou, jimmij Jan 6 at 14:50


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – B Layer, G-Man, Jeff Schaller, George Vasiliou, jimmij
If this question can be reworded to fit the rules in the help center, please edit the question.












  • I found the solution. I don't seem to have enough fake internet points to do anything further. Should I just delete the question? It has enough debugging pointers that it might be of use to someone in the future.
    – lopass
    Jan 6 at 4:06










  • I put it up for a close vote.
    – B Layer
    Jan 6 at 4:17














up vote
1
down vote

favorite












I am using a yubikey nano on my local system to do encrypt/decrypt/sign on remote systems, plus SSH agent forwarding. I recall this being a bear to setup, but it has worked flawlessly for several months now. Suddenly it broke. My searches all return the same links I read when I set it up, but I am stuck.



SSH agent forwarding inexplicably works. Remote system shows this:



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


I can login to other servers using SSH from the remote system and it uses the nano for auth (I know this because it requires touch to enable agent signing). I can see logs about the SSH signing in the gpg-agent log on the local system.



However, I can't get GPG sign/encrypt to work at all. If I run the following on the remote system:



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


In the local gpg-agent log I see no logs about the attempt. If I run this command, I can see log entries in the local gpg-agent log:



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>


Which results in these logs in the local 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>


If I run strace -f -F on gpg-connect-agent on the remote system, it seems to be connecting to a socket in /var/run, but not the one forwarded from the local system in ~/.gnupg/. I have tried removing both sockets, killing all gpg-agent processes and changed the SSH remote forward to go to either the /var/run location or the ~/.gnupg location to no avail. It is possible I screwed these steps up and I will try them again, but I want to know if someone knows the answer, and I would like to have an easy to find post for the next time this breaks.



LOCAL SYSTEM:



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


REMOTE SYSTEM:



ubuntu 17.10
gpg (GnuPG) 2.1.15
libgcrypt 1.7.8


EDIT:
Ok, no idea what changed, but I left it alone for a bit and came back and tried to switch the socket again and it now works:



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) = 0
socket(AF_UNIX, SOCK_STREAM, 0) = 5


Changing my SSH remote forward to this new location worked. I swear I tried this earlier using the socket path provided by gpgconf --list-dir agent-ssh-socket, without any luck. Probably forgot to kill the existing agent. And by happenstance, I just chanced upon a blogpost reporting that this changed:
https://blog.kylemanna.com/linux/gpg-213-ssh-agent-socket-moved/







share|improve this question














closed as off-topic by B Layer, G-Man, Jeff Schaller, George Vasiliou, jimmij Jan 6 at 14:50


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – B Layer, G-Man, Jeff Schaller, George Vasiliou, jimmij
If this question can be reworded to fit the rules in the help center, please edit the question.












  • I found the solution. I don't seem to have enough fake internet points to do anything further. Should I just delete the question? It has enough debugging pointers that it might be of use to someone in the future.
    – lopass
    Jan 6 at 4:06










  • I put it up for a close vote.
    – B Layer
    Jan 6 at 4:17












up vote
1
down vote

favorite









up vote
1
down vote

favorite











I am using a yubikey nano on my local system to do encrypt/decrypt/sign on remote systems, plus SSH agent forwarding. I recall this being a bear to setup, but it has worked flawlessly for several months now. Suddenly it broke. My searches all return the same links I read when I set it up, but I am stuck.



SSH agent forwarding inexplicably works. Remote system shows this:



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


I can login to other servers using SSH from the remote system and it uses the nano for auth (I know this because it requires touch to enable agent signing). I can see logs about the SSH signing in the gpg-agent log on the local system.



However, I can't get GPG sign/encrypt to work at all. If I run the following on the remote system:



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


In the local gpg-agent log I see no logs about the attempt. If I run this command, I can see log entries in the local gpg-agent log:



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>


Which results in these logs in the local 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>


If I run strace -f -F on gpg-connect-agent on the remote system, it seems to be connecting to a socket in /var/run, but not the one forwarded from the local system in ~/.gnupg/. I have tried removing both sockets, killing all gpg-agent processes and changed the SSH remote forward to go to either the /var/run location or the ~/.gnupg location to no avail. It is possible I screwed these steps up and I will try them again, but I want to know if someone knows the answer, and I would like to have an easy to find post for the next time this breaks.



LOCAL SYSTEM:



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


REMOTE SYSTEM:



ubuntu 17.10
gpg (GnuPG) 2.1.15
libgcrypt 1.7.8


EDIT:
Ok, no idea what changed, but I left it alone for a bit and came back and tried to switch the socket again and it now works:



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) = 0
socket(AF_UNIX, SOCK_STREAM, 0) = 5


Changing my SSH remote forward to this new location worked. I swear I tried this earlier using the socket path provided by gpgconf --list-dir agent-ssh-socket, without any luck. Probably forgot to kill the existing agent. And by happenstance, I just chanced upon a blogpost reporting that this changed:
https://blog.kylemanna.com/linux/gpg-213-ssh-agent-socket-moved/







share|improve this question














I am using a yubikey nano on my local system to do encrypt/decrypt/sign on remote systems, plus SSH agent forwarding. I recall this being a bear to setup, but it has worked flawlessly for several months now. Suddenly it broke. My searches all return the same links I read when I set it up, but I am stuck.



SSH agent forwarding inexplicably works. Remote system shows this:



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


I can login to other servers using SSH from the remote system and it uses the nano for auth (I know this because it requires touch to enable agent signing). I can see logs about the SSH signing in the gpg-agent log on the local system.



However, I can't get GPG sign/encrypt to work at all. If I run the following on the remote system:



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


In the local gpg-agent log I see no logs about the attempt. If I run this command, I can see log entries in the local gpg-agent log:



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>


Which results in these logs in the local 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>


If I run strace -f -F on gpg-connect-agent on the remote system, it seems to be connecting to a socket in /var/run, but not the one forwarded from the local system in ~/.gnupg/. I have tried removing both sockets, killing all gpg-agent processes and changed the SSH remote forward to go to either the /var/run location or the ~/.gnupg location to no avail. It is possible I screwed these steps up and I will try them again, but I want to know if someone knows the answer, and I would like to have an easy to find post for the next time this breaks.



LOCAL SYSTEM:



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


REMOTE SYSTEM:



ubuntu 17.10
gpg (GnuPG) 2.1.15
libgcrypt 1.7.8


EDIT:
Ok, no idea what changed, but I left it alone for a bit and came back and tried to switch the socket again and it now works:



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) = 0
socket(AF_UNIX, SOCK_STREAM, 0) = 5


Changing my SSH remote forward to this new location worked. I swear I tried this earlier using the socket path provided by gpgconf --list-dir agent-ssh-socket, without any luck. Probably forgot to kill the existing agent. And by happenstance, I just chanced upon a blogpost reporting that this changed:
https://blog.kylemanna.com/linux/gpg-213-ssh-agent-socket-moved/









share|improve this question













share|improve this question




share|improve this question








edited Jan 6 at 4:03

























asked Jan 5 at 22:51









lopass

62




62




closed as off-topic by B Layer, G-Man, Jeff Schaller, George Vasiliou, jimmij Jan 6 at 14:50


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – B Layer, G-Man, Jeff Schaller, George Vasiliou, jimmij
If this question can be reworded to fit the rules in the help center, please edit the question.




closed as off-topic by B Layer, G-Man, Jeff Schaller, George Vasiliou, jimmij Jan 6 at 14:50


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – B Layer, G-Man, Jeff Schaller, George Vasiliou, jimmij
If this question can be reworded to fit the rules in the help center, please edit the question.











  • I found the solution. I don't seem to have enough fake internet points to do anything further. Should I just delete the question? It has enough debugging pointers that it might be of use to someone in the future.
    – lopass
    Jan 6 at 4:06










  • I put it up for a close vote.
    – B Layer
    Jan 6 at 4:17
















  • I found the solution. I don't seem to have enough fake internet points to do anything further. Should I just delete the question? It has enough debugging pointers that it might be of use to someone in the future.
    – lopass
    Jan 6 at 4:06










  • I put it up for a close vote.
    – B Layer
    Jan 6 at 4:17















I found the solution. I don't seem to have enough fake internet points to do anything further. Should I just delete the question? It has enough debugging pointers that it might be of use to someone in the future.
– lopass
Jan 6 at 4:06




I found the solution. I don't seem to have enough fake internet points to do anything further. Should I just delete the question? It has enough debugging pointers that it might be of use to someone in the future.
– lopass
Jan 6 at 4:06












I put it up for a close vote.
– B Layer
Jan 6 at 4:17




I put it up for a close vote.
– B Layer
Jan 6 at 4:17















active

oldest

votes






















active

oldest

votes













active

oldest

votes









active

oldest

votes






active

oldest

votes

Popular posts from this blog

Peggy Mitchell

Palaiologos

The Forum (Inglewood, California)