similar to: [Bug 2079] New: openssh 6.1/6.2 disconnect due to channel bug

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

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

I've updated the channel patch including some suggestions. The main difference is that I eliminated the channels[] array entirely (and the attendant code to create the array). I did not, however, include linked list pointers in the Channel struct. Mostly because its easier for me to work with at this time. I expect I'll do it in the next iteration though. Removing the channels array

Hi, It looks like remote forwarding with SSH v2 is not working on my Solaris machines (and from what I understand from the source, it may not work elsewhere either). When looking at channel_post_port_listener() in channels.c, I found that nextstate was defined as : nextstate = (c->host_port == 0) ? SSH_CHANNEL_DYNAMIC : SSH_CHANNEL_OPENING; And later comes the call : if

When I encounter the problem with TCP port forwarding locking up, I'll see this on the client window (if I haven't invoked ssh with -q): chan_shutdown_read failed for #1/fd6: Transport endpoint is not connected chan_shutdown_read failed for #1/fd6: Transport endpoint is not connected This is with Blowfish encryption. I have to kill and restart the client when this happens. Phil

https://bugzilla.mindrot.org/show_bug.cgi?id=2116 Bug ID: 2116 Summary: SSH to Nortel/Avaya switch fails Product: Portable OpenSSH Version: 6.2p1 Hardware: All OS: All Status: NEW Severity: major Priority: P5 Component: ssh Assignee: unassigned-bugs at mindrot.org

Hi, With the 20100127 snapshot, there appears to be a bug in the multiplexing support that causes the master to die under some circumstances when a slave session exits. The error messages that I am getting are: cfe1.imorgan> exit Connection to cfe1 closed. $ channel_by_id: 2: bad id: channel free client_input_channel_req: channel 2: unknown channel channel_by_id: 2: bad id: channel free

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

Hi, I needed to convert a public RSA key to autorized_keys format and found ssh-keygen lacking this feature. I made the option -Q publicfile to allow an conversion like ssh-keygen -Q pubrsa.pem -y The patch is produced using unified diff and made on latest release. If you like it and can make a patch for the man-page also! Regards, /Lars -------------- next part -------------- diff -u

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

On Wed, 8 Nov 2023, Roger Marsh wrote: > Damien, > > Sorry about distributed context. > > Those discussions told me about the new ObscureKeystrokeTiming > argument to the ssh command. One reply suggested I try that because it > is easy to test. > > Most of my xterm ssh command combinations in fvwm configuration file > are expressed 'Exec exec xterm -title ... -e

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

Hello I have ported OpenSSH 3.8p1 to a LynxOS platform. Recently I heard a report from the field that v2 is perceived to be significantly slower than v1. Is this a known issue? Are there any configuration parameters that can be modified to make v2 faster? Thanks in advance for your response Amba

https://bugzilla.mindrot.org/show_bug.cgi?id=2057 Bug ID: 2057 Summary: ssh should treat "Received disconnect" messages as errors Classification: Unclassified Product: Portable OpenSSH Version: -current Hardware: All OS: All Status: NEW Severity: minor Priority:

https://bugzilla.mindrot.org/show_bug.cgi?id=2090 Bug ID: 2090 Summary: SSH/SSHD hang with a Match User setting in sshd_config . Classification: Unclassified Product: Portable OpenSSH Version: 6.1p1 Hardware: Other OS: AIX Status: NEW Severity: critical Priority: P5

The command "ssh ls -l /doesnotexist" gives various responses: Running from a 200 MHz PentiumPro with dsa key added to ssh-agent: Mistakes worst to fast machine: To a faster 600 MHz dual processor i686 600 MHz machine: ls: /doesnotexist: No such file or directory -- correct nothing at all -- wrong ls: select: Bad file descriptor -- wrong

On Sat, 2005-03-05 at 23:52, Mihail Egorov wrote: > 1. How can I identify disconnect due to low <queue-size>. Suppose, I have > enabled loglevel=4 (debug). Suppose, I have network jam. What shall I see at > error.log? There is a log message that signifies the removal of a listener for being too slow and that is "Client has fallen too far behind, removing" It currently

Hello Karl In your reply in this case you mentinoned: >> >> Check your TCP buffers sizes as well, a larger RTT (ping) will require a >> larger TCP window to maintain the same maximum bitrate. >> >> karl. We had troubles with the problem of "disconnecting when client has fallen too far behind" and we solved it temporarily by increasing the queue-size and

Using OpenSSH_8.3p1 I had an open (working) connection to some other box; after a bit of inactivity, some device in the middle seems to have forgotten about the TCP connection (NAT) and broke it. I've got an EscapeChar defined, though; so first I tried to send a BREAK and, when that didn't help (TCP already gone, packets get lost!), I tried (just out of curiosity) a Rekey. Now I can see