16 ms·

An SSH server that knows who you are

152 points by tech234a 7y ago

ajphdiv 7y ago
Aside from IdentitiesOnly setting. I assume storing keys outside of ~/.ssh and calling each key via config file or ssh -i would render this useless. Perhaps even a simple bash function to rotate the needed key in/out of .ssh.
- majewsky 7y ago
  You can still store your keys in ~/.ssh as long as you don't use the default file names. By default, ssh will only announce id_rsa, id_dsa, id_ecdsa and id_ed25519. But if your key for GitHub is stored in, say, ~/.ssh/id_github, it won't be offered unless explicitly requested with -i or the IdentityFile config option.
peteretep 7y ago
That’s a neat demo. Am I right to think it’s exceptionally difficult — without local exec access on a machine — to induce a machine to open an ssh connection to an arbitrary host?
- zamadatix 7y ago
  I'm not sure I follow, induce what to open an ssh connection? If you mean the service in question (whoami.filippo.io) it is opening an ssh connection it just displays a message and closes instead of authenticating you and dropping you into a shell. If you mean launch an ssh session from a machine to something in general then yes you have to be able to execute programs on the machine as that's all an ssh client is - another program.
  - tedunangst 7y ago
    I think the question is if it's possible to add <img src=ssh://> to a webpage and have something dumb happen.
    - peteretep 7y ago
      Exactly that, and I'm reasonably sure the answer is no.
      - jrockway 7y ago
        I am sure there is some setup where that will work. Set a URL handler to open Emacs, format the filename as a TRAMP path, something like that. There are plenty of things that try to transparently SSH places, and I'm sure someone has accidentally hooked that into their browser.
- stygiansonic 7y ago
  Probably cannot induce the local machine to connect, but if you enabled agent forwarding, and then connected to a machine, someone who compromised that machine may be able to use your credentials to connect to other SSH servers. Source: https://heipei.io/2015/02/26/SSH-Agent-Forwarding-considered-harmful/ https://heipei.io/2015/02/26/SSH-Agent-Forwarding-considered...
- Thorrez 7y ago
  If you try to SSH into some new machine that you own, someone can redirect your request to an attacker's machine (via DNS attacks or MITM), and since it's a new machine, it won't be in your known_hosts file, so it will prompt if you want to trust this machine and 99% of people will say yes.
  - dependenttypes 7y ago
    openssh makes the situation worse because if the key is already in your host file and it's just the ip/domain that changed it will not tell you that it recognises the key.
    - rekoil 7y ago
      I mean, if a mitm has your SSH server key, chances are you are screwed anyway.
      - dependenttypes 7y ago
        In the case which I am describing nobody other than you has your key.
        rekoil 7y ago
        But the key you are talking about the SSH client recognising is the server key right? Or did you mean after authorising your SSH client to connect to the unknown machine, and the key you were talking about was the identity public key? I ask because the thread you commented on was discussing users not looking carefully which servers they connect to when connecting to new servers, and that is based on the SSH servers key, not your identity key, which is why I said that if someone who is able to redirect your SSH connection to a different server also owns the correct servers SSH server key (as you said "just the ip/domain that changed"), then there isn't much the client can do to help keep you safe anyway.
        dependenttypes 7y ago
jffry 7y ago
Discussed four and a half years ago, albeit the Tweet mentions having a new source of data: https://news.ycombinator.com/item?id=10004678 https://news.ycombinator.com/item?id=10004678 The top-rated comment mentioning having an "IdentitiesOnly yes" setting in your ~/.ssh/config is still relevant if you want to have multiple SSH keys and ensure that only specific hosts get specific keys. EDIT: Also link is to a retweet, the source tweet is https://twitter.com/FiloSottile/status/1229093553269362689 https://twitter.com/FiloSottile/status/1229093553269362689
exabrial 7y ago
I thought this was pretty obvious.... but ok, so don't ssh places you're not supposed to?
- kanox 7y ago
  Why is this obvious? I don't know much about crypto but I'd imagine it's possible for an protocol to not reveal the identity of the authenticating party. For example a server can send a challenge which requires knowledge of the private key to solve but does not reveal anything from the client on failure. If the server has multiple authorized_keys it could just send multiple challenges and accept a reply for any of them. Am I missing something? This seems like a nice privacy feature.
  - vore 7y ago
    If you don't know the identity of the authenticating party, how does the authenticating party log in to their account?
    - saagarjha 7y ago
      They tell you which account they want to log in as, which isn't necessarily their global identity they'd like to share with you.
      - kanox 7y ago
        Exactly: you wouldn't be able to ssh git@github.com/repo/proj but rather have to use user@github.com/proj/repo and this would be better.
- untog 7y ago
  I really don’t think there’s anything obvious about the fact that logging into an SSH server also exposes other login information stored in your computer. Given that creating a Github account is one of the first things beginner devs are guided towards it’s worth keeping such beginners in mind. And it’s not so much “places you’re not supposed to” as “places you know haven’t been compromised in any way”, which is difficult to know unless you’re the sysadmin.
dependenttypes 7y ago
In theory there is a way to do it without needing to have IdentitiesOnly yes. That is, if ssh did something like: server -> user: nonce user -> server: nonce2, h(nonce || nonce2 || publickey) (for every publickey) or alternatively user -> server: nonce server -> user: nonce2, h(nonce || nonce2 || publickey) (for every publickey) It would still leak the amount of keys (for the user for the 1st protocol and for the server for the second) but nothing about them. (I would also suggest using a modern hash function for h, such as blake(2) or sha3) There should be a way to extend this protocol as to not leak the amount of keys.
- dependenttypes 7y ago
  this will actually not work. this is why you should not make your own crypto protocols in production if you are not an expert and/or if you have not proven them correct.
- fazilakhtar 7y ago
  Look at kssh (Keybase SSH)
femto113 7y ago
The availability of developers' keys on github can be quite useful, a few jobs ago I leveraged this to auto-provision ssh bastion hosts with public keys for all of the collaborators of a repo. Much easier than getting people to send them to you and add them to authorized keys by hand. https://gist.github.com/femto113/ef9162d670def84b3c684d2d30588037 https://gist.github.com/femto113/ef9162d670def84b3c684d2d305...
leowoo91 7y ago
I wonder how does it match my public key at github? Does it use a popular accounts index, or maybe he crawled a bit?
- guessmyname 7y ago
  > I wonder how does it match my public key at github? > Does it use a popular accounts index, or maybe he crawled a bit? Ben Cartwright-Cox (aka. benjojo) [1] crawled many “github.com/USERNAME.keys” some time ago [2]. Filippo, being colleagues, probably asked for a copy of his database to run this experiment. For example, here are the public SSH keys Linus Torvalds uses on GitHub [3]. [1] https://github.com/benjojo https://github.com/benjojo [2] https://blog.benjojo.co.uk/post/auditing-github-users-keys https://blog.benjojo.co.uk/post/auditing-github-users-keys [3] https://github.com/torvalds.keys https://github.com/torvalds.keys
deleted 7y ago
[deleted]
stormbeard 7y ago
Can somebody comment on why the exposure of public keys is a problem?
- guessmyname 7y ago
  > Can somebody comment on why the exposure of public keys is a problem? It is not, it just makes you identifiable. Public SSH keys are… well, public.

152 points by tech234a 7y ago

Aside from IdentitiesOnly setting. I assume storing keys outside of ~/.ssh and calling each key via config file or ssh -i would render this useless. Perhaps even a simple bash function to rotate the needed key in/out of .ssh.

majewsky 7y ago
You can still store your keys in ~/.ssh as long as you don't use the default file names. By default, ssh will only announce id_rsa, id_dsa, id_ecdsa and id_ed25519. But if your key for GitHub is stored in, say, ~/.ssh/id_github, it won't be offered unless explicitly requested with -i or the IdentityFile config option.

peteretep 7y ago

That’s a neat demo. Am I right to think it’s exceptionally difficult — without local exec access on a machine — to induce a machine to open an ssh connection to an arbitrary host?

zamadatix 7y ago
I'm not sure I follow, induce what to open an ssh connection? If you mean the service in question (whoami.filippo.io) it is opening an ssh connection it just displays a message and closes instead of authenticating you and dropping you into a shell. If you mean launch an ssh session from a machine to something in general then yes you have to be able to execute programs on the machine as that's all an ssh client is - another program.
- tedunangst 7y ago
  I think the question is if it's possible to add <img src=ssh://> to a webpage and have something dumb happen.
  - peteretep 7y ago
    Exactly that, and I'm reasonably sure the answer is no.
    - jrockway 7y ago
      I am sure there is some setup where that will work. Set a URL handler to open Emacs, format the filename as a TRAMP path, something like that. There are plenty of things that try to transparently SSH places, and I'm sure someone has accidentally hooked that into their browser.
stygiansonic 7y ago
Probably cannot induce the local machine to connect, but if you enabled agent forwarding, and then connected to a machine, someone who compromised that machine may be able to use your credentials to connect to other SSH servers. Source: https://heipei.io/2015/02/26/SSH-Agent-Forwarding-considered-harmful/ https://heipei.io/2015/02/26/SSH-Agent-Forwarding-considered...
Thorrez 7y ago
If you try to SSH into some new machine that you own, someone can redirect your request to an attacker's machine (via DNS attacks or MITM), and since it's a new machine, it won't be in your known_hosts file, so it will prompt if you want to trust this machine and 99% of people will say yes.
- dependenttypes 7y ago
  openssh makes the situation worse because if the key is already in your host file and it's just the ip/domain that changed it will not tell you that it recognises the key.
  - rekoil 7y ago
    I mean, if a mitm has your SSH server key, chances are you are screwed anyway.
    - dependenttypes 7y ago
      In the case which I am describing nobody other than you has your key.
      - rekoil 7y ago
        But the key you are talking about the SSH client recognising is the server key right? Or did you mean after authorising your SSH client to connect to the unknown machine, and the key you were talking about was the identity public key? I ask because the thread you commented on was discussing users not looking carefully which servers they connect to when connecting to new servers, and that is based on the SSH servers key, not your identity key, which is why I said that if someone who is able to redirect your SSH connection to a different server also owns the correct servers SSH server key (as you said "just the ip/domain that changed"), then there isn't much the client can do to help keep you safe anyway.
        dependenttypes 7y ago

jffry 7y ago

Discussed four and a half years ago, albeit the Tweet mentions having a new source of data: https://news.ycombinator.com/item?id=10004678 https://news.ycombinator.com/item?id=10004678 The top-rated comment mentioning having an "IdentitiesOnly yes" setting in your ~/.ssh/config is still relevant if you want to have multiple SSH keys and ensure that only specific hosts get specific keys. EDIT: Also link is to a retweet, the source tweet is https://twitter.com/FiloSottile/status/1229093553269362689 https://twitter.com/FiloSottile/status/1229093553269362689

exabrial 7y ago

I thought this was pretty obvious.... but ok, so don't ssh places you're not supposed to?

kanox 7y ago
Why is this obvious? I don't know much about crypto but I'd imagine it's possible for an protocol to not reveal the identity of the authenticating party. For example a server can send a challenge which requires knowledge of the private key to solve but does not reveal anything from the client on failure. If the server has multiple authorized_keys it could just send multiple challenges and accept a reply for any of them. Am I missing something? This seems like a nice privacy feature.
- vore 7y ago
  If you don't know the identity of the authenticating party, how does the authenticating party log in to their account?
  - saagarjha 7y ago
    They tell you which account they want to log in as, which isn't necessarily their global identity they'd like to share with you.
    - kanox 7y ago
      Exactly: you wouldn't be able to ssh git@github.com/repo/proj but rather have to use user@github.com/proj/repo and this would be better.
untog 7y ago
I really don’t think there’s anything obvious about the fact that logging into an SSH server also exposes other login information stored in your computer. Given that creating a Github account is one of the first things beginner devs are guided towards it’s worth keeping such beginners in mind. And it’s not so much “places you’re not supposed to” as “places you know haven’t been compromised in any way”, which is difficult to know unless you’re the sysadmin.

dependenttypes 7y ago

In theory there is a way to do it without needing to have IdentitiesOnly yes. That is, if ssh did something like: server -> user: nonce user -> server: nonce2, h(nonce || nonce2 || publickey) (for every publickey) or alternatively user -> server: nonce server -> user: nonce2, h(nonce || nonce2 || publickey) (for every publickey) It would still leak the amount of keys (for the user for the 1st protocol and for the server for the second) but nothing about them. (I would also suggest using a modern hash function for h, such as blake(2) or sha3) There should be a way to extend this protocol as to not leak the amount of keys.

dependenttypes 7y ago
this will actually not work. this is why you should not make your own crypto protocols in production if you are not an expert and/or if you have not proven them correct.
fazilakhtar 7y ago
Look at kssh (Keybase SSH)

femto113 7y ago

The availability of developers' keys on github can be quite useful, a few jobs ago I leveraged this to auto-provision ssh bastion hosts with public keys for all of the collaborators of a repo. Much easier than getting people to send them to you and add them to authorized keys by hand. https://gist.github.com/femto113/ef9162d670def84b3c684d2d30588037 https://gist.github.com/femto113/ef9162d670def84b3c684d2d305...

leowoo91 7y ago

I wonder how does it match my public key at github? Does it use a popular accounts index, or maybe he crawled a bit?

guessmyname 7y ago
> I wonder how does it match my public key at github? > Does it use a popular accounts index, or maybe he crawled a bit? Ben Cartwright-Cox (aka. benjojo) [1] crawled many “github.com/USERNAME.keys” some time ago [2]. Filippo, being colleagues, probably asked for a copy of his database to run this experiment. For example, here are the public SSH keys Linus Torvalds uses on GitHub [3]. [1] https://github.com/benjojo https://github.com/benjojo [2] https://blog.benjojo.co.uk/post/auditing-github-users-keys https://blog.benjojo.co.uk/post/auditing-github-users-keys [3] https://github.com/torvalds.keys https://github.com/torvalds.keys

deleted 7y ago

[deleted]

stormbeard 7y ago

Can somebody comment on why the exposure of public keys is a problem?

guessmyname 7y ago
> Can somebody comment on why the exposure of public keys is a problem? It is not, it just makes you identifiable. Public SSH keys are… well, public.