[Bug 2358] allow sshd to "redirect" to another local user

[bugzilla-daemon]

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

Max Langbein  changed:

   What|Removed |Added

 CC||m_lan...@cs.uni-kl.de
Version|6.7p1   |7.6p1

--- Comment #4 from Max Langbein  ---
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.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 2358] allow sshd to "redirect" to another local user

[bugzilla-daemon]

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

Damien Miller  changed:

   What|Removed |Added

 CC||d...@mindrot.org

--- Comment #3 from Damien Miller  ---
(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.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 2358] allow sshd to redirect to another local user

[bugzilla-daemon]

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

--- Comment #2 from Christoph Anton Mitterer cales...@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.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 2358] allow sshd to redirect to another local user

[bugzilla-daemon]

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

Darren Tucker dtuc...@zip.com.au changed:

   What|Removed |Added

 CC||dtuc...@zip.com.au

--- Comment #1 from Darren Tucker dtuc...@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.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs