
An SSH server that knows who you are - tech234a
https://twitter.com/FiloSottile/status/1229093553269362689
======
jffry
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)

------
femto113
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/ef9162d670def84b3c684d2d305...](https://gist.github.com/femto113/ef9162d670def84b3c684d2d30588037)

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

~~~
fazilakhtar
Look at kssh (Keybase SSH)

------
peteretep
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?

~~~
Thorrez
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
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
I mean, if a mitm has your SSH server key, chances are you are screwed anyway.

~~~
dependenttypes
In the case which I am describing nobody other than you has your key.

~~~
rekoil
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
> But the key you are talking about the SSH client recognising is the server
> key right?

Correct

> which is why I said that if someone who is able to redirect your SSH
> connection to a different server

I will try to be more clear. Often when I am away I use ssh to connect to my
desktop pc which has a dynamic IP address. Even though I have already stored
the public key of my server in known_hosts it keeps asking me to verify if I
trust its public key every time that it changes IP address without even
mentioning that it has met said public key before. So if I am not careful
enough I might end up accepting the public key regardless, even if I am being
MITMed.

~~~
rekoil
Ah, yes, I've always found that to be a little strange. It is
cryptographically possible for the server to establish to the client that it
is who it says it is, just on a different IP

Sorry for the confusion, I misread your initial comment, thought you were
saying it does what we're saying would be a good behaviour, and was confused
as to why you thought this was a problem, but it was just I who was confused!

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

~~~
guessmyname
> _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.

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

------
leowoo91
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
> _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)

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

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

~~~
exabrial
The fact that people are using this tool regularly and fail to grep a basic
understanding of what and how the protocol works in mind blowing.

~~~
untog
Is it really? It’s what Github recommends for every new user without
explaining in real depth what’s going on.

