4 ms·

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 mak

by Metus 6y ago

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.

paxswill 6y ago
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.
fragmede 6y ago
> 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.
- kortilla 6y ago
  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.
deleted 6y ago
[deleted]
Hnrobert42 6y ago
There is a native way in .ssh/config. I just added a reply to a different post.
- mfontani 6y ago
  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.
  - Hnrobert42 6y ago
    You are correct. Touch to authorize is lower risk. I don’t know a way to do that natively. Sorry if I misunderstood.
willyt 6y ago
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?
- stepstop 6y ago
  Ya I’ve done this before so I know it’s possible. The Mac keychain will even auto-lock the chains it can lock

by Metus 6y ago

paxswill 6y ago

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.

fragmede 6y ago

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

kortilla 6y ago
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.

deleted 6y ago

[deleted]

Hnrobert42 6y ago

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

mfontani 6y ago
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.
- Hnrobert42 6y ago
  You are correct. Touch to authorize is lower risk. I don’t know a way to do that natively. Sorry if I misunderstood.

willyt 6y ago

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?

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