similar to: [Bug 2416] New: [PATCH] Allow forwarding of stdio to streamlocal end points

Later versions of OpenSSH allow the user to forward connections also to/from Unix sockets. This patch allows to use Unix sockets as the target when forwarding the local stdio using the -W feature. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Allow-forwarding-of-stdio-to-streamlocal-end-points.patch Type: application/text Size: 5796 bytes Desc: not

Hi ! Here's a patch to add remote port forwarding support (protocol 2) for openssh. I have tried to test that it works like it should but a more thorough testing is needed. This patch adds both client/server support. The patch should be applied to openssh-2.1.1p4 source tree. Also included is a PortForwarding sshd_config option, new ./configure option --disable-forwarding that should make it

https://bugzilla.mindrot.org/show_bug.cgi?id=2529 Bug ID: 2529 Summary: direct-streamlocal channel open doesn't match PROTOCOL documentation Product: Portable OpenSSH Version: -current Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: ssh

When forwarding a Unix-domain socket, the remote socket path must be absolute (otherwise the forwarding fails later). However, guessing absolute path on the remote end is sometimes not straightforward, because the file system location may vary for many reasons, including the system installation, the choices of NFS mount points, or the remote user ID. To allow ssh clients to request remote socket

--- channels.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/channels.c b/channels.c index a84b487..396e192 100644 --- a/channels.c +++ b/channels.c @@ -3014,10 +3014,14 @@ channel_setup_fwd_listener_streamlocal(int type, struct Forward *fwd, debug3("%s: type %d path %s", __func__, type, fwd->listen_path); + /* Expand home directory if necessary */ +

https://bugzilla.mindrot.org/show_bug.cgi?id=1632 Summary: [PATCH] UTF-8 hint sftp-server extension Product: Portable OpenSSH Version: 5.2p1 Platform: All OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: sftp-server AssignedTo: unassigned-bugs at mindrot.org

Hi all, This is a client side only implementation of reversed dynamic (SOCKS) TCP forwarding, which means it is compatible with any existing servers have 'remote forward' capability. To establish such forward, use "ssh -R [BIND_ADDRESS:]PORT ...". The server will listen on that port and address and accept SOCKS traffics. Hope this will be useful for you. There was an

https://bugzilla.mindrot.org/show_bug.cgi?id=2147 Bug ID: 2147 Summary: OpenSSH remote forwarding of dynamic ports doesn't work when you create more than one Product: Portable OpenSSH Version: -current Hardware: All OS: All Status: NEW Severity: normal Priority: P5

https://bugzilla.mindrot.org/show_bug.cgi?id=396 Andrew McNabb <amcnabb at mcnabbs.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |amcnabb at mcnabbs.org --- Comment #16 from Andrew McNabb <amcnabb at mcnabbs.org> 2012-02-10 05:21:40 EST

https://bugzilla.mindrot.org/show_bug.cgi?id=2601 Bug ID: 2601 Summary: StreamLocalBindUnlink not working Product: Portable OpenSSH Version: 7.2p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: ssh Assignee: unassigned-bugs at mindrot.org

https://bugzilla.mindrot.org/show_bug.cgi?id=1424 Summary: Cannot signal a process over a channel (rfc 4254, section 6.9) Classification: Unclassified Product: Portable OpenSSH Version: 4.7p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: sshd

https://bugzilla.mindrot.org/show_bug.cgi?id=1572 Summary: accept SOCKS requests over the mux socket in master mode Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: ssh AssignedTo: unassigned-bugs

Hello, there is a patch which allows redirecting UNIX domain sockets here: http://www.25thandclement.com/~william/projects/streamlocal.html<http://www.25thandclement.com/%7Ewilliam/projects/streamlocal.html> We really need it in our institution. It's for OpenSSH 4.4 but I managed to adopt it for 4.7p1 included in Ubuntu 8.04.

https://bugzilla.mindrot.org/show_bug.cgi?id=2421 Bug ID: 2421 Summary: direct-streamlocal at openssh.com doesn't have a reserved string - PROTOCOL.txt Product: Portable OpenSSH Version: 6.9p1 Hardware: Other OS: All Status: NEW Severity: enhancement Priority: P5

I've a server where clients can connect to using direct-streamlocal at openssh.com. I want that the server "knows" the address of the client. I've tried using the peercredentials of the process connecting my server (which is a sshd process) and check the environment. I thought that in the environment the var SSH_CLIENT would be set, but that did not work. This sshd process has

https://bugzilla.mindrot.org/show_bug.cgi?id=2283 Bug ID: 2283 Summary: option to execute command without shell Product: Portable OpenSSH Version: 6.6p1 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: sshd Assignee: unassigned-bugs at

To the openssh and sudo developer mailing lists: Ssh has a key agent allowing authentication to remote hosts without entering your password/passphrase again and again, which is very convenient. I think the 'su', 'sudo', and similiar commands could benefit from this idea and mechanism. I don't have the necessary expertise in cryptology to do this myself so I just want to throw

Hi, Just a usecase that I'm sure has been covered before but just in case its not an openssh solution would be very helpful. I was trying to install software on a server that was firewalled so no outbound http connections would work. I was also tunnelling via another server. Outbound ssh connections also were a convenient option. What would have been nice would be a remote version of

On Tue, 3 May 2016, Rogan Dawes wrote: > Hi Damien, > Thanks for the response! > > I tried moving the StreamLocalBindUnlink directive outside of the Match > rule, and it worked. But that doesn't explain why the Match was not > correctly setting the directive: > > This is running on an alternate port with -ddd: > > debug3: checking match for 'User

Two servers, each have normal user umask values of 0077 and root umask values on 0022. On the first server (CentOS 5.4 i386) running sudo 1.6.9pl7-5 (from base), here are the results of touching a file as a user, as root and as a user sudoing to root: user: touch file - result is 600 root: touch file - result is 644 user: sudo touch file - result is 644 On the second server (CentOS x86-64)