Greetings everyone! I would like to know if adding support for Unix socket to sshd would be a feature that would be consider to be added upstream? (ListenAddress). One of the main reason for this question to you all is that tor now has Unix socket support for hidden services that is traffic of a hidden service can be forwarded to a Unix socket (see HiddenServicePort in tor.1). The rationale behind that is basically so someone can set up a server with no inet traffic allowed (firewall, namespace, <insert sandboxing tech>) _except_ for the tor daemon and use hidden service to access services on the local machine using only Unix socket, in this case ssh. That being said, if you wouldn't object to this feature being added to ssh, I'm willing to implement it and make the efforts for upstream merge. But before I do start the work, I would like to make sure it's something that won't get an automatic NACK just based on the original idea :). Big thanks! David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 603 bytes Desc: Digital signature URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20160204/cb9ceaee/attachment.bin>
On Thu 2016-02-04 07:40:39 -0500, David Goulet wrote:> I would like to know if adding support for Unix socket to sshd would be a > feature that would be consider to be added upstream? (ListenAddress).fwiw, i think this is a good idea, but i wouldn't implement it as an explicit ListenAddress option: i'd rather have sshd be able to listen on an inherited file descriptor. This would allow generic socket activation, regardless of socket type. --dkg
> On Feb 4, 2016, at 7:46 AM, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote: > > On Thu 2016-02-04 07:40:39 -0500, David Goulet wrote: > >> I would like to know if adding support for Unix socket to sshd would be a >> feature that would be consider to be added upstream? (ListenAddress). > > fwiw, i think this is a good idea, but i wouldn't implement it as an > explicit ListenAddress option: i'd rather have sshd be able to listen on > an inherited file descriptor. This would allow generic socket > activation, regardless of socket type.Can?t this already be done with ?sshd -i?, by passing in the socket via stdin/stdout? A simple wrapper which listened on the UNIX domain socket could fork & exec ?sshd -i? as new UNIX domain socket connections arrived, similar to inetd. -- Ron Frederick ronf at timeheart.net
On 04 Feb (10:46:55), Daniel Kahn Gillmor wrote:> On Thu 2016-02-04 07:40:39 -0500, David Goulet wrote: > > > I would like to know if adding support for Unix socket to sshd would be a > > feature that would be consider to be added upstream? (ListenAddress). > > fwiw, i think this is a good idea, but i wouldn't implement it as an > explicit ListenAddress option: i'd rather have sshd be able to listen on > an inherited file descriptor. This would allow generic socket > activation, regardless of socket type.Hrm... not sure I fully understand here. How would sshd inherited an fd? And what do you mean by "allow generic socket activation"? If I understand it, wouldn't that require a wrapper over sshd? Let's assume I set up an sshd and want it to use Unix socket in /foo/bar/ssh.sock, how would that work without me being able to specify somewhere the path? Thanks! David> > --dkg-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 603 bytes Desc: Digital signature URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20160204/64cb0138/attachment.bin>
Apparently Analagous Threads
- [libnbd PATCH v3 19/19] socket activation: set LISTEN_FDNAMES
- [PATCH] ssh-agent: add systemd socket-based activation
- [libnbd PATCH v3 19/19] socket activation: set LISTEN_FDNAMES
- Unix socket support for sshd
- [libnbd PATCH v3 19/19] socket activation: set LISTEN_FDNAMES