similar to: remote forwarding in 2.9p2

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

Using OpenSSH_2.9p2 on Linux and Sparc Solaris. Trying to connect from Linux to Solaris, with remote port-forwarding i.e. On Linux, ssh -R 3000:Linux:23 Solaris The connection is established okay, but the port-forwarding does not work; on Solaris, the connection to localhost port 3000 is accepted, but it appears as if no data makes it back to port 23 on Linux. If an older 1.2.30 sshd is used

Hi all, I'm using openssh-2.9p2 on Solaris 2.8. I can get remote port forwarding to work using the -R flag, but only with ssh protocol 1 not ssh protocol 2. I've read that remote forwarding protocol 2 was not supported in earlier versions of openssh, but I'm wondering if this is still the case. Jarno Huuskonen [Jarno.Huuskonen at uku.fi], posted a patch in 2000 to add support for

this (uncomplete) patch makes various features compile time options and saves up to 24K in the resulting ssh/sshd binaries. i don't know whether this should be added to the CVS since it makes the code less readable. perhaps WITH_COMPRESSION should be added, since it removes the dependency on libz -m Index: Makefile.inc =================================================================== RCS

Hello, I'm running OpenBSD 2.9 (-rOPENBSD_2_9) on i386. Remote port forwarding doesn't work. Attached are 2 logs of ssh -v -R2828:localhost:22 localhost and sshd -p 2222 -d Note that server tries to forward to Connection to port 2828 forwarding to 0.0.0.0 port 0 requested. instead of localhost port 22 as it should. what ssh, what sshd and /etc/sshd_config are also attached. Thanks

Hi, At the n2k10 OpenBSD network hackathon, I finally got some time to clean up and rewrite the ssh(1) client multiplexing code. The attached diffs (one for portable OpenSSH, one for OpenBSD) are the result, and they need some testing. The revised multiplexing code uses a better protocol between the master and slave processes and I even bothered to write it up :) It tracks the control sockets

Hello, Today I tried using "dynamically assigned" port for remote listener, by requesting listener on port 0. This is supposed to create a listener on a port choosen by server. Everything seemed OK (the choosen port was sent back to client), but forwarding was refused. So I checked the source. in channels.c, function: channel_setup_fwd_listener /* *

https://bugzilla.mindrot.org/show_bug.cgi?id=2649 Bug ID: 2649 Summary: Problem with reverse tunnel between SSH client 5.5p1 and SSH server > 6.4p1 Product: Portable OpenSSH Version: 6.7p1 Hardware: amd64 OS: Linux Status: NEW Severity: normal Priority: P5

Hi, we got a report on the Cygwin mailing list showing that there's a spurious error message when using the -W option. This didn't occur with OpenSSH 6.4p1. Here's an example: $ ssh machine1 -W machine2:22 getsockname failed: Bad file descriptor SSH-2.0-OpenSSH_6.1 The error message is a result of getsockname being called with a file descriptor -1. The call stack at the

Specifying a RemoteForward of 0:example.com:1234 dynamically allocates the listen port on the server, and then reports it to ... the client! Where it is practically useless. Was this someone's idea of a joke? Presumably not--there are some technical obstacles to reporting it to the remote process. I'd like to help solve that problem. The natural way to me would be to extend the syntax

Could you please try the below diff if you have been experiencing problems with the globbing support in the sftp client. There have been a few reports that it doesn't work on Solaris, etc. Index: ChangeLog =================================================================== RCS file: /var/cvs/openssh/ChangeLog,v retrieving revision 1.1022 diff -u -r1.1022 ChangeLog --- ChangeLog 2001/03/28

We have developed a patch that enables changing the SSH window size using the tcp window size as the source. This allows SSH to obtain maximum use of the bandwidth on high BDP links. We also have a page that describes the changes and performance. http://www.psc.edu/~rapier/hpn-ssh/ The patch against CVS is included here. Common subdirectories: src/usr.bin/ssh/CVS and ssh/CVS diff -u

Hi, I am still working on getting hostbased authentication working in OpenSSH 3.5p1. I emailed the user list, and got no response. It seems so simple, yet I have continued to have problems getting it working properly. I've read posts about it on this list, and the openssh-unix-dev list, and nothing I have tried seems to work. My question is this, does it matter which key, either

I am running OpenSSH 2.9p1 on SunOS 5.7 w/4-24-2001 patch cluster. Like many other users I am seeing the hanging session on logout with background processes. This is a huge problem for me as I centrally manage 50+ machines with rdist across ssh. Instead of just complaining about the problem I thought I would put my CS degree to use and try to track down the problem myself. For starters,

Attached is a patch to allow a user to turn on TCP keepalives for port forwarded connections. It's mainly useful when the connections to the ssh listener are coming from many different boxes, some of which crash, leaving the service on the other side of the port forwarder waiting on connections indefinitely. It creates a new option named "KeepAliveForward" to control this behavior.

On Mon, 2024-03-04 at 20:10 -0500, Tygre via samba wrote: > Hi there, > I have looked for a solution to my problem on the Internet (and > in particular this mailing list), but couldn't find one, probably due > to searching for the wrong thing :-) > I have an RPI running Samba version 4.9.5-Debian. "pdbedit -L" > shows that the user "smbuser" exists. I

Hi there, I have looked for a solution to my problem on the Internet (and in particular this mailing list), but couldn't find one, probably due to searching for the wrong thing :-) I have an RPI running Samba version 4.9.5-Debian. "pdbedit -L" shows that the user "smbuser" exists. I used "smbpassword" to set the password of "smbuser". I also have

Hi there, Sorry to come back to that, I tried to follow the code at https://github.com/samba-team/samba/blob/master/source3/auth/auth.c#L214 (and below) but I still can't understand why one Samba client can connect, but the other can't. I can't understand why, with one client, the code would go into "check_samsec.c:183" (and return "sam_account_ok") while, with

https://bugzilla.mindrot.org/show_bug.cgi?id=2079 Bug ID: 2079 Summary: openssh 6.1/6.2 disconnect due to channel bug Classification: Unclassified Product: Portable OpenSSH Version: 6.1p1 Hardware: amd64 OS: FreeBSD Status: NEW Severity: normal Priority: P5 Component: ssh

Portable OpenSSH 2.5.2p2 is now available from the mirror sites listed at http://www.openssh.com/portable.html Security related changes: Improved countermeasure against "Passive Analysis of SSH (Secure Shell) Traffic" http://openwall.com/advisories/OW-003-ssh-traffic-analysis.txt The countermeasures introduced in earlier OpenSSH-2.5.x versions caused interoperability problems with