Hacker News Reader

Comment by mfontani | Hacker News Reader

Does it have touch to authorise (doesn't seem to support that), or is it just going to send on all of one's currently-loaded SSH keys whenever one connects with -A (seems to)?

> You can configure your key so that they require Touch ID (or Watch) authentication before they're accessed.

That, to me, would be a key thing to want to have: something that tells me "hey, Terminal just wanted to access your Github key. Is that okay?"

If I'm git pushing, that's fine. If I just connected to a random server... that's not okay. What is that trying to do? Deny.

View on HN

1. with pubkeyauthentication, you don’t send your private key. Your public key, which is stored on the server, is used to encrypt something. You prove you have the corresponding private key by sending back a decrypted version of the something. Attempting to log in to a server, whether they have zero or more of your public keys poses no risk.

2. You can control which private keys are used for which remote server using .ssh/config. You can look up the man page for more.

3. There is a risk of using ssh-sgent key forwarding that while you are connected to a server with key forwarding turned on, a super user sudo to your user and log in to a second host. This risk can be minimized by only enabling key agent forwarding to hosts you trust and limiting the keys available to each host.

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.

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.

> 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.

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.

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

To be clear, that would be a privacy issue (a malicious server could tell what keys you have), but wouldn't allow a malicious server to log in to anything else with your keys. You don't send the private key when you log in.

Note that GP said -A -- this means the agent gets forwarded, and processes on the malicious server can ask the agent to perform authentication operations.

Touch to auth means the agent (or hardware token) asks the user to to confirm they are expecting an authentication request to come in.

This allows you to forward your agent to a host and have slightly more protection against malicious processes on the host using your key.

Github shouldn't ever make any use of -A should it?

Nope. But if you -A to a malicious server it could use your key to push to github.

> random server

use this:

    Host *
      IdentitiesOnly yes

My general understanding is that -A is generally discouraged in the first place: especially when connecting to an untrusted server. But, it just seems to me to be a bad idea to ever let a private key leave your computer. Instead, you should generate a key on the new box and authorize that one somehow (the lowest friction way would be to use an ssh ca to sign the key and then have the servers you want to log into trust only public keys that have been signed by the CA’s key.

-A does not forward your keys to the remote server itself; it "just" lets the remote server make requests to your local SSH agent to sign things. But you that's still sufficient to allow the remote server to sign into things as you without your authorization, so probably not the best of ideas to sign into servers you don't trust with -A.

If you're using -A to log into other machines behind the SSH server (really, the only reason one would use -A), there are now better mechanisms to do that. ProxyJump if the server supports it; port forwarding or ProxyCommand if it doesn't.

Reply on news.ycombinator.com