ssh-agent stopped working

I too am seeing this error trying to use ssh-agent forwarded over an ssh connection:


1password.desktop[84193]: INFO 2022-10-28T13:04:20.199 tokio-runtime-worker(ThreadId(2)) [1P:foundation/op-sys-info/src/process_information/linux.rs:367] no GUI info available to determine top level parent
1password.desktop[84193]: WARN 2022-10-28T13:04:20.199 tokio-runtime-worker(ThreadId(2)) [1P:ssh/op-ssh-agent/src/lib.rs:416] Unable to get client_info for pid: 40121


PID 40121 is my ssh connection to $remote. I can run ssh-add -L successfully on $remote, but any attempt to use the key fails with the above appearing in debug logs.

This happens only when using agent forwarding.

Versions:
* 1Password for Linux 8.9.8 (80908001) running https://swaywm.org/ on Linux 6.0.2-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 15 Oct 2022 14:00:49 +0000 x86_64 GNU/Linux.
* Local ssh: OpenSSH_9.1p1, OpenSSL 1.1.1q 5 Jul 2022
* Remote ssh: OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017

I can reproduce consistently with that setup, but things work fine when remote ssh version is OpenSSH_9.0p1, OpenSSL 1.1.1q 5 Jul 2022. This is surprising to me.

Let me know if I can be of further assistance in debugging; I can reliably reproduce, and am happy to run debug builds etc if that's helpful.

I had the same issue, it happened on some machines and not others. Tracking back from the reference to no GUI info available to determine top level parent
I managed to find the cause.

I had


ControlMaster auto
ControlPath ~/.ssh/%r@%h:%p.sock
ControlPersist yes


configured in my .ssh/config for the server. This means the connection is kept open as a socket and the terminal uses that meaning on reauth process.

The side effect was that this broke the 1Password SSH Agent as the connection didn't have a GUI attached. Removing this configuration meant everything worked correctly again.

Hi @lawrencegripper:

Thanks for sharing that. We're actively investigating situations like this, so thanks for the additional details.

Jack

I'm running into this as well. I see it both during SSH authentication and also during git commit signing using my SSH key.


WARN 2022-12-19T13:19:55.881 tokio-runtime-worker(ThreadId(8)) [1P:ssh/op-ssh-agent/src/lib.rs:426] Unable to get client_info for pid: 58009
WARN 2022-12-19T13:20:22.788 tokio-runtime-worker(ThreadId(5)) [1P:ssh/op-session-info/src/macos.rs:37] no top level process found, launchd is missing from process tree


With git commit signing configured, a command like git commit --allow-empty -m 'Test commit' sporadically fails

```
$ git commit --allow-empty -m 'Test commit'
error: agent returned an error

fatal: failed to write commit object
$ git commit --allow-empty -m 'Test commit'
[test-1Password 8e11b5f05f] Test commit
$ git commit --allow-empty -m 'Test commit'
error: agent returned an error

fatal: failed to write commit object
```

Each time it fails, the 1Password_rCURRENT.log shows the pair of WARN logs I listed above. Versions:

• 1Password for Mac 8.9.11 (80911019)
• macOS 13.1 (22C65)

I recently upgraded from macOS 12 to macOS 13. Perhaps that's part of it. My suspicion is that 1Password is trying to get information about the process requesting a signature with the SSH key, and that for some reason it is occasionally unable to get that information. No obvious rhyme or reason sticks out to me:


$ for _ in {0..19}; do git commit --allow-empty -m 'Test commit' &> /dev/null && echo 'Success' || echo 'Failure'; done
Failure
Failure
Success
Failure
Success
Success
Failure
Success
Failure
Success
Failure
Success
Success
Failure
Success
Success
Failure
Success
Failure
Success


And success rate varies:


$ for _ in {0..19}; do git commit --allow-empty -m 'Test commit' &> /dev/null && echo 'Success' || echo 'Failure'; done | sort | uniq -c
5 Failure
15 Success
$ for _ in {0..19}; do git commit --allow-empty -m 'Test commit' &> /dev/null && echo 'Success' || echo 'Failure'; done | sort | uniq -c
8 Failure
12 Success


From reading the other posts on this thread, it seems there are two separate issues. One is the sporadic failure to get client_info, and the other is no GUI info available. I've only experienced the former, not the latter.

Hi @ravron:

Are you using Terminal.app, iTerm, or another terminal app? Let me know, as we're continuing to investigate this.

Jack

@Jack_P_1P: I'm using iTerm2, 3.4.18.

I am also facing this issue, it is quite disruptive and I consider disabling the ssh agent until it is fixed. Any idea when a fix can be expected? Thanks, otherwise I love the feature!

Hi @kudzuspaver:

I'd like to ask you to create a diagnostics report from your Mac:

Sending Diagnostics Reports (Mac)

Attach the diagnostics to an email message addressed to support+forum@1password.com.

With your email please include:

• A link to this thread: https://1password.community/discussion/130082/ssh-agent-stopped-working#latest
• Your forum username: kudzuspaver

You should receive an automated reply from our BitBot assistant with a Support ID number. Please post that number here. Thanks very much!

@Jack_P_1P I am happy to do so as well, if you like. I am still experiencing the issue as described previously.

Hi @ravron:

That would be helpful as well. Please follow the same steps but mention your username. 🙂

Jack