4 ms·

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, un

by xaduha 4y ago

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.

moviuro 4y ago
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-agent-forwarding https://docs.github.com/en/developers/overview/using-ssh-age...
- xaduha 4y ago
  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.
  - BlackLotus89 4y ago
    > 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.
    - xaduha 4y ago
      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.
      - BlackLotus89 4y ago
        Ah "security key" as in hardware token. Sorry thought you were referencing to your key file and not your usb-key. Misunderstanding that's all :)
  - tialaramex 4y ago
    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 asks for UP) to allow the signature to proceed immediately without a presence check so long as they don't set the UP bitflag in their signed response. I think Fillipo's server can tell the client "I want UP" to check this, but I'm not sure and if few people do that I bet somebody already made a client which gets it wrong. [[ Because the flags are signed, even though UP is a single bit flag you can't forge it ]]
    - xaduha 4y ago
      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.
      - tialaramex 4y ago
        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.
schaefer 4y ago
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?
- xaduha 4y ago
  If you have Yubikey, then this is fine https://xeiaso.net/blog/yubikey-ssh-key-storage 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 https://github.com/philipWendland/IsoApplet which uses https://en.wikipedia.org/wiki/PKCS_11 https://en.wikipedia.org/wiki/PKCS_11 standard, but modern way is much smoother as long as your OpenSSH server is up to date.
  - rgoulter 4y ago
    FWIW, the method in that xeiaso link (using resident keys on a security key) can be done with the cheaper "Security Keys" from Yubico, and doesn't need the more expensive Yubikey. -- The cheaper security key can be used as a FIDO key as 2FA for many websites; or even for stuff like Linux login.

by xaduha 4y ago

moviuro 4y ago

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-agent-forwarding https://docs.github.com/en/developers/overview/using-ssh-age...

xaduha 4y ago
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.
- BlackLotus89 4y ago
  > 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.
  - xaduha 4y ago
    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.
    - BlackLotus89 4y ago
      Ah "security key" as in hardware token. Sorry thought you were referencing to your key file and not your usb-key. Misunderstanding that's all :)
- tialaramex 4y ago
  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 asks for UP) to allow the signature to proceed immediately without a presence check so long as they don't set the UP bitflag in their signed response. I think Fillipo's server can tell the client "I want UP" to check this, but I'm not sure and if few people do that I bet somebody already made a client which gets it wrong. [[ Because the flags are signed, even though UP is a single bit flag you can't forge it ]]
  - xaduha 4y ago
    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.
    - tialaramex 4y ago
      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.

schaefer 4y ago

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?

xaduha 4y ago
If you have Yubikey, then this is fine https://xeiaso.net/blog/yubikey-ssh-key-storage 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 https://github.com/philipWendland/IsoApplet which uses https://en.wikipedia.org/wiki/PKCS_11 https://en.wikipedia.org/wiki/PKCS_11 standard, but modern way is much smoother as long as your OpenSSH server is up to date.
- rgoulter 4y ago
  FWIW, the method in that xeiaso link (using resident keys on a security key) can be done with the cheaper "Security Keys" from Yubico, and doesn't need the more expensive Yubikey. -- The cheaper security key can be used as a FIDO key as 2FA for many websites; or even for stuff like Linux login.