ssh-agent stopped working
kzolnowski
Hi,
After last nigthly update ssh-agent stopped working with error:
sign_and_send_pubkey: signing failed for ED25519 "SSH key ed25519 private" from agent: agent refused operation
Here's a log:
INFO 2022-05-20T09:38:39.891 tokio-runtime-worker(ThreadId(16)) [1P:ssh/op-agent-controller/src/desktop.rs:311] SSH Agent has started.
WARN 2022-05-20T09:42:55.966 tokio-runtime-worker(ThreadId(16)) [1P:ssh/op-session-info/src/macos.rs:39] no top level process found, launchd is missing from process tree
WARN 2022-05-20T09:42:55.966 tokio-runtime-worker(ThreadId(16)) [1P:ssh/op-ssh-agent/src/lib.rs:356] Unable to get client_info for pid: 3445
WARN 2022-05-20T09:47:04.442 tokio-runtime-worker(ThreadId(15)) [1P:ssh/op-session-info/src/macos.rs:39] no top level process found, launchd is missing from process tree
WARN 2022-05-20T09:47:04.443 tokio-runtime-worker(ThreadId(15)) [1P:ssh/op-ssh-agent/src/lib.rs:356] Unable to get client_info for pid: 3633
Could you please help me?
1Password Version: 8.8.0 80800101, on NIGHTLY channel
Extension Version: Not Provided
OS Version: macOS 12.3.1
Comments
Team Member
@kzolnowski We're investigating the issue now. We'll keep you posted here.
Experiencing the same issue as of today (worked fine yesterday)
(also running Mac 80800101 Nightly build, but on macOS 12.4)
Team Member
@kzolnowski @XIII The fix just got released on the nightly channel, let us know if that worked for you!
Yes! Thank you.
Hope this does not happen again...
Hey,
After last nighlty update the issue is fixed for me. Thanks!
@floris_1P How does one install the nightly build? I'm on the beta build currently and having the same error. Running OpenSuse Tumbleweed, I start 1Password in silent and debug mode at session start. I'm also using xmonad wm instead of a typical DE if it's relevant. Here are the logs:
I'm getting the same error now.
1Password for Mac 8.9.8 (80908007)
using iterm2
If I keep trying to ssh, it often resolves itself. Also when I open a new terminal window.
I'm getting the same error now.
1Password for Mac 8.9.8 (80908007)
using iterm2
If I keep trying to ssh, it often resolves itself. Also when I open a new terminal window.
I'm getting the same error now.
1Password for Mac 8.9.8 (80908007)
using iterm2
If I keep trying to ssh, it often resolves itself. Also when I open a new terminal window.
sorry about the triple post!
I too am seeing this error trying to use ssh-agent forwarded over an ssh connection:
PID 40121 is my ssh connection to
$remote. I can runssh-add -Lsuccessfully 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:
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 parentI managed to find the cause.I had
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.
Team Member
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.
With git commit signing configured, a command like
git commit --allow-empty -m 'Test commit'sporadically failsEach time it fails, the
1Password_rCURRENT.logshows the pair of WARN logs I listed above. Versions: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 SuccessAnd 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 SuccessFrom 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 isno GUI info available. I've only experienced the former, not the latter.Team Member
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!
Team Member
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
[email protected].With your email please include:
kudzuspaverYou 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.
Team Member
Hi @ravron:
That would be helpful as well. Please follow the same steps but mention your username. 🙂
Jack
Done. The support ID number I received is [#IFU-93959-615].
I have also started seeing this issue and sent a diagnostic report of my own. What's strange is that this only appears to be happening on one particular git repo for me. All of my other git repos (same host, github.com) seem to work fine. I've tried restarting 1password and my computer to no avail. I've also tried recloning the repo to no avail. I am using Alacritty, tmux, and zsh on a fresh install of macOS.
The ticket number I got back is: #DMI-82239-715
I'm seeing this too (Mac, 1Password 8.9.11, Terminal.app):
sign_and_send_pubkey: signing failed for ED25519 "SSH Key" from agent: agent refused operation
In my case the issue seems to be because I use a Touch ID laptop with an external display and the lid closed. If I open the lid, quit/lock 1Password, and unlock using Touch ID then my SSH command works. I can then close the lid and it continues to work.
The clue for this was in the logs:
ERROR 2023-01-06T09:37:30.131 tokio-runtime-worker(ThreadId(4)) [1P:op-automated-unlock/src/lib.rs:295] Failed to authorize using system biometry: FailedToUnlockWithKeys(BiometryUnavailable)
INFO 2023-01-06T09:37:30.131 tokio-runtime-worker(ThreadId(4)) [1P:ssh/op-ssh-agent/src/lib.rs:460] Session was not authorized
Done, the support ID is [#MWS-48134-783]. Thank you!
Same. :)
[#KIL-32375-262]
Team Member
Thanks folks!
1P was working fine on my MacPro until a recent restart, which also installed a new Beta of 1Password (not Ventura).
sign_and_send_pubkey: signing failed for ED25519 "whatever" from agent: agent refused operation
Using:
1Password for Mac 8.10.0 (81000032)
I'm being forced onto "Nightly" version, for whatever reason (not by choice, tried Production, rebooting, etc, but, I keep being forced into Nightly).
Tried with Apple Terminal, as well as Warp terminal. Prefer Warp.
Worked this morning, now all ssh is broken for authentication whilst I undo the use of 1P.
Okay, found workaround; seems that something in a recent beta changed for the SSH agent somewhat significantly; different UI elements from the previous versions as well. Shut system down, restarted, still had error, but, found that for some reason the update disabled my Apple Watch, so, the error about refusing operation was really about not having a biometric device connected (looked in Console logs).