SSH Client
I am porting the ssh client to an embedded platform and wanted to see where to start in the code. Main seems to setup the server, I just need to port the client
use dropbear ssh client over specific interface?
Hei hei, say I have a machine with multiple network interfaces, and maybe policy based routing. Is it possible to let the ssh client use a specific network interface for an outgoing connection? I could not tell from `man 8 dropbear` or `man 1 dbclient`. Greets Alex signature.asc Description: OpenPGP digital signature
Re: use dropbear ssh client over specific interface?
> On Sat 18/10/2014, at 4:09 pm, Alexander Dahl wrote: > > say I have a machine with multiple network interfaces, and maybe policy > based routing. Is it possible to let the ssh client use a specific > network interface for an outgoing connection? I could not tell from `man > 8 dropbear` or `man 1 dbclient`. Hi Alex, Not at the moment. It wouldn’t be hard to implement OpenSSH’s “-b bindaddress”, I’ll put it on the todo list. Cheers, Matt
Dropbear 2016.71 issue with Bitvise ssh client v7.15
Hi All, I am running Dropbear v2016.74 SSH server from inetd on uClinux OS running on ARM cortex M3 processor. When I connected to the SSH server using Bitvise ssh client v7.15 with option "open SFTP" enabled (by default) in addition to "Open Terminal" option (by default), the client successfully connected to the server. The terminal program (custom CLI, not linux shell) is accessible. I am not doing any sftp transfers during the session. After disconnecting the ssh session, I am not able to reconnect again from Bitvise ssh client. When I debugged further I found that there is a process "cli -c /usr/libexec/sftp-server" still running in the background on uClinux Os. Workaround: I tried following two options to workaround this issue. 1. kill cli process manually before reconnecting the client again. This works fine. 2. disable "Open SFTP" option in Bitvise ssh client. This also works fine & no background sftp process is getting created. I wanted to know why Dropbear ssh server is not terminating all child processes when the connection is terminated from bitvise ssh client. Is this a known issue? Thanks and Regards, Naveen
[PATCH] ssh client can't be compiled without interactive authentication
Compiling dropbear without ENABLE_CLI_INTERACT_AUTH results in an error ... a needed member of "clientsession" structure from session.h isn't included. Because I can't see a direct coherence between "no interactive authentication" and "unencrypted connection", my proposed change is to declare "cipher_none_after_auth" in any case (a simple #endif has to move one line up). --- session.h.org 2013-04-18 16:58:14.0 +0200 +++ session.h 2013-08-28 15:32:36.0 +0200 @@ -270,9 +270,9 @@ info request from the server for interactive auth.*/ +#endif int cipher_none_after_auth; /* Set to 1 if the user requested "none" auth */ -#endif sign_key *lastprivkey; int retval; /* What the command exit status was - we emulate it */
Re: Dropbear 2016.71 issue with Bitvise ssh client v7.15
Hi Naveen, Which sftp-server are you using? Dropbear doesn't ship its own. It would have expected that it would exit when the SSH session exits, because its pipe will be closed. Do you know what is preventing the second connection - is memory constrained so only one sftp-server process can run? Cheers Matt > On Mon. 5/12/2016, at 3:10 pm, Naveen Mamindlapalli > wrote: > > Hi All, > > I am running Dropbear v2016.74 SSH server from inetd on uClinux OS > running on ARM cortex M3 processor. When I connected to the SSH server > using Bitvise ssh client v7.15 with option "open SFTP" enabled (by > default) in addition to "Open Terminal" option (by default), the > client successfully connected to the server. The terminal program > (custom CLI, not linux shell) is accessible. I am not doing any sftp > transfers during the session. > > After disconnecting the ssh session, I am not able to reconnect again > from Bitvise ssh client. When I debugged further I found that there is > a process "cli -c /usr/libexec/sftp-server" still running in the > background on uClinux Os. > > Workaround: > I tried following two options to workaround this issue. > > 1. kill cli process manually before reconnecting the client again. > This works fine. > 2. disable "Open SFTP" option in Bitvise ssh client. This also works > fine & no background sftp process is getting created. > > I wanted to know why Dropbear ssh server is not terminating all child > processes when the connection is terminated from bitvise ssh client. > Is this a known issue? > > Thanks and Regards, > Naveen
doesn't stop command when remote ssh client is killed
A difference in behaviour that I have noticed between dropbear (on OpenWRT) and openssh (on CentOS 7) is that if I start a long running command from a client configured to use Control* muxing that writes output to stdout, when I stop the client, the long running command doesn't get a SIGPIPE. Without the Control* muxing, the long running process will get a SIGPIPE. This works as expected (i.e. the long running process gets a SIGPIPE) on the CentOS 7/openssh server even when it is using Control* muxing. Thoughts? Cheers, b. signature.asc Description: This is a digitally signed message part
weird hang and tcp retransmissions in dropbear ssh client 2014.63
Hello devs, i stumbled upon a rare but very exasperating bug in openwrt's dropbear, steps to reproduce: connecting from a debian7 with openssh-client_1:6.6p1-4~bpo70 to an openwrt bb-rc3 running dropbear 2014.63 as server with agent forwarding enabled on client, then try to "daisy-chain" into another host [debian7]-->[openwrtA]-->[openwrtB] so, ssh into openwrtA, and from there do "ssh openwrtB" expected behaviour (this works with dropbear_2012.55): successfully login into openwrtB without being asked for a password, since openwrtA's dropbear forwards the credentials from debian7 to openwrtB actual behaviour: (with 2014.63, and also 2013.59 IIRC) openwrtA dropbear client hangs for a minute or more, finally dying with a timeout error. --- i'm so used to using pubkeys, that it never ocurred to me that it'd make a difference to disable agent forwarding. Today i discovered that if I disable agent forwarding on my openssh-client, then connect to openwrtA, and from there ssh into openwrtB, it will ask for a password and let me login just fine. Hope that serves as a pointer in the right direction :) attached you'll find two pcaps, taken with tcpdump on openwrtA. in the first one, to simplify the setup, i simply did "ssh localhost" (so openwrtA = openwrtB) which works as expected in 2012.55, and produces this bizarre pcap in 2014.63. as a contrast, i also send the result of doing "ssh debian7" (192.168.1.234) from openwrtA. openssh-server reacts just fine, and i can login back to my computer from dropbear-client running on openwrtA in both cases, agent forwarding was enabled on my debian7 openssh-client hope i didn't confuse the hell out of you, sorry to ruin your delightful weekend with such an intricate report, and thanks in advance for any help :) cheers! gui dropbear_2014.63_ssh-localhost-on-openwrt-trunk.cap Description: application/vnd.tcpdump.pcap dropbear_2014.63_ssh-wheezy-from-openwrt-trunk.cap Description: application/vnd.tcpdump.pcap
