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

From: Jeff King <peff@peff.net>
Date: Jan 20, 2021, 14:35 UTC
Message-ID: <YAg/wV05JYbzOdck@coredump.intra.peff.net>
In-Reply-To: <87im7r93u7.fsf@evledraar.gmail.com>

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

Show 7 quoted lines

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