Il 16/11/18 15:25, Matt Johnston ha scritto:
The problem is that waiting for the remote banner is still adding a round trip of
delay. That's fine for a local network, but me -> dropbear.nl is half a second,
that's no good.
As long as we let the Cisco speak first, it is happy.
So why don't
> On Fri 16/11/2018, at 2:26 am, Nik Soggia wrote:
>
> So in the end if I delay the kexinit until there is some data on the wire I
> will pull the rabbit out of the cylinder.
The problem is that waiting for the remote banner is still adding a round trip
of delay. That's fine for a local
Il 14/11/18 16:13, Matt Johnston ha scritto:
I'm not keen on changing dbclient, the current implementation saves a network
roundtrip. It's perfectly reasonable according to the spec. If you have Cisco
support could you report it to them?
Unfortunately I don't have Cisco support.
I think
On Wed, Nov 14, 2018 at 06:20:59PM +0300, Konstantin Tokarev wrote:
> Note that OpenSSH enables a couple of workarounds for Cisco-1.*
>
> https://github.com/openssh/openssh-portable/blob/master/compat.c#L88
The tricky thing is that dbclient can't do anything to work around
it here. We haven't
14.11.2018, 18:16, "Matt Johnston" :
> Hi Nik,
>
>> dbclient sends "SSH-2.0-dropbear_2018.76\r\n" and kexinit
>> cisco sends "SSH-2.0-Cisco-1.25\r\n"
>> then cisco waits "ip ssh time-out" seconds and then closes the TCP socket.
>>
>> my conjecture is that cisco empties its receive buffer
Hi Nik,
>
> dbclient sends "SSH-2.0-dropbear_2018.76\r\n" and kexinit
> cisco sends "SSH-2.0-Cisco-1.25\r\n"
> then cisco waits "ip ssh time-out" seconds and then closes the TCP socket.
>
> my conjecture is that cisco empties its receive buffer after sendind the
> identification string and
Hi,
openssh can connect to cisco appliances and dbclient can't (but cisco
ssh client can connect to dropbear).
Thanks to tcpdump I think that I found the problem:
openssh sends "SSH-2.0-OpenSSH_7.4
\r\n"
cisco sends "SSH-2.0-Cisco-1.25\r\n"
openssh sends kexinit
cisco sends kexinit, then all
