Use SSH Agent

[fnkr]

My setup is like this: my (encrypted) private key is stored in ~/.ssh/id_rsa. The passphrase for this key is stored in Keychain. The agent is launched automatically by the system, the key is inserted automatically. [Docs] It would be great if Postico would just use the agent instead of trying to load the encrypted key from disk.

Benefits:

• Security: Only the OS (access group com.apple.ssh.passphrases) can access the passphrase of the private key.
• Ease of use: Other tools (e.g. ssh, rsync, git, Cyberduck, Sequel Pro, [basically any other tool that I use], and soon Postico?) "just work" because they use the agent, no need to set path to private key or anything.

libssh2 already supports this so it shouldn't be hard to implement.

[jakob]

The problem is that sandboxed apps can’t access unix sockets outside of their sandbox. This means that in order to use SSH Agent, Postico can’t be sandboxed any more.

I always tried to have a single version of Postico, so that there is no difference between the Mac App Store version and the normal one.

I also think that it’s safer to have Postico sandboxed — for the customer it’s good to know that Postico can’t install a rootkit.

But I’ve seen that customers don’t really care about the improved security of the Sandbox, but they do care about the inconvenience it brings. So maybe it’s time to say good bye to Sandbox, and the Mac App Store.

[jakob]

(Note: I’ve reported this issue to Apple, and they consider the inability to use SSH Agent “working as intended”)

[fnkr]

I absolutely agree with you. I would like to use the Mac App Store and it's sandboxed applications, however, I've experienced too many drawbacks and now I'm no longer using it at all. Apple makes it really hard for app developers and then they don't obey their own rules (e.g. Xcode must be installed through the App Store – but isn't sandboxed). Also: a sandboxed app can read my private key and ask for the passphrase, but it isn't allowed to use the agent? And that's supposed to be safer?

[christos]

I am having the exact same issue, and it is a dealbreaker.

Could you not prompt for the key's passphrase and store it in Postico's keychain, if the user chooses to, or prompt for it every time otherwise?

Update: Using 1.4beta3 and an id_ed25519 key

[jakob]

@christos I'm not sure I understand your suggestion. @fnkr talks about using SSH Agent, specifically so that Postico would not need the private key passphrase. As I explained, that is not possible because of Sandboxing.

Could you explain in more detail what you'd like Postico to do? It would help if you could open a new issue, and answer the questions from the issue template.

[fnkr]

@jakob Have you made a decision regarding the sandbox problem yet? Could you provide a non-sandboxed version of the app that supports this?

[jakob]

@fnkr Rewriting the SSH Tunnel part to use OpenSSH instead of libssh2 is a bigger project. It's something that we're considering for the future, we've made no decision yet.

It's not a feature that we can offer in the short term.

[jakob]

PS: To answer your question:

Also: a sandboxed app can read my private key and ask for the passphrase, but it isn't allowed to use the agent? And that's supposed to be safer?

A sandboxed app can read your private key after you have selected it in an open dialog. Sandboxed apps with the right entitlement can open arbitrary user selected files. Unfortunately that doesn't work for sockets, which SSHAgent uses.

A workaround might be to use a non-sandboxed utility that create a socket inside Postico's sandbox that forwards to the SSHAgent socket. Might be worth a try...

[fnkr]

@jakob Why switch to OpenSSH? libssh2 can use agents as well. (See my initial post.)

[jakob]

@fnkr Sorry, I was confusing this issue with another one... (I'm currently in Canada for a conference and feel a bit jetlagged)

You're right, just adding support for SSH Agent in libssh2 is a lot less work than switching to OpenSSH. I'm still hesitant to offer multiple builds of Postico, since it would make our build process more complex, but we could try that.

No promises when I will get to it though...

[sj26]

I'm giving Postico a good go at the moment and this feature is the one thing I'm sorely missing.

Would you need a separate build? I presume there's a way to detect if the app is running in a sandbox environment, if it's not then it could attempt to use the ssh agent if it's available — and this could be in a single build?

[tkrajacic]

This is the biggest pain point for me at the moment. I am sharing my Postico 2 favorites between my development machines and I always have to select the private key for the ssh tunnel on each one anew, because it has to be picked from the file system, and by that the bookmark becomes invalid on all other machines. Being able to have the key being shared in the keychain would make this infinitely better. :(

[jakob]

@tkrajacic I'm currently working on making SSH keys work when you sync favorites in Postico 2. Since this is orthogonal to ssh-agent, I opened a new issue to discuss this problem. Could you have a look at issue #717?

[florisvdg]

The problem is that sandboxed apps can’t access unix sockets outside of their sandbox. This means that in order to use SSH Agent, Postico can’t be sandboxed any more.

You could consider adding a Locate SSH agent... button in the SSH setup pane, which would display a Powerbox to locate the socket file and pass that path on to libssh.

[jakob]

@florisvdg last time I tried, that didn't work. Powerbox only gives the sandboxed app permission to open regular files, it does not give permission to open sockets.

[florisvdg]

@jakob Okay, here's another idea: sandboxed apps should be able to connect to sockets that live within the app container. So what could work is this:

1. User creates a socket file (actual file, so no symlinks) in the app container, e.g. ~/Library/Containers/at.eggerapps.Postico/Data/agent.sock.
2. User sets SSH_AUTH_SOCK and starts Postico with SSH_AUTH_SOCK set.
3. User configures their SSH agent and client to use the socket.
4. User leaves private key field empty in Postico and Postico falls back to use SSH_AUTH_SOCK to handle authentication.

To take this workflow a step further, the first two steps could even be done automatically by Postico, using a predetermined socket path in the app container.

Sequel Ace already supports this and it works great!

[LinusU]

I think that this is the missing piece in order to have the private key stored in 1Password? Would be amazing to have this implemented 🙏

ref: https://developer.1password.com/docs/ssh/agent/compatibility/#postico