Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A sane SSH(1) key management example

try.popho.be

Post reply on HN
Print view View original

41–50 of 69 posts

Re: A sane SSH(1) key management example

#41

Post by dinosaurdynasty »

Quekid5 wrote: post #26
BlackLotus89 wrote: post #23

Earlier quoted context omitted.

If you can generate infinite keys for your car, invalidate old ones and limit the privileges of each key you may think differently. I would love to give the car mechanic a key that only works to drive around the lot or test if it starts.

> invalidate old ones This one is non-trivial in SSH land (unless you go with a CA approach, of course). Lots of authorized_keys files strewn about everywhere...

If you distribute a key revocation list to your servers, it will override anything in anyone's authorized_keys file (on that server of course).

Even with a CA approach (unless the expirations are sufficiently short) you will need to do something like this.

Re: A sane SSH(1) key management example

#42

Post by devonkim »

ashtuchkin wrote: post #33
bityard wrote: post #15

SSH public keys are called public keys because they're totally safe to distribute anywhere. That's rather the entire point of asymmetric cryptography. So I guess I don't really understand the problem being solved here. And yes, I would very much love to have a single key that worked for my house, car, safe deposit box, etc. One that isn't my smart phone, of course.

Privacy. If someone owns two servers you're logging into, they can associate your logins if you use the same key. Another case is associating you with your GitHub account (as your ssh keys there are public)

This is fingerprinting across different identities which is a form of discovery. It’s why I have separate ssh keys for work and personal projects in the first place to better avoid associations across different online identities (with the full understanding that if I’m targeted I’m already against attack vectors that require much more sophisticated defenses). Firstly, for work projects I can give up my private key to my employer as I leave and I won’t care because it was only ever used for work and it would be some reassurance to my colleagues that they can at least access the stuff I used to have access to.

Re: A sane SSH(1) key management example

#44

Post by [deleted] »

BlackLotus89 wrote: post #6

> It’s common knowledge that you shouldn’t put all your eggs in the same basket, but most of the time on IRC or on reddit (or the Internet at large, really), I see people using one single ssh key for all uses. How would you look at someone using a single key for their car, house, safe, work place, and so on? a bit envious tbh. I would be so annoyed if we would get a key fob for every door at work instead of one key f…

[deleted]

Re: A sane SSH(1) key management example

#45

Post by xaduha »

tialaramex wrote: post #40
xaduha wrote: post #24

Earlier quoted context omitted.

Just tried this $ ssh whoami.filippo.io and it prints this You have SSH agent forwarding turned (universally?) on. That is a VERY BAD idea. For example, right now this server has access to your agent and can use your keys however it likes as long as you are connected. ANY SERVER YOU LOG IN TO AND ANYONE WITH ROOT ON THOSE SERVERS CAN LOGIN AS YOU ANYWHERE. but I very much doubt that, because I didn't authorize my sec…

Probably filippo should update this software to notice if the only identities presented were from FIDO authenticators and, if so, modify this message to explain the reduced risk Note that although it's likely yours always requires a presence check (e.g. touch sensor), OpenSSH does not by default tell FIDO authenticators that it insists on UP (User Present) and so they are entitled (but few do since WebAuthn always as…

For something like that to work an attacker would have to add into ~/.ssh/config (on each intermediate server) lines mentioned in another recent post

    ControlMaster        auto
    ControlPath          ~/.ssh/github.sock
    ControlPersist       999999999s
    ServerAliveInterval  0
without me noticing to sort of cache presence check. In which case they have access to my account already and presence or absence of 'ForwardAgent yes' makes no difference since they can add it if they want.

A paranoid answer to that is to use something like /usr/bin/ssh -F /dev/null -A user@fqdn.example.org everytime without an alias, of course. And only plugging in your security key when you need it.

Re: A sane SSH(1) key management example

#46

Post by cassianoleal »

On Macs, Secretive [0] is great. It creates keys in the secret enclave, from where they can't be read, only used for signing requests. TouchID authorisation is optional but it's so quick and easy that I keep it on for all keys.

It can also use Smart Cards (Yubikeys are called out by name in the readme).

A forwarded agent will have the same level of security, meaning that if the forwarded agent needs to use a key in Secretive, it will have to be authorised locally - and even if TouchID is disabled, you are notified if a key is used.

[0] https://github.com/maxgoedjen/secretive/

Re: A sane SSH(1) key management example

#47

Post by e12e »

jph wrote: post #39
joshstrange wrote: post #37

My googling skills are failing me. Can anyone help explain what the "(1)" after SSH means? I guess I always thought it was a footnote marker or something (mainly I just ignored it when I saw it) but I'd love to know what it means.

The (1) means Unix manual pages, section 1. The "ssh(1)" means "read about ssh in man page section 1". Section 1 is for general commands. https://en.wikipedia.org/wiki/Man_page Pages are traditionally referred to using the notation "name(section)": for example, ftp(1). The section refers to different ways the topic might be referenced. 1 General commands 2 System calls 3 Library functions 4 Special files such as devi…

In this case, running "man 1 ssh" is likely the same as "man ssh" (ssh only has a man page in section 1). Many systems will have separate pages for for example "man 1 crontab" and "man 5 crontab".

Re: A sane SSH(1) key management example

#48

Post by tialaramex »

xaduha wrote: post #45
tialaramex wrote: post #40

Earlier quoted context omitted.

Probably filippo should update this software to notice if the only identities presented were from FIDO authenticators and, if so, modify this message to explain the reduced risk Note that although it's likely yours always requires a presence check (e.g. touch sensor), OpenSSH does not by default tell FIDO authenticators that it insists on UP (User Present) and so they are entitled (but few do since WebAuthn always as…

For something like that to work an attacker would have to add into ~/.ssh/config (on each intermediate server) lines mentioned in another recent post ControlMaster auto ControlPath ~/.ssh/github.sock ControlPersist 999999999s ServerAliveInterval 0 without me noticing to sort of cache presence check. In which case they have access to my account already and presence or absence of 'ForwardAgent yes' makes no difference…

Your description is very confusing, either I don't understand your explanation or you misunderstood.

ForwardAgent is a decision for your client, so an attacker's change to some intermediate can't cause your client to set ForwardAgent. Lots of modern SSH users do not have ForwardAgent, at all, it's just not necessary for them, so an intermediate server doesn't have the opportunity to do anything with it.

I also don't see how this is relevant anyway. My point was that although you will probably be asked to touch your FIDO token to authenticate to SSH servers, that's actually not technically the default, cheap tokens figured since WebAuthn is the majority use of FIDO, and since they're allowed to volunteer UP which WebAuthn wants, they can just ignore the UP flag on the request side and always do user presence testing. But the FIDO design does not require this, and so we can't know whether some/ all/ most tokens in say ten years time have this behaviour.

Re: A sane SSH(1) key management example

#49

Post by sbf501 »

tialaramex wrote: post #38
sbf501 wrote: post #7

Earlier quoted context omitted.

The config file already does this, this is just a shortcut with %h and the file system structure. You literally start an entry with "Host " follwed by "User" and "IdentifyFile". There's even a bash autocomplete rule for it so you can tab through your servers "ssh ". It won't send all the keys to the server if you organize this way (which doesn't really matter anyway, since they are PUBLIC KEYS). It resolves to a pref…

> It won't send all the keys to the server if you organize this way (which doesn't really matter anyway, since they are PUBLIC KEYS). Having a public key doesn't teach an observer your private key, and so they can't impersonate you, but it does allow the observer to distinguish you from others. If you would like to prevent observers from correlating identity this way (most famously if you use a public key for GitHub…

> to distinguish you from others

Yeah, that's a good point. The less information that is leaked, the better.

> have overridden that to "Yes" previously and then forgotten.

Another good point. I have this at the start of my macOS config:

    Host *
        IdentitiesOnly Yes
        UseKeychain Yes
Edit: Uh oh, I think I misunderstood something! I'm still seeing nonexisting identify files being tried:

    % ssh -v whoami.filippo.io
    OpenSSH_8.6p1, LibreSSL 3.3.5
    debug1: Reading configuration data /Users/x/.ssh/config
    debug1: /Users/x/.ssh/config line 4: Applying options for whoami.filippo.io
    debug1: /Users/x/.ssh/config line 21: Applying options for \*
    debug1: Reading configuration data /etc/ssh/ssh_config
    debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/\* matched no files
    debug1: /etc/ssh/ssh_config line 54: Applying options for \*
    debug1: /etc/ssh/ssh_config line 58: Applying options for \*
    debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
    debug1: Connecting to whoami.filippo.io port 22.
    debug1: Connection established.
    debug1: identity file /Users/x/.ssh/id_rsa type -1
    debug1: identity file /Users/x/.ssh/id_rsa-cert type -1
    debug1: identity file /Users/x/.ssh/id_dsa type -1
    debug1: identity file /Users/x/.ssh/id_dsa-cert type -1
    debug1: identity file /Users/x/.ssh/id_ecdsa type -1
    debug1: identity file /Users/x/.ssh/id_ecdsa-cert type -1
    debug1: identity file /Users/x/.ssh/id_ecdsa_sk type -1
    debug1: identity file /Users/x/.ssh/id_ecdsa_sk-cert type -1
    debug1: identity file /Users/x/.ssh/id_ed25519 type -1
    :
Even though those don't exist, it is still trying them.

Re: A sane SSH(1) key management example

#50

Post by xaduha »

tialaramex wrote: post #48
xaduha wrote: post #45

Earlier quoted context omitted.

For something like that to work an attacker would have to add into ~/.ssh/config (on each intermediate server) lines mentioned in another recent post ControlMaster auto ControlPath ~/.ssh/github.sock ControlPersist 999999999s ServerAliveInterval 0 without me noticing to sort of cache presence check. In which case they have access to my account already and presence or absence of 'ForwardAgent yes' makes no difference…

Your description is very confusing, either I don't understand your explanation or you misunderstood. ForwardAgent is a decision for your client, so an attacker's change to some intermediate can't cause your client to set ForwardAgent. Lots of modern SSH users do not have ForwardAgent, at all, it's just not necessary for them, so an intermediate server doesn't have the opportunity to do anything with it. I also don't…

What I described there is a current, practical way to bypass subsequent presence checks in my particular security key (Google Titan NFC) which I tried out too.

What you're talking about is that some hardware implementations might be lax about user presence checks which is true, but doesn't affect any particular user (e.g. me) if they know that their key doesn't allow logging in without it.

> so we can't know whether some/ all/ most tokens in say ten years time have this behaviour.

I've used some U2F applets like this one https://github.com/tsenger/CCU2F which bypass presence checks, so yes I'm aware it's not a requirement, but it basically has to be a vulnerability on the hardware/applet level. So I guess don't use NONAME hardware is your advice, is that it?

Post reply on HN