Hacker News Reader

Comment by Metus | Hacker News Reader

After researching this for a while, it seems there is no documented, native option to do this. The only option is to unlock all SSH keys all the time, which makes them less secure than the passwords for websites managed by the exact same keychain. Which, in my opinion, is weird.

Do they employees at Apple use a different system altogether? Because the built-in one doesn't seem very secure. Or maybe I am using it wrong, who knows.

In a similar vein, is there an exhaustive manual for macOS? It bugs me that Apple machines cost a small fortune, the OS is full of nifty features, but there is no non-superficial manual shipped with it.

View on HN

> which makes them less secure than the passwords for websites managed by the exact same keychain

That's NOT true. While giving out less information to untrusted parties is obviously better than more, the private key itself is not transmitted directly to the server. This means that connecting to an attacker's SSH server doesn't give them a copy of your private key, so they can't then connect to your SSH servers.

The scenario here is with -A (agent forwarding). This means as long as you’re connected to a server with that enabled, that server can auth as you to a bunch of other stuff by having your client do it silently.

In regards to the ssh-agent stuff (and a lot of the other CLI tricks), the man pages usually document them. They may lag a bit for new features, but most of them will have a man page. Barring that they’ll usually print a help message.

One command off the top of my head that doesn’t really follow this is the undocumented/internal `airport` command. In that case it has two different help messages depending on how it’s called, and is also tucked away in a framework as well.

You used to be able to have multiple keychain files in keychain so you could create another one which doesn't unlock at login which you keep for more securerer stuff?

Ya I’ve done this before so I know it’s possible. The Mac keychain will even auto-lock the chains it can lock

There is a native way in .ssh/config. I just added a reply to a different post.

That only restricts the blast radius to one key.

One is unawares of when, how, and for what purposes that key is used - as forwarding the key means it's available for use by any user process (as the mechanism behind the forwarding is user-owned) or root (as root can see everything).

Touch-to-authorize helps mitigate that.

If one seees the prompt come up when they've just performed a git pull, it's expected and likely non-malicious. Allow.

If it pops up after having ran "ls" or "randomly" in the course of a session - what's going on? Deny.

You are correct. Touch to authorize is lower risk. I don’t know a way to do that natively. Sorry if I misunderstood.

Reply on news.ycombinator.com