SSH_AUTH_SOCK should be set per user, not system-wide

[rjc]

The current suggestion of setting SSH_AUTH_SOCK to /usr/local/var/run/yubikey-agent.sock doesn't take shared, multi-user systems into account, i.e. switch user, etc.

Setting it to /tmp/${USER}-yubikey-agent.socket or $HOME/.yubikey-agent.sock, etc. would probably make more sense, no?

[FiloSottile]

There is only one YubiKey connected to a system, regardless of how many users there are. What's the use case / difference in UX?

[rjc]

Based on the README:

yubikey-agent is a seamless ssh-agent for YubiKeys.
Easy to use. A one-command setup, one environment variable, and it just runs in the background.
Indestructible. Tolerates unplugging, sleep, and suspend. Never needs restarting.

I understand that it's an agent, i.e. starts when user logs in and runs in the background, then it creates a socket with ownership and permissions for that user. Then the user locks the screen, without logging off, and another user logs in. When the other user's agent starts, the socket already exists and is owned by the first user. Am I missing something? The usecase is a shared system, be it a family laptop or work terminal - Linux or macOS, doesn't matter.

[rjc]

I forgot to add - obviously, each user has their own YubiKey.

[joneskoo]

https://tools.ietf.org/html/draft-miller-ssh-agent-02

Since being able to access an agent is usually sufficient to perform
private key operations, it is critically important that the agent
only be exposed to its owner.

This at least is important. #9 current version would make it not specific to an user?

I think the case where one laptop is used turn by turn by multiple users would be reasonable enough; in that case the session should start on first use and end on disconnect. Per-user socket would work for this, no? Any downsides?

EDIT: I mean the agent could run for each user, but hold the Yubikey session (with PIN cached) only as long as it's plugged in.

[joneskoo]

Limiting to one user instead of global would be important in case of other untrusted users (could be service users too). Otherwise another (service) user could trigger the touch prompt and gain access to authenticate using the key by confusing what the touch actually authorized.

[unchainedio]

on linux where should this SOCK point? i dont see any yubikey-agent.sock

[FiloSottile]

I think there are two separate concerns here: socket ownership, and location.

I agree the socket should be owned by the local user. That is already the case on macOS where the daemon is installed to run as the local user, and the socket is owned by the local user.

$ ls -l /usr/local/var/run/yubikey-agent.sock
srwxr-xr-x  1 filippo  admin  0 17 Jun 00:09 /usr/local/var/run/yubikey-agent.sock

As for the location, on macOS the Homebrew prefix (/usr/local by default) is owned by the user that installed Homebrew, so it's an appropriate path for user-owned files.

On other OSes it's likely that the most appropriate path is within $HOME.

Note that yubikey-agent will take an exclusive lock on the YubiKey, so two separate instances running at the same time is not a supported configuration. At the moment we don't support multiple YubiKeys at all, but even once we do, I don't plan to support a config option to only control a certain token, so multiple instances running at the same time will never be supported.

[rjc]

There seems to be an assumption that macOS (a Unix OS) is a single-user system (sic!), i.e. that at any given time, it'll only ever be used by a single person. Unless I'm missing something, the system-wide socket path is the only thing that prevents multiple users running their own instances of yubikey-agent with their own respective keys.

[FiloSottile]

A Homebrew installation is single-user. You can install Homebrew in $HOME, and the yubikey-agent socket will be created there. The default is in a system path (/usr/local). That's a Homebrew decision, not ours. (But I don't disagree with it, because most macOS systems are signle-user.)

But again, regardless of the path, yubikey-agent takes an exclusive lock on the hardware key. If you run multiple instances, they will just fight for control over it. It's not a supported configuration.

[rjc]

A Homebrew installation is single-user.

Sure - it is a bug, IMHO. It's beyond me why would anyone in the 21st century write software which can only be used by a singe person on any given machine. However, this is easily fixed/worked around, and doesn't entirely prevent multiple users from using it. Not every macOS installation is on a MacBook Pro which will never see another user. Let's forget about Homebrew for a bit, though - this is about yubikey-agent, which I presume can also be installed by other means? ;^)

A single yubikey-agent running as one user takes an exclusive lock on the hardware key - I'm with you. What I don't understand is, if we make the socket a per-user setting, what prevents another user from running another yubikey-agent under their own UID with their own hardware key? What am I missing?

[FiloSottile]

There is no "their own hardware key". USB ports are not per-user. Once multi-key support lands yubikey-agent will just enumerate the connected YubiKeys, and connect to them.

Anything else would need a way to specify which YubiKeys are yours, which violates the headline feature of yubikey-agent: zero configuration. I understand this makes it less flexible, and bars the use case of multiple-users-with-multiple-keys. That's a deliberate decision.

[rjc]

I think we might be thinking about two different scenarios - multiple users on the system, per-user yubikey-agent processes running happily on the system, and only one key (obviously!?) plugged in at at any given time.

Something along the lines of:

1. I log in.
2. Plug my key.
3. Run yubikey-agent.
4. Work.
5. Unplug my key.
6. Log out.
7. My yubikey-agent process is running or gets killed - doesn't really matter.
8. My colleague logs in.
9. Pugs their key in.
10. Runs their instance of yubikey-agent.
11. Work.
12. Unplug the key.
13. Log out.

yubikey-agent is an agent, right? Runs in user context? It isn't a system daemon running as root? What stands in the way of the above scenario working as described?

[FiloSottile]

yubikey-agent is a user daemon, meant to keep running in the background for the duration of the user session, and it will automatically reacquire the YubiKey when it's unplugged and replugged. This is by design.

The issue is at step 7: if your yubikey-agent is not killed, it will go and grab your colleague's YubiKey, as it's expected to. It can't know it's not yours, and it's designed to support unplug cycles.

Anyway I don't know what we are discussing. I agree the socket should be in a user-owned path. On Homebrew systems, that happens to be /usr/local/var/run by default.