openssh bugs - Feb 2015 - [Bug 2358] New: allow sshd to "redirect" to another local user

https://bugzilla.mindrot.org/show_bug.cgi?id=2358

            Bug ID: 2358
           Summary: allow sshd to "redirect" to another local user
           Product: Portable OpenSSH
           Version: 6.7p1
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: calestyo at scientia.net

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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2358

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at zip.com.au

--- Comment #1 from Darren Tucker <dtucker at zip.com.au> ---
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.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2358

--- Comment #2 from Christoph Anton Mitterer <calestyo at scientia.net>
---
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).

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2358

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #3 from Damien Miller <djm at mindrot.org> ---
(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

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2358

Max Langbein <m_langbe at cs.uni-kl.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |m_langbe at cs.uni-kl.de
            Version|6.7p1                       |7.6p1

--- Comment #4 from Max Langbein <m_langbe at cs.uni-kl.de> ---
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).

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.