Re: False negative authentication with multiple accounts on a SSH-GIT server

[Jeff King <peff@peff.net>]

On Wed, Jan 20, 2021 at 01:42:56PM +0100, Ævar Arnfjörð Bjarmason wrote:

> > Unfortunately, this leaks whether a repository exists.  If Company XYZ
> > has a repository for each of its clients, it then becomes easy to see if
> > Company XYZ is doing work for a particular client by trying to see if a
> > repository exists.
> 
> I wonder how many hosting providers are confident that the code involved
> in this isn't vulnerable to a timing attack.

I would say "not very certain" in the case of GitHub. I don't recall any
analysis of the timing ever having happened.

> Why would a site like GitHub treat ssh differently than https here? I
> think it just comes down to openssh's support for use-case being a bit
> of a pain to configure.

GitHub doesn't use openssh at all; ssh sessions are terminated at a
custom load-balancing/proxy layer daemon.

I agree that servers in general probably could accept this notion of "no
valid user" for ssh sessions. I just think it's something that nobody
has asked for. I.e., if you are not planning to be an authenticated
user, then why use ssh in the first place? Certainly you could ask "why
not", but AFAIK this is the first time it has come up.

There is one protocol issue I'm not sure of, though. My understanding of
ssh auth is that the client offers keys in sequence, and the server says
"yes" or "no" on each. We'd want to continue saying "no" on keys that we
don't know about, so the client may keep trying other keys to which we
might say "yes". But after having seen all of the keys, what then?

We would want the server to say "OK, even though we don't like any of
your keys, let's start a session anyway". Is that possible within the
protocol? I think having the server say "OK, now try password auth" is
not a good idea. If the client asks for a dummy password, that is likely
to be either confusing, or disrupt sessions without a human present.

But I don't know the ssh protocol very well, so perhaps my understanding
of what is possible totally wrong. https has this much easier because
unauthenticated requests are totally normal, and the server sees the
auth along with the whole request at the same time.

-Peff