Bug 2358

Summary:	allow sshd to "redirect" to another local user
Product:	Portable OpenSSH	Reporter:	Christoph Anton Mitterer <calestyo>
Component:	sshd	Assignee:	Assigned to nobody <unassigned-bugs>
Status:	NEW ---
Severity:	enhancement	CC:	djm, dtucker, m_langbe
Priority:	P5
Version:	7.6p1
Hardware:	All
OS:	All

Description Christoph Anton Mitterer 2015-02-22 02:57:11 AEDT

Hi.

This request is very close to bug #2357, i.e. it could be very handy to have it for "vhosting" like use cases in SSH, but I think it may also be generally useful, which is why I filed it as a separate enhancement request.

It would be nice if sshd could "redirect" a connection to user foo to another local user bar, consider roughly the following sshd_config:
Match User foo
User bar

Let me bring again my git/gitolite use case as an example where this could be helpful for vhosting:
Match User git LocalAddress 11.22.33.44
User git-a
Match User git LocalAddress 11.22.33.55
User git-b

So one would have e.g. two domains, pointing to different IPs, which however both go to the same physical host (and thus sshd).
In that example it would be desired, that the two git/gitolites are completely separate, i.e. no shared "usernames" (which they implement via ssh keys), no shared repositories between the two domains and so on.

Right now, one would need two different user accounts for this, and two different git/gitolite installations.
But this in turn "breaks" the typical convention of using "git" as the connecting username.
The above functionality would allow this, basically hiding that there is actually another user, with different UID, home, etc. being used.
And restricted environments (like gitolite) would really hide this from the user.

Another possible (non-vhosting related) use case could be that bigger installations (in terms of users) give their users either aliases for their logins (e.g. it's often the case that people have multiple email addresses one being like "christoph.mitterer" and the other being the account name like "cmitterer" - then people could log in with both)... or temporary redirects in case the username is changed, e.g. one marries and "cmitterer" would become "cmueller", then I could login for a while with both (and especially all scripts/etc. where the name might be hardcoded would continue to function for a while, till I migrated them.

Admittedly, I haven't much thought about any possible security implications of this - at least at a first glance I wouldn't see any.

Cheers,
Chris.

Comment 1 Darren Tucker 2015-04-15 16:31:08 AEST

Thinking about this one I think it would be possible to fit into the Match framework but I'm struggling to think of an example of where it would actually be useful.  Why would you want to do such a thing?

As for security implications: it might upset privsep (in general it does not allow changing of usernames once started).  It would have to be explicitly configured by the system administrator.

Comment 2 Christoph Anton Mitterer 2015-04-15 23:16:48 AEST

Well my main idea for a "use case" was the example as given with gitolite.

Another one may be when user names are migrated on the remote side, so that the old ones are still valid as legacy names or so.

The feature simply seems a "natural" counterpart to what we have with "HostName" and "User" on the client side.



As for the security:
What you write only addresses the SSH part itself, right?
I rather wondered: Are there client side and/or server side applications, which assume that the specified user name during login is actually the one which is taken on the remote side (*if* login succeeds).

Comment 3 Damien Miller 2015-11-13 14:19:07 AEDT

(In reply to Darren Tucker from comment #1)
> Thinking about this one I think it would be possible to fit into the
> Match framework but I'm struggling to think of an example of where
> it would actually be useful.  Why would you want to do such a thing?
> 
> As for security implications: it might upset privsep (in general it
> does not allow changing of usernames once started).  It would have
> to be explicitly configured by the system administrator.

I know of one case where system administrators wanted to implement a "catch-all" user. They did this by hacking getpwnamallow() to lookup a single account for all users. We could do a "ForceUser" option that did something similar I guess.

it does mean that authctxt->user wouldn't be the same as authctxt->pw->pw_name and a couple of things depend on this, e.g. s/key

Comment 4 Max Langbein 2020-11-21 00:28:45 AEDT

IMHO the functionality needed by the OP could quite well be implemented without a separate user, just by using the ChrootDirectory option inside the Match section (of course, there is a tiny bit more hassle by creating the directory roots for the different "vhosts ", with different /home pointing to different directories).