Displaying 20 results from an estimated 10000 matches similar to: "[Bug 2079] New: openssh 6.1/6.2 disconnect due to channel bug"
2012 Oct 22
1
[PATCH] Implement remote dynamic TCP forwarding
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
2010 Jan 14
1
ssh(1) multiplexing rewrite
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
2007 Aug 03
1
Channel Patch
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
2001 Jul 04
1
remote forwarding in 2.9p2
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
2000 Jan 07
2
possible clue on tcp forwarding problems
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
2013 Jun 04
7
[Bug 2116] New: SSH to Nortel/Avaya switch fails
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
2010 Jan 27
1
Multiplexing bug on client exit
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
2001 Aug 16
1
port-forwarding problem!?
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
2001 Sep 26
1
Protocol 2 remote port forwarding
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
2012 Sep 09
2
Patch for ssh-keygen to allow conversion of public key to openssh format
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
2000 Aug 23
1
Protocol 2 remote forwarding patch
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
2023 Nov 08
2
Delay in starting programs on FreeBSD via ssh after upgrade OpenBSD from 7.3 to 7.4
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
2013 Aug 05
2
RemoteForward and dynamically allocated listen port
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
2005 Feb 24
7
Question performnace of SSH v1 vs SSH v2
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
2013 Jan 04
16
[Bug 2057] New: ssh should treat "Received disconnect" messages as errors
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:
2013 Apr 15
12
[Bug 2090] New: SSH/SSHD hang with a Match User setting in sshd_config .
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
2001 Feb 22
3
intermittent stderr
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
2020 Oct 14
2
Connection hang, can't stop SSH
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
2005 Mar 05
0
how can I identify disconnect due to low <queue-size>
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
2005 Mar 07
1
how can I identify disconnect due to low
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