ssh agent on Mac Os - no prompt for password after the first connection

cp2300

Hello!

I have a question i did not find an answer to yet.

We are a database related support company, and we use ssh keys to login into machines.Recently we started to try out the ssh agent feature of 1Password.

It works great so far, but we noticed something, i have no real explanation for.

We are working with Mac Os and use Iterm2 to connect to a bunch of different machines, and with our configuration , get prompted to use the Touch Id for every new connection somewhere - which is also exactly what we want.

Yet we noticed a behavior, when the the lid of a macbook is closed (while 1Password is already unlocked) there is no prompt for Touch Id or Password. But there is a similar popup which requests access from Iterm2 to 1Password - but instead needing to authorize with Touch Id or Password, there is a simple "Authorize" Button.

Why is that?

When 1 Password is locked, it is working as intended, and instead of the Touch Id feature you get prompted to enter the Password instead. But shouldnt this be the same for all further connections too, the same as it would, if the Macbook lid was open?

TLDR:

Macbook Lid Open:

1. New connection -> prompt for touch ID to unlock vault and connect

2. New connection -> prompt for touch ID to establish connection

Macbook Lid Closed:

1. New connection -> prompt for password to unlock vault and connect

2. New connection -> prompt to click blue "authorize"-Button, no touch id or password required

Why are further connections after the first one (in the case of a Macbook with closed lid) not secured and can just be established by clicking a button?

Cheers,

---

1Password Version: 8.10.16
Extension Version: Not Provided
OS Version: macOS 14.0
Browser: Not Provided

floris_1P

Great question! This is a design choice we've been internally debating for a while before launching this functionality.

The reason why we don't require the account password to authorize SSH connections when 1Password is already unlocked is because the additional protection that this gives does not outweigh the UX overhead.

On macOS, a malicious process that would try to approve a malicious SSH connection by automating the Authorize button click would first need explicit Accessibility permissions in the OS settings or require root access. This makes it acceptable to lower the approval requirements on macOS, in favor of the UX for non-Touch ID / clamshell mode users.

However, with this reasoning you could argue that when 1Password is already unlocked we should not ask for Touch ID either, because it's not required. But we concluded that in the case of Touch ID, there is some value in the consistent UX of placing your finger on the Touch ID sensor regardless of whether 1Password is locked or unlocked.

cp2300

Thank you very much for your answer.

I can see the approach taken and its solid reasoning.

Our concerns with that approach are still, that if someone is knowledgeable with how it works, could argue that, when people get away from their workplace (forgetting to lock their Machine or Vault) - someone else could use their machine by just closing the lid, and and they can establish new connections to every other system, just by clicking the "authorize" button.

I think either a toggle-able option which makes it to prompt for the password for all new connections when no Touch ID is available, or a function with locks the vault on lid closure would solve this.

We would prefer to use 1Password, instead of proprietary access control. But we feel, that this quirk could lead to problems in security audits, especially GDPR related ones.

floris_1P

Our concerns with that approach are still, that if someone is knowledgeable with how it works, could argue that, when people get away from their workplace (forgetting to lock their Machine or Vault) - someone else could use their machine by just closing the lid, and and they can establish new connections to every other system, just by clicking the "authorize" button.
I think either a toggle-able option which makes it to prompt for the password for all new connections when no Touch ID is available, or a function with locks the vault on lid closure would solve this.

We have considered that, but adding in Touch ID to approve SSH key usage would not protect against a malicious actor physically present in the room getting hold of the workstation while 1Password is unlocked, because they could simply export the private key within the 1Password app, or reveal/export other vault items from that could allow them to control the server's authorized_keys, such as GitHub or AWS credentials.

So having good automated locking rules set up (which are already configured by default) is very important regardless of the SSH agent.

floris_1P

Here are the docs for the 1Password auto-lock settings.