Protect what matters – even after you're gone. Make a plan for your digital legacy today.
Forum Discussion
Solved
SSH Agent Permission Denied for Multiple User Accounts on Same Machine
Hi,
I think this is basically the same issue reported here (but not resolved): SSH Agent Permission Denied for Multiple Users on the same machine over RDP | 1Password Community but without the RDP aspect.
I echo that user's sentiments: 1Password being an SSH Agent is awesome and I use it daily.
My situation is this: I have a laptop that I use for personal and work related development. To keep these activities separate I have two logins on this computer. One for work, one for personal. Up until I got this new laptop (a month ago) I didn't have the separate logins so this wasn't an issue. But now it's an issue.
After booting the laptop, whichever account I log into first will have no issues using the SSH Agent (`ssh-add -l` shows the expected available SSH keys). But then when I login to the second account, `ssh-add -l` shows `Error connecting to agent: Permission denied`). If I switch back to the first account, it continues to work fine. If I logout of the first account, the second account (which is now the only one logged in) continues to give the same error. Only rebooting the system and logging into that account first will let me use the SSH Agent with it.
Any idea how to solve this? I'd really like for this to just work!
1Password Version: 8.12.1
Windows Version: 11 Pro 25H2 26200.7623
I just wanted to follow this up with the answer I got from support and why this is a known issue that isn't going to be solved.
Windows uses a hardcoded named pipe that persists across sessions and cannot be shared. This is why when you are setting up SSH Agent on Windows, there is a step to disable the OpenSSH service so that the pipe is freed up for 1Password to use. On Linux/Mac, UNIX sockets are used which allow multiple instances to co-exist and this is not an issue on those platforms.
They have considered a 1Password background service to act as traffic controller to the pipe for handling multiple instances of 1Password, but this introduces significant security problems that contradicts their strict per-user process isolation security model. They are not to say it would be impossible, but it does not sound like it is something they are pursuing at this time.
The only option is to make sure the pipe is freed up in one instance before trying to use it in another. This would mean signing out of User A before logging in as User B. Or fully quitting 1Password in User A before switching to User B. If both users are admins on the machine, then you could kill the other user's 1Password with an elevated script. None of these are ideal and they know that, but they're a bit stuck due to how Windows pipes work.
3 Replies
devinwyatt
Don't fall for the its windows fault. I run into same issue on MacOS and Linux.
If it's a known issue from the original post 3 years ago than that is the final straw. 1password Service Account workflow was not built for "solo=developers". I hope to god that they didn't develop the product as an upsell opportunity for loyal customers.Their explanation makes complete sense and I can imagine my use case here is a bit of an edge case. Am I disappointed? Absolutely. Do I buy their explanation? Yeah, it seems reasonable to me. Why would they lie to me about this? Am I going to stop using 1Password because of it? No.
I just wanted to follow this up with the answer I got from support and why this is a known issue that isn't going to be solved.
Windows uses a hardcoded named pipe that persists across sessions and cannot be shared. This is why when you are setting up SSH Agent on Windows, there is a step to disable the OpenSSH service so that the pipe is freed up for 1Password to use. On Linux/Mac, UNIX sockets are used which allow multiple instances to co-exist and this is not an issue on those platforms.
They have considered a 1Password background service to act as traffic controller to the pipe for handling multiple instances of 1Password, but this introduces significant security problems that contradicts their strict per-user process isolation security model. They are not to say it would be impossible, but it does not sound like it is something they are pursuing at this time.
The only option is to make sure the pipe is freed up in one instance before trying to use it in another. This would mean signing out of User A before logging in as User B. Or fully quitting 1Password in User A before switching to User B. If both users are admins on the machine, then you could kill the other user's 1Password with an elevated script. None of these are ideal and they know that, but they're a bit stuck due to how Windows pipes work.
