4 ms·

This isn’t a technical security vulnerability, because the cryptography is sound. But it is an information disclosure vulnerability, because it didn’t need to

This isn’t a technical security vulnerability, because the cryptography is sound. But it is an information disclosure vulnerability, because it didn’t need to disclose your identity, and the typical user will not expect it to disclose all their identities. And the information that is disclosed opens heavy social vulnerabilities, because your activity can now be perfectly correlated with who you are, by an untrusted party. This is information that businesses put huge amounts of effort into attempting to do on the web, because it can be quite valuable (sometimes absurdly so). And SSH defaults to just giving them exactly what they want so they don’t even have to work for it.

wootland 4y ago
Do you feel the same way about GitHub/GitLab... because Git works over SSH and anytime you clone anything over the SSH protocol your public keys are sent to the server. Same thing with SSHing into AWS, Google Cloud, Azure consoles. I don't think exposing your public key has ever been an issue for most people, and for those that it is, they can configure SSH access as you have in your parent comments.
- chrismorgan 4y ago
  That’s where you’re actually using it for authentication, for which there is obviously no alternative, and you also trust the party in question. The “demo over SSH” thing is not like that.
  - wootland 4y ago
    If you clone a public repo, this exact SSH flow happens on the GitHub servers, same with any other Git server running the SSH protocol. The OP is a git server just like that, so I don't see why it would be an issue here but not elsewhere.
    - chrismorgan 4y ago
      I’ll put it this way. When in a browser you connect to https://github.com https://github.com, it sends your session cookie so the server knows who you are. Well and good. What it doesn’t do is send any of that to any other server; if example.com wants to know (and prove) your GitHub username, you have to go through an OAuth flow where you explicitly grant permission for sharing these details. By contrast, the OpenSSH remote login client (`ssh`) defaults to leaking this potentially-sensitive information. It shares all your keys, when you probably actually want to share zero or one of them.
      - wootland 4y ago
        I'm talking about using Git over SSH (a protocol it and all of the Git hosts support). You can do this right now: git clone git@github.com:Chanzhaoyu/chatgpt-web.git And it will use SSH, no web browser involved: https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protoco...
      - Aeolun 4y ago
        > It shares all your keys, when you probably actually want to share zero or one of them. Is that true though? When I connect to a server I generally want ssh to connect with _any_ of the keys that are currently in my agent. For that to happen the server needs to check if I’m allowed to connect with each of them, therefore I have to send that information to the server. I guess SSH could default to asking me which key I want to connect with and then store that info afterwards? If I wanted it to connect using only a specific key for that host (or pattern), I’d specify that in my ssh config.
        chrismorgan 4y ago
        > I guess SSH could default to asking me which key I want to connect with and then store that info afterwards? Exactly. When you consider that it already does this sort of thing for host keys, it’s really a pretty obvious way to plug the information disclosure vulnerability.

wootland 4y ago

Do you feel the same way about GitHub/GitLab... because Git works over SSH and anytime you clone anything over the SSH protocol your public keys are sent to the server. Same thing with SSHing into AWS, Google Cloud, Azure consoles. I don't think exposing your public key has ever been an issue for most people, and for those that it is, they can configure SSH access as you have in your parent comments.

chrismorgan 4y ago
That’s where you’re actually using it for authentication, for which there is obviously no alternative, and you also trust the party in question. The “demo over SSH” thing is not like that.
- wootland 4y ago
  If you clone a public repo, this exact SSH flow happens on the GitHub servers, same with any other Git server running the SSH protocol. The OP is a git server just like that, so I don't see why it would be an issue here but not elsewhere.
  - chrismorgan 4y ago
    I’ll put it this way. When in a browser you connect to https://github.com https://github.com, it sends your session cookie so the server knows who you are. Well and good. What it doesn’t do is send any of that to any other server; if example.com wants to know (and prove) your GitHub username, you have to go through an OAuth flow where you explicitly grant permission for sharing these details. By contrast, the OpenSSH remote login client (`ssh`) defaults to leaking this potentially-sensitive information. It shares all your keys, when you probably actually want to share zero or one of them.
    - wootland 4y ago
      I'm talking about using Git over SSH (a protocol it and all of the Git hosts support). You can do this right now: git clone git@github.com:Chanzhaoyu/chatgpt-web.git And it will use SSH, no web browser involved: https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protoco...
    - Aeolun 4y ago
      > It shares all your keys, when you probably actually want to share zero or one of them. Is that true though? When I connect to a server I generally want ssh to connect with _any_ of the keys that are currently in my agent. For that to happen the server needs to check if I’m allowed to connect with each of them, therefore I have to send that information to the server. I guess SSH could default to asking me which key I want to connect with and then store that info afterwards? If I wanted it to connect using only a specific key for that host (or pattern), I’d specify that in my ssh config.
      - chrismorgan 4y ago
        > I guess SSH could default to asking me which key I want to connect with and then store that info afterwards? Exactly. When you consider that it already does this sort of thing for host keys, it’s really a pretty obvious way to plug the information disclosure vulnerability.