Page MenuHomePhabricator

When a repository remote URI has a username in the URI and a different credential username, fail in an obvious way
Open, WishlistPublic


See PHI2165.

A repository may have a remote URI specified like, and be configured to use a credential with a different explicit username like duckling.

Currently, this resolves into an invocation of ssh -i identity.key -l duckling -- turtle@, which is ambiguous, and different versions of SSH might possibly have different behavior in the face of this ambiguity (PHI2165 reports a behavioral change which is possibly, but not conclusively, a result of an SSH version upgrade).

This should be disambiguated in the UI, probably by warning that the URI username will become controlling and choosing it over the credential username (since this is strictly more flexible in all cases I can come up with).

Event Timeline

epriestley triaged this task as Wishlist priority.Dec 14 2021, 5:58 PM
epriestley created this task.

...possibly, but not conclusively, a result of an SSH version upgrade...

Since the old and new versions of ssh are on hand, I attempted to test if their behavior differs. The old version of SSH makes it exceptionally difficult to figure out which login name it is actually using, but here's an approximate test:

$ ssh -V
OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.13, OpenSSL 1.0.1f 6 Jan 2014
$ ssh -l valid-user invalid-user@some-other-host
Permission denied (publickey).
$ ssh -l invalid-user valid-user@some-other-host
valid-user@some-other-host:/ $

That is, the older version of ssh prioritizes a username in the URI over a username in the -l flag.

Based on evidence in PHI2165, the newer version:

$ ssh -V
OpenSSH_8.2p1 Ubuntu-4ubuntu0.3, OpenSSL 1.1.1f  31 Mar 2020

...prioritizes the -l flag over a username in a URI.

So this seems to conclusively be an SSH behavioral difference across versions.