Re: Strange behaviour surrounding "ssh -T ..." and non-zero exit
>> Here is a more practical example which demonstrates the problem: >> >> $ echo false | dbclient -T r...@host.example.com >> $ echo $? >> 0 > > I think this should now _really_ be fixed with > https://secure.ucc.asn.au/hg/dropbear/rev/79eef94ccea9 > > dbclient was ignoring all packets for channels that were in the process > of being closed, which included exit status messages. This seems to work. I applied this change to an otherwise vanilla dropbear-2018.76, and it seemed to solve the problem. Thank you! -- Mike :wq
Re: dbclient can't connect to cisco
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 they did it on purpose, maybe to stop some kind of attack (back in the old days sendmail's greet_pause was enough to spot spambots). rfc4253: 5.2. New Client, Old Server RFC's are always right, it's definitely a cisco bug/feature! I'll try to register and report the problem to them, just for fun. Thank you, cheers -- /\/ / /-<
Re: dbclient can't connect to cisco
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 yet received the version banner when we send the first key exchange packet. Cheers, Matt
Re: dbclient can't connect to cisco
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 after sendind the >> identification string and then waits for the lost kexinit. >> To prove my idea I added a sleep() after the first write_packet(), and >> dbclient was able to connect to cisco (ios 12.4 and 15.1). > > Yes, it seems some Cisco SSH versions are buggy. Older IOS is possibly OK (I > did a bit of investigation about a year ago when someone reported similar). > > 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? Note that OpenSSH enables a couple of workarounds for Cisco-1.* https://github.com/openssh/openssh-portable/blob/master/compat.c#L88 > > Cheers, > Matt > > rfc4253: > 5.2. New Client, Old Server > > Since the new client MAY immediately send additional data after its > identification string (before receiving the server's identification > string), ... -- Regards, Konstantin
Re: dbclient can't connect to cisco
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 then waits for the lost kexinit. > To prove my idea I added a sleep() after the first write_packet(), and > dbclient was able to connect to cisco (ios 12.4 and 15.1). Yes, it seems some Cisco SSH versions are buggy. Older IOS is possibly OK (I did a bit of investigation about a year ago when someone reported similar). 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? Cheers, Matt rfc4253: 5.2. New Client, Old Server Since the new client MAY immediately send additional data after its identification string (before receiving the server's identification string), ...
Re: Strange behaviour surrounding "ssh -T ..." and non-zero exit
Hi Mike, > On Sat 10/11/2018, at 12:52 am, W. Michael Petullo wrote: > > > Here is a more practical example which demonstrates the problem: > > $ echo false | dbclient -T r...@host.example.com > $ echo $? > 0 I think this should now _really_ be fixed with https://secure.ucc.asn.au/hg/dropbear/rev/79eef94ccea9 dbclient was ignoring all packets for channels that were in the process of being closed, which included exit status messages. Cheers, Matt
