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

21–30 of 69 posts

Re: A sane SSH(1) key management example

#21

Post by moviuro »

xaduha wrote: post #16

My ~/.ssh/config has one line: ForwardAgent yes My public keys are in my dotfiles repo and my private keys were in hardware security keys/cards since 2016, unextractable. I don't see any reason to do what this post is suggesting and in my opinion a post about SSH keys without advising to use security keys (which you also can use for 2FA) is a bit retrograde.

GitHub advises against this[0]:

> You may be tempted to use a wildcard like `Host *` to just apply [ForwardAgent yes] to all SSH connections. That's not really a good idea, as you'd be sharing your local SSH keys with every server you SSH into. They won't have direct access to the keys, but they will be able to use them as you while the connection is established.

[0] https://docs.github.com/en/developers/overview/using-ssh-age...

Re: A sane SSH(1) key management example

#22

Post by schaefer »

xaduha wrote: post #16

My ~/.ssh/config has one line: ForwardAgent yes My public keys are in my dotfiles repo and my private keys were in hardware security keys/cards since 2016, unextractable. I don't see any reason to do what this post is suggesting and in my opinion a post about SSH keys without advising to use security keys (which you also can use for 2FA) is a bit retrograde.

Can you point to any existing write ups that are more in line with your methodology, for those of us that want to dig in and give it a try?

Re: A sane SSH(1) key management example

#23

Post by BlackLotus89 »

qwertox wrote: post #20
1970-01-01 wrote: post #17

>How would you look at someone using a single key for their car, house, safe, work place, and so on? One key to rule them all? Honestly, I would be jealous.

Sure, but as soon as you've got to leave the car key at the shop for the car inspection, you might rethink that approach.

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.

Re: A sane SSH(1) key management example

#24

Post by xaduha »

moviuro wrote: post #21
xaduha wrote: post #16

My ~/.ssh/config has one line: ForwardAgent yes My public keys are in my dotfiles repo and my private keys were in hardware security keys/cards since 2016, unextractable. I don't see any reason to do what this post is suggesting and in my opinion a post about SSH keys without advising to use security keys (which you also can use for 2FA) is a bit retrograde.

GitHub advises against this[0]: > You may be tempted to use a wildcard like `Host *` to just apply [ForwardAgent yes] to all SSH connections. That's not really a good idea, as you'd be sharing your local SSH keys with every server you SSH into. They won't have direct access to the keys, but they will be able to use them as you while the connection is established. [0] https://docs.github.com/en/developers/overview/usi…

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 security key to log into this server, never mind any other afterwards.

Re: A sane SSH(1) key management example

#25

Post by xaduha »

schaefer wrote: post #22
xaduha wrote: post #16

My ~/.ssh/config has one line: ForwardAgent yes My public keys are in my dotfiles repo and my private keys were in hardware security keys/cards since 2016, unextractable. I don't see any reason to do what this post is suggesting and in my opinion a post about SSH keys without advising to use security keys (which you also can use for 2FA) is a bit retrograde.

Can you point to any existing write ups that are more in line with your methodology, for those of us that want to dig in and give it a try?

If you have Yubikey, then this is fine https://xeiaso.net/blog/yubikey-ssh-key-storage. I have Google Titan NFC which is basically Feitian K9 NFC, so it doesn't support -O resident.

Back in 2016 I was using https://github.com/philipWendland/IsoApplet which uses https://en.wikipedia.org/wiki/PKCS_11 standard, but modern way is much smoother as long as your OpenSSH server is up to date.

Re: A sane SSH(1) key management example

#26

Post by Quekid5 »

BlackLotus89 wrote: post #23
qwertox wrote: post #20

Earlier quoted context omitted.

Sure, but as soon as you've got to leave the car key at the shop for the car inspection, you might rethink that approach.

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

Re: A sane SSH(1) key management example

#27

Post by blfr »

Yeah, I use different keys for different purposes/projects but not for each and every server. Sounds inconvenient.

Plus how would only one of my ssh keys leak when I store them all in the same place? If I was worried about my keys leaking, I would rather do the YubiKey voodoo and keep my keys there.

But, again, once someone (persistently) compromises my main laptop, it's game over anyway.

Re: A sane SSH(1) key management example

#28

Post by tmottabr »

qwertox wrote: post #20
1970-01-01 wrote: post #17

>How would you look at someone using a single key for their car, house, safe, work place, and so on? One key to rule them all? Honestly, I would be jealous.

Sure, but as soon as you've got to leave the car key at the shop for the car inspection, you might rethink that approach.

there are facier cars that have a valet key that only open the driver door and start the engine..

I guess a similar solution could be implemented for a mechanical shop key..

Re: A sane SSH(1) key management example

#29

Post by BlackLotus89 »

xaduha wrote: post #24
moviuro wrote: post #21

Earlier quoted context omitted.

GitHub advises against this[0]: > You may be tempted to use a wildcard like `Host *` to just apply [ForwardAgent yes] to all SSH connections. That's not really a good idea, as you'd be sharing your local SSH keys with every server you SSH into. They won't have direct access to the keys, but they will be able to use them as you while the connection is established. [0] https://docs.github.com/en/developers/overview/usi…

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…

> but I very much doubt that, because I didn't authorize my security key to log into this server, never mind any other afterwards.

What? This server pulls your public key from github and allows your client to connect to it. If you have forwarding turned on this server can INDEED connect to every server you are connected to.

Re: A sane SSH(1) key management example

#30

Post by xaduha »

BlackLotus89 wrote: post #29
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…

> but I very much doubt that, because I didn't authorize my security key to log into this server, never mind any other afterwards. What? This server pulls your public key from github and allows your client to connect to it. If you have forwarding turned on this server can INDEED connect to every server you are connected to.

No it cannot, not until I touch my security key. I'm not a novice in these matters and I just tested it again.

To connect to one server I have to touch my security key and then to connect to another one from it immediately afterwards I need to touch my security key again. Otherwise nothing happens and it just times out.

Even when using something like ssh -J user@server1 user@server2 I need to touch it two separate times.

Post reply on HN