6 ms·

In my honest opinion, delegating the trust model down to the user to figure out which host key is trusted or not is the broken model. I always blindly accept th

by h1d 8y ago

In my honest opinion, delegating the trust model down to the user to figure out which host key is trusted or not is the broken model. I always blindly accept the key because I have no way of knowing what is good or bad by looking at the prompt with random letters telling me it could be bad and in my life 100% of those alerts are false positives and I got used to accepting those alerts.

Kovah 8y ago
Could someone elaborate on how to find out the correct key of a host that was recently setup, like a new Digitalocean instance? Is there even a method?
- tedunangst 8y ago
  Does your cloud dashboard not tell you? Last resort, login on console and look at it.
- detaro 8y ago
  You can provide a pregenerated key to the instance during setup, e.g. using cloud-init. Or supply it with a way to report its key once it is generated. Or use out-of-band access, e.g. a host-provided console, to connect once and extract the key.
  - amelius 8y ago
    Ok, but shouldn't ssh require the user to type in the entire key then, rather than to type yes/no?
    - detaro 8y ago
      Why?/How does that relate to my answer? It'd make it harder to just accept a changed key instead of leaving the decision to the user, and would make use cases where the user doesn't want/need to authenticate the server harder (one can probably debate each scenario for that if the decision to not authenticate was "right"). Although I find it a bit weird there's not even an option to pass a host key to SSH instead of editing the KnownHosts file.
    - nothrabannosir 8y ago
      Yes, the SSH flow is completely broken and, therefore, in reality only really protects against passive snooping. I have never met a real human, in real life, who ever checked the host key on first connect. For what it’s worth: The way to solve this is require the host key fingerprint as an argument to the ssh command, along with host and user. This would force people to look it up. This is not a popular opinion, but I think it’s inescapable: SSH was not made for humans. (This is purely a client issue, by the way. But at the end of the day: does that matter for anyone?) (Edit: when this comes up people often mention key based auth. Unfortunately, that relies on nobody else having your public key. You can find mine anywhere, it used to be available through the GitHub api , even. It won’t let the attacker connect to the original server but they can definitely impersonate it. Perhaps get your key agent forwarded, and continue. Not great.)
      - aaronmdjones 8y ago
        No, the way to solve this is to use client public key authentication. Then a successful MITM will require the client's private key too.
        nothrabannosir 8y ago
        No, it will only require the public key (which is public) to impersonate the server. It won’t be a MITM but it’s still bad; see e.g. the bug in this very article, or if (god forbid) you’ve set up agent forwarding. Or if you do e.g. a git pull from github on a fresh comp, it can serve you bad code. Asymmetric key is not a solution to the problem of users blindly trusting hosts without checking the fingerprint. It’s a UI problem. Every time I bring this up it gets shot down (e.g. now -3 votes), and every time I wait for someone to put forward an actual counter argument. Unfortunately, no luck. SSH is broken and it needs fixing.
        fwip 8y ago
        I'm not sure you know how public/private keys work.
- jsiepkes 8y ago
  You can use SSHFP records in DNS. Clients like OpenSSH can be configured to retrieve and use those.
  - vthriller 8y ago
    Aaand we've returned to discussions about hacks designed to make DNS at least somewhat trustful.
- eslaught 8y ago
  It gets printed to the console by default when you run cloud-init, and e.g. in AWS you can retrieve the console logs with an API call and grep for what you want. I've got a script sitting around here somewhere which does this... Not necessarily in a state that's easy to reuse, of course.
  - __david__ 8y ago
    It doesn't work if your cloud init prints too much. AWS only holds a certain amount and the so the API call will truncate the output and lose the key (it shows you the tail and not the head of I remember correctly). Our organization has this problem (we run puppet in cloud init which spews like crazy). I did notice recently that cloud init has an option to hot a web hook when it is complete and they have options in there to add the host key to the POST. But I wonder how to make a web hook that would be immune to spoofing…
- tombrossman 8y ago
  Yes, it is probably in /etc/ssh/. What type of key depends on your distro and version, but here is a helpful explanation for Ubuntu: https://askubuntu.com/a/76388 https://askubuntu.com/a/76388
jstanley 8y ago
> I always blindly accept the key Even from a host you use all the time and where know the key hasn't changed?
- toyg 8y ago
  "Frack knows what all dem Gilfoyles do all the time. I have shit to do." <accepts>
Ayesh 8y ago
There is a DNS SSHFP record type that the history can publish the host keys. I wrote about them some time back: https://ayesh.me/sshfp-verification https://ayesh.me/sshfp-verification For servers without a domain pointed to it, I suppose you can still verify them by comparing the history key fingerprint by logging into said server with the console provided by server vendor.
- gruez 8y ago
  And how do you trust that the dns record hasn’t been tampered with? DNSSEC?
  - xoa 8y ago
    The article mentions DNSSEC, but is that a limiting factor in this case? If you are connecting to a server you specifically have out of band access to then just use pre-shared keys like normal and none of this is relevant. If you don't and DNS is compromised then you're depending on DNS anyway right? At that point getting the host pubkey from DNS too doesn't seem like it hurts anything and it could still defend against MITM if the chain from you to DNS is different then you to the server (not uncommon I'd think, since a lot of people are either using their local resolver, using their ISP's at 1 hop, or using someone distributed like Cloudflare who are also minimal hops). Of course authentic secure DNS is really important anyway, and worth working on. Beyond DNSSEC there is also DNS over HTTPS. And just using shared keys and nothing else, no option to even accept if it changes, is best of all. But if that doesn't work for whatever reason having it in DNS doesn't seem like an awful idea, anymore then Let's Encrypt depending on DNS does right?
    - tptacek 8y ago
      Authentic secure DNS is in fact not important, and is not worth working on. I think the lengths you had to go to just now to establish some kind of marginal value for SSHFP is a good illustration of why. And that's because we've designed protocols for the past 20 years to assume the DNS is insecure. SSH, in particular, has "don't trust DNS" baked into its DNA; it's a response to the old Unix r-commands, which did trust DNS.
m45t3r 8y ago
SSH saves the host identification in .known_hosts file. So after the first connection (that asks you if you know this key, and sure, nobody verifies it) you known for sure that this is the server that you want to connect. If after all that you receive a message an error from SSH that the host key identification changed, you didn't change this key yourself (or your team) and you still blindly ignore this issue (since it is not easy to bypass either, there is no flag, for example), this is not an UI issue and you're responsible for your actions.

by h1d 8y ago

Kovah 8y ago

Could someone elaborate on how to find out the correct key of a host that was recently setup, like a new Digitalocean instance? Is there even a method?

tedunangst 8y ago
Does your cloud dashboard not tell you? Last resort, login on console and look at it.
detaro 8y ago
You can provide a pregenerated key to the instance during setup, e.g. using cloud-init. Or supply it with a way to report its key once it is generated. Or use out-of-band access, e.g. a host-provided console, to connect once and extract the key.
- amelius 8y ago
  Ok, but shouldn't ssh require the user to type in the entire key then, rather than to type yes/no?
  - detaro 8y ago
    Why?/How does that relate to my answer? It'd make it harder to just accept a changed key instead of leaving the decision to the user, and would make use cases where the user doesn't want/need to authenticate the server harder (one can probably debate each scenario for that if the decision to not authenticate was "right"). Although I find it a bit weird there's not even an option to pass a host key to SSH instead of editing the KnownHosts file.
  - nothrabannosir 8y ago
    Yes, the SSH flow is completely broken and, therefore, in reality only really protects against passive snooping. I have never met a real human, in real life, who ever checked the host key on first connect. For what it’s worth: The way to solve this is require the host key fingerprint as an argument to the ssh command, along with host and user. This would force people to look it up. This is not a popular opinion, but I think it’s inescapable: SSH was not made for humans. (This is purely a client issue, by the way. But at the end of the day: does that matter for anyone?) (Edit: when this comes up people often mention key based auth. Unfortunately, that relies on nobody else having your public key. You can find mine anywhere, it used to be available through the GitHub api , even. It won’t let the attacker connect to the original server but they can definitely impersonate it. Perhaps get your key agent forwarded, and continue. Not great.)
    - aaronmdjones 8y ago
      No, the way to solve this is to use client public key authentication. Then a successful MITM will require the client's private key too.
      - nothrabannosir 8y ago
        No, it will only require the public key (which is public) to impersonate the server. It won’t be a MITM but it’s still bad; see e.g. the bug in this very article, or if (god forbid) you’ve set up agent forwarding. Or if you do e.g. a git pull from github on a fresh comp, it can serve you bad code. Asymmetric key is not a solution to the problem of users blindly trusting hosts without checking the fingerprint. It’s a UI problem. Every time I bring this up it gets shot down (e.g. now -3 votes), and every time I wait for someone to put forward an actual counter argument. Unfortunately, no luck. SSH is broken and it needs fixing.
        fwip 8y ago
        I'm not sure you know how public/private keys work.
jsiepkes 8y ago
You can use SSHFP records in DNS. Clients like OpenSSH can be configured to retrieve and use those.
- vthriller 8y ago
  Aaand we've returned to discussions about hacks designed to make DNS at least somewhat trustful.
eslaught 8y ago
It gets printed to the console by default when you run cloud-init, and e.g. in AWS you can retrieve the console logs with an API call and grep for what you want. I've got a script sitting around here somewhere which does this... Not necessarily in a state that's easy to reuse, of course.
- __david__ 8y ago
  It doesn't work if your cloud init prints too much. AWS only holds a certain amount and the so the API call will truncate the output and lose the key (it shows you the tail and not the head of I remember correctly). Our organization has this problem (we run puppet in cloud init which spews like crazy). I did notice recently that cloud init has an option to hot a web hook when it is complete and they have options in there to add the host key to the POST. But I wonder how to make a web hook that would be immune to spoofing…
tombrossman 8y ago
Yes, it is probably in /etc/ssh/. What type of key depends on your distro and version, but here is a helpful explanation for Ubuntu: https://askubuntu.com/a/76388 https://askubuntu.com/a/76388

jstanley 8y ago

> I always blindly accept the key Even from a host you use all the time and where know the key hasn't changed?

toyg 8y ago
"Frack knows what all dem Gilfoyles do all the time. I have shit to do." <accepts>

Ayesh 8y ago

There is a DNS SSHFP record type that the history can publish the host keys. I wrote about them some time back: https://ayesh.me/sshfp-verification https://ayesh.me/sshfp-verification For servers without a domain pointed to it, I suppose you can still verify them by comparing the history key fingerprint by logging into said server with the console provided by server vendor.

gruez 8y ago
And how do you trust that the dns record hasn’t been tampered with? DNSSEC?
- xoa 8y ago
  The article mentions DNSSEC, but is that a limiting factor in this case? If you are connecting to a server you specifically have out of band access to then just use pre-shared keys like normal and none of this is relevant. If you don't and DNS is compromised then you're depending on DNS anyway right? At that point getting the host pubkey from DNS too doesn't seem like it hurts anything and it could still defend against MITM if the chain from you to DNS is different then you to the server (not uncommon I'd think, since a lot of people are either using their local resolver, using their ISP's at 1 hop, or using someone distributed like Cloudflare who are also minimal hops). Of course authentic secure DNS is really important anyway, and worth working on. Beyond DNSSEC there is also DNS over HTTPS. And just using shared keys and nothing else, no option to even accept if it changes, is best of all. But if that doesn't work for whatever reason having it in DNS doesn't seem like an awful idea, anymore then Let's Encrypt depending on DNS does right?
  - tptacek 8y ago
    Authentic secure DNS is in fact not important, and is not worth working on. I think the lengths you had to go to just now to establish some kind of marginal value for SSHFP is a good illustration of why. And that's because we've designed protocols for the past 20 years to assume the DNS is insecure. SSH, in particular, has "don't trust DNS" baked into its DNA; it's a response to the old Unix r-commands, which did trust DNS.

m45t3r 8y ago

SSH saves the host identification in .known_hosts file. So after the first connection (that asks you if you know this key, and sure, nobody verifies it) you known for sure that this is the server that you want to connect. If after all that you receive a message an error from SSH that the host key identification changed, you didn't change this key yourself (or your team) and you still blindly ignore this issue (since it is not easy to bypass either, there is no flag, for example), this is not an UI issue and you're responsible for your actions.