Forwarded SSH agent refuses operation after a while

Hollow
Hollow
Community Member

I've been following this thread to setup agent forwarding for 1Password.

I can successfully use the key(s) stored in 1Password on the remote machine, but after a few seconds the agent refuses operations from the remote session:

❯ echo $SSH_AUTH_SOCK
/Users/bene/.ssh/ssh_auth_sock

❯ ssh-add -l
256 SHA256:**** SSH-Key (****) (ED25519)
3072 SHA256:**** SSH-Key (****) (RSA)

❯ ssh some.host

❯ date && ssh-add -l
Sat Jan 14 07:21:48 AM UTC 2023
256 SHA256:**** SSH-Key (****) (ED25519)
3072 SHA256:**** SSH-Key (****) (RSA)

❯ date && ssh-add -l
Sat Jan 14 07:22:04 AM UTC 2023
256 SHA256:**** SSH-Key (****) (ED25519)
3072 SHA256:**** SSH-Key (****) (RSA)

❯ date && ssh-add -l
Sat Jan 14 07:22:15 AM UTC 2023
2023/01/14 08:22:15 agent 11: agent: client error: write unix ->/Users/bene/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock: write: broken pipe
                                       error fetching identities: agent refused operation

1Password Version: 8.9.13
Extension Version: Not Provided
OS Version: macOS 13.1
Browser:_ Not Provided

Comments

  • Hollow
    Hollow
    Community Member

    I have also checked log files in /Users/bene/Library/Group Containers/2BUA8C4S2C.com.1password/Library/Application Support/1Password/Data but couldn't find anything suspicious

  • Hi @Hollow:

    Thanks for reaching out about this! Just to confirm, are you SSHing into a device that also has 1Password installed and configured as its SSH agent?

    The reason I ask is that when SSH agent forwarding is enabled, the agent on the remote host (in the environment variable SSH_AUTH_SOCK) should be of the form: /tmp/ssh-abcdef/agent.123456. If you're seeing /Users/bene/... on that device, that would indicate that the host you've connected to also has 1Password configured as the SSH agent locally. Is this a situation where you have say a MacBook and an iMac or Mac Pro, and you're connecting from your MacBook to the iMac or Mac Pro? Let me know, and I can take a closer look at how to resolve this.

    Jack

  • Hollow
    Hollow
    Community Member

    Hi @Jack.P_1P

    My local machine is a MacBook with the 1Password agent running. The issue starts exactly 30 seconds after being logged in to remote machines running Linux with no other keys available or agent running:

    ❯ ssh *****
    
    ❯ echo $SSH_AUTH_SOCK; date && ssh-add -l && sleep 30 && ssh-add -l
    /tmp/ssh-XXXX10DkkS/agent.430829
    Wed Jan 18 05:23:59 AM UTC 2023
    256 SHA256:**** SSH-Key (****) (ED25519)
    3072 SHA256:**** SSH-Key (****) (RSA)
    2023/01/18 06:24:29 agent 11: agent: client error: write unix ->/Users/bene/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock: write: broken pipe
                                           error fetching identities: agent refused operation
    

    Please note that my MacBook is using CET and the remote system is using UTC

  • Which OpenSSH version are you running locally and remotely (ssh -V)? And does this happen only on one particular remote or everywhere, consistently? And does it only happen with the 1Password agent socket or also if you use the one provided by the standard OpenSSH agent?

  • Hollow
    Hollow
    Community Member

    I'm running OpenSSH_9.1p1, OpenSSL 1.1.1s 1 Nov 2022 from homebrew locally and OpenSSH_8.7p1, OpenSSL 3.0.1 14 Dec 2021 from AlmaLinux 9.1 on the remote host. This fails consistently on multiple (I did not test all) of our servers. However, I've also tested it with a connection to my local Synology NAS running OpenSSH_9.0p1, OpenSSL 1.1.1s 1 Nov 2022 and this seems to work just fine 🤔

  • Hollow
    Hollow
    Community Member

    I've tested this a bit more and the issue seems to be caused by the ProxyCommand directive required for Okta Advanced Server Access (formerly ScaleFT): https://help.okta.com/asa/en-us/Content/Topics/Adv_Server_Access/docs/setup/ssh.htm

  • Hi @Hollow:

    Thanks for following up. We'll definitely take a closer look at this.

    Jack

This discussion has been closed.