SSH agent fails with "sign_and_send_pubkey: signing failed: agent refused operation" first time

telnetdoogie
telnetdoogie
Community Member
edited August 2022 in SSH

When I'm using 1password for my ssh auth on Windows 11 (OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2) - everything works ONLY IF I've already done the first 1password 'unlock' using my full password.

If I've just launched 1password or just logged into my machine, and haven't yet done the 1Password app unlock, I get the error:

sign_and_send_pubkey: signing failed: agent refused operation
...1password prompts me for my password in the foreground, but in the background, the ssh client has already moved on, and I'm prompted to provide a password for the remote host.

If I've already done the unlock in the 1password app, however, the ssh client waits while I'm prompted for my "Windows Hello" pin in 1password, and upon entering it, will get the provided key and everything works.

Is this the intended behavior?

The logs during this scenario (1password not initially unlocked with a password) show the following:

INFO  2022-08-22T18:05:38.283 tokio-runtime-worker(ThreadId(6)) [1P:ssh\op-ssh-agent\src\lib.rs:419] Session was not authorized
INFO  2022-08-22T18:05:38.513 tokio-runtime-worker(ThreadId(14)) [1P:op-app\src\app\backend\unlock.rs:242] System unlock was attempted but we cannot use it.
INFO  2022-08-22T18:05:38.514 tokio-runtime-worker(ThreadId(6)) [1P:op-app\src\app\backend\unlock.rs:242] System unlock was attempted but we cannot use it.

The logs during the 'Windows Hello' scenario (1password previously unlocked) show the following:

INFO  2022-08-22T18:07:55.723 tokio-runtime-worker(ThreadId(14)) [1P:op-data-layer\src\load.rs:136] loaded 442 items in 3 vaults for account: redacted
INFO  2022-08-22T18:07:55.725 op_executor:invocation_loop(ThreadId(22)) [1P:op-app\src\app\backend\unlock.rs:82] Lock state changed: Unlocked
INFO  2022-08-22T18:07:56.253 tokio-runtime-worker(ThreadId(8)) [1P:op-syncer\src\sync_job.rs:284] synced account redacted(0.0862899s)
INFO  2022-08-22T18:07:56.297 tokio-runtime-worker(ThreadId(2)) [1P:op-data-layer\src\file.rs:607] find_and_complete_pending_uploads: 'redacted'
INFO  2022-08-22T18:07:56.308 tokio-runtime-worker(ThreadId(8)) [1P:op-data-layer\src\sync.rs:522] The B5 Notifier for (redacted) has connected, now monitoring for events.

1Password Version: 80800203
Extension Version: Not Provided
OS Version: Windows 11 21H2
Browser:_ N/A

Comments

  • floris_1P
    floris_1P
    edited August 2022

    Upon reboot and after 14 days of using Windows Hello, you're required to enter your account password once before Windows Hello can be used (again). After that, if you lock 1Password or 1Password auto-locks, you should be able to unlock and/or authorize SSH session with Windows Hello. Does that match with your experience?

    About the SSH experience around reboots and the 14-day threshold: this is something we're working on to improve.

  • telnetdoogie
    telnetdoogie
    Community Member

    I understand you're required to re-login after a lock or after some period... however, why doesn't the SSH agent 'pause' things just like it does when prompting for a windows Hello login? The way I'd expect it to work is exactly the same way as when unlocking with hello / pin.

    when 'unlocked'
    ssh login attempted -> (ssh client 'waits' here) -> hello prompt -> 1p unlocked -> ssh login completes

    when 'locked'
    ssh login attempted -> ssh login fails (agent issue?) -> 1p unlock prompt -> 1p unlocked -> nothing

    Why wouldn't / couldn't the 'locked' scenario behave the exact same way as the top example? in both cases I'm unlocking / authing in some way... one of them just sort of fails, the other gracefully waits.

  • floris_1P
    floris_1P

    This issue has been fixed. The prompt will now always show and not fail after the password timeout.

This discussion has been closed.