Re: Dropbear difficulties due to outdated version?

[Fabrizio Bertocci]

James,
What I suggested was not to recompile dropbear for the VPS, but download
and compile the same version of dropbear *on your computer* (or whatever is
the machine you are using to connect to the VPC from). Then use dbclient
instead of ssh to connect to the VPS.
If you can write on the VPC, another thing you can do is to *cross compile*
a newer version of dropbear on your PC using a toolchain for VPS, then
install dropbear
Regards,
Fabrizio


On Tue, Jun 28, 2022 at 12:52 AM James Miller 
wrote:

> Thanks to all for your responses and apologies for the delay in
> responding. I decided that perhaps including in this response output from
> the ssh -v command might be the best way to proceed since answers to some
> of the questions asked will be found there. Thus, the following
> slightly-obfuscated and commented output:
>
> ### below with key-pair authentication enabled
> OpenSSH_9.0p1, OpenSSL 1.1.1p  21 Jun 2022
> debug1: Reading configuration data /home/user/.ssh/config
> debug1: /home/user/.ssh/config line 6: Applying options for vps
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: Connecting to 12.34.56.78 [12.34.56.78] port 2.
> debug1: Connection established.
> debug1: identity file /home/user/.ssh/MyMachine.id.rsa type 0
> debug1: identity file /home/user/.ssh/MyMachine.id.rsa-cert type -1
> debug1: Local version string SSH-2.0-OpenSSH_9.0
> debug1: Remote protocol version 2.0, remote software version
> dropbear_2017.75
> debug1: compat_banner: no match: dropbear_2017.75
> debug1: Authenticating to 12.34.56.78:2 as 'user'
> debug1: load_hostkeys: fopen /home/user/.ssh/known_hosts2: No such file or
> directory
> debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or
> directory
> debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or
> directory
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug1: kex: algorithm: curve25519-sha...@libssh.org
> debug1: kex: host key algorithm: ssh-rsa
> debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256
> compression: none
> debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256
> compression: none
> debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
> debug1: SSH2_MSG_KEX_ECDH_REPLY received
> debug1: Server host key: ssh-rsa SHA256: chars here>
> debug1: load_hostkeys: fopen /home/user/.ssh/known_hosts2: No such file or
> directory
> debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or
> directory
> debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or
> directory
> debug1: Host '[12.34.56.78]:2' is known and matches the RSA host key.
> debug1: Found key in /home/user/.ssh/known_hosts:95
> debug1: rekey out after 4294967296 blocks
> debug1: SSH2_MSG_NEWKEYS sent
> debug1: expecting SSH2_MSG_NEWKEYS
> debug1: SSH2_MSG_NEWKEYS received
> debug1: rekey in after 4294967296 blocks
> debug1: get_agent_identities: bound agent to hostkey
> debug1: get_agent_identities: agent returned 1 keys
> debug1: Will attempt key: /home/user/.ssh/MyMachine.id.rsa RSA
> SHA256: explicit agent
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug1: Authentications that can continue: publickey
> debug1: Next authentication method: publickey
> debug1: Offering public key: /home/user/.ssh/MyMachine.id.rsa RSA
> SHA256: explicit agent
> debug1: send_pubkey_test: no mutual signature algorithm
> debug1: No more authentication methods to try.
> user@12.34.56.78: Permission denied (publickey).
>
> ### below with key-pair authentication disabled (no -s switch under
> /etc/default/dropbear config file)
> OpenSSH_9.0p1, OpenSSL 1.1.1p  21 Jun 2022
> debug1: Reading configuration data /home/user/.ssh/config
> debug1: /home/user/.ssh/config line 6: Applying options for vps
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: Connecting to 12.34.56.78 [12.34.56.78] port 2.
> debug1: Connection established.
> debug1: identity file /home/user/.ssh/MyMachine.id.rsa type 0
> debug1: identity file /home/user/.ssh/MyMachine.id.rsa-cert type -1
> debug1: Local version string SSH-2.0-OpenSSH_9.0
> debug1: Remote protocol version 2.0, remote software version
> dropbear_2017.75
> debug1: compat_banner: no match: dropbear_2017.75
> debug1: Authenticating to 12.34.56.78:2 as 'user'
> debug1: load_hostkeys: fopen /home/user/.ssh/known_hosts2: No such file or
> directory
> debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or
> directory
> debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or
> directory
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug1: kex: algorithm: curve25519-sha...@libssh.org
> debug1: kex: host key algorithm: ssh-rsa
> debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256
> compression: none
> debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256
> compression: none
> debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
> debug1: SSH2_MSG_KEX_ECDH_REPLY 

Re: Dropbear difficulties due to outdated version?

[Fabrizio Bertocci]

I know I am not directly answering your question, but have you thought of
building dropbear v2017.75 on your PC and use dbclient to connect (instead
of ssh) to your VPS ?
If you must use openssh, I would look into the ssh client settings to see
if there is some sort of configurable parameters that restricts some of the
functionalities (e.g. GSSAPIKexAlgorithms, HostKeyAlgorithms, ...)
My 5 cents...
Fabrizio

On Sat, Jun 25, 2022 at 1:56 AM James Miller 
wrote:

> I set up a small low-resource VPS a few years ago to use mainly as a
> light-use xmpp server. I got Dropbear operating there so I could admin it.
> Dropbear seemed a good choice since system resources were so anemic. I
> recall it being quite challenging to get key-pair authentication to
> finally work there, though I can't recall many details about how I finally
> succeeded.
>
> Sometime during the interval after I set that up, key-pair authentication
> has stopped working again. So I've had to re-enable username/password
> authentication. I'm now trying to determine why it happened that the
> key-pair authentication stopped working and am hoping I can somehow
> re-enable it.
>
> The VPS runs Ubuntu 16.04 (EMS), so the version of Dropbear there is a bit
> outdated (v2017.75). Since that release was made, various changes have
> happened to openssh that may, I assume, make it incompatible with this
> version of Dropbear. I am using ssh when I try to connect to the VPS, btw.
>
> So I'd like to start off by just asking whether the challenges I am
> encountering as I try to re-enable key-pair authentication are likely
> related to the version mismatch between the Dropbear I have installed on
> the VPS and the much more current version of openssh I have on the home
> computer from which I'm trying to connect?
>
> Input on that question will be appreciated. If it seems unreasonable to
> expect modern versions of openssh to interoperate with a Dropbear server
> dating to 2017, I will need to just give up on it and seek some other
> solution.
>
> Thank you
>

Re: restrict access

[Fabrizio Bertocci]

I've used successfully (well, at least I believe it's successful) sshblack (
http://www.pettingers.org/code/sshblack.html) to block those pesky robots
through iptables.
To get it to work correctly It's not as obvious as it seems... and there
are some limitations, but once you are familiar with it, it does its job.
(In particular, the main issue of sshblack is that if not set up correctly,
its database and iptables goes out of sync after a reboot of the host and
it essentially fails to block login attempts. email me directly for more
details).
Regards,
Fabrizio


On Thu, May 20, 2021 at 11:09 AM Sebastian Gottschall <
s.gottsch...@dd-wrt.com> wrote:

> what about a feature like blocking a client for N minutes if more than N
> times of failed logins. its relativily easy to implement and lows down
> brute force attacks
>
> Am 20.05.2021 um 16:44 schrieb Matt Johnston:
> > On Thu, May 20, 2021 at 02:29:20PM +, Walter Harms wrote:
> >> Thx for the fast response,
> >> for the background: little system, far-far-away land, but some
> script-kiddie is filling the log ...
> >> so no iptables or other fancy stuff. Seems i have to change that,
> somehow.
> >>
> >> @matt:
> >> in case i get something working ...
> >> i am thinking about fnmatch and inet_ntoa would that be acceptable ?
> > I'm not really sure it's the job of Dropbear to be doing
> > that filtering. Though I wonder if it might make sense to
> > optionally not bother logging failed SSH auth attempts,
> > given how many there are...
> >
> > Cheers,
> > Matt
> >
>

Re: Cannot Connect to Dropbear Server of Openwrt in QEMU

[Fabrizio Bertocci]

FYI, the firewall rules on OpenWRT are defined in: /etc/config/firewall

As far as I remember by default port 22 is blocked on wan, so make sure
there is a section as follow:
--
config rule
option target 'ACCEPT'
option src 'wan'
option proto 'tcp'
option dest_port '22'
option name 'SSH'
--
Regards,
Fabrizio


On Tue, Oct 20, 2020 at 9:12 AM Matt Johnston  wrote:

> Hi,
>
> Given in tcpdump there was no response at all (not even a rejection), my
> guess is there is a firewall on the OpenWrt host that drops all port 22
> packets.
> Are firewall rules listed if you go "iptables -vnL" , or in a config file?
>
> Cheers,
> Matt
>
> On Tue 20/10/2020, at 1:50 pm, 许大仙  wrote:
>
> Hi!
> Sorry to disturb you.
> I meet some problems when I try to connect  to Dropbear Server of Openwrt.
> So I really need your help.
>
> Here's the thing:
> *1. I run QEMU with Openwrt(guest) for emulating an ARM system on ubuntu
> 18.04(host).*
> Run the following commands on ubuntu 18.04:
>
> qemu-system-aarch64 -net nic,vlan=0 -net nic,vlan=1 -net user,vlan=1 \
> -m 1024 -smp 2 -cpu cortex-a57 -M virt -nographic \
> -kernel openwrt-19.07.3-armvirt-64-Image-initramfs \
> -drive if=none,file=disk.img,format=raw,id=hd0 \
> -net user,host=10.0.2.10,hostfwd=tcp:127.0.0.1:10021-:22 \
>  -net nic,model=e1000
>
> Details: https://openwrt.org/docs/guide-user/virtualization/qemu.
>
> *2. But I can not access dropbear of Openwrt through ssh in my host
> machine——ubuntu 18.04.*
> SSH timeout:
> 
> Dropbear Service of Openwrt in QEMU:
> 
>
> *3. I tried to use tcpdump to capture packages in Openwrt and found that
> dropbear did not respond to any data packet received on port 22.*
> Captured packages:
> 
>
>
> *This is so strange. Could you give me some possible reasons?*
> *Under what circumstances will Dropbear not reply to the packet?*
>
>
> *Additional Information:*
> 1. Config of dropbear
> 
> 2.  User Networking of QEMU
> https://wiki.qemu.org/Documentation/Networking
> 
>
>
>

Re: Dropbear server exit when idle?

[Fabrizio Bertocci]

I don't think you should have this functionality in Dropbear. This is
specific to your use case.
You can still do it with a bash script. At boot the script can check the
/var/log/secure file to see if there is any activity on dropbear (poll the
file size every few seconds)... Reset the internal timer whenever the file
size change between poll cycles, then kill dropbear after your 10 minutes
of inactivity.

Regards,
Fabrizio

On Thu, Mar 8, 2018 at 9:41 AM, Dave Haynes 
wrote:

> We have a small range of embedded linux devices used in security systems.
> We are undertaking a gradual process to harden the default security, and
> one of our first tasks has been replace the legacy telnet server with
> dropbear for diagnostic access.
>
> We have compiled dropbear and have it running well, set up to only allow
> one session using a patch found on this list.
>
> We are now considering if it would be worthwhile/useful to modify dropbear
> to exit after a period with no active connections. So dropbear runs at
> boot, but exits after (say) 10 minutes with no login. The devices can be
> remotely rebooted via other means, so there are no access issues for
> authorised users.
>
> Does anyone see any reason this wouldn't be a useful approach? Anyone
> patched anything similar before we start hacking about, or any pointers
> where to start?
>
> (We could give the system a task to terminate dropbear, but it would seem
> neater to produce a self contained solution.)
>
> --
> Dave Haynes
> RF Design Consultant - Wireless Solutions Ltd.
>
>

Re: Tunnelling support?

[Fabrizio Bertocci]

Russel,
dropbear fully support tunneling. Both local (with -L) and reverse (with
-R). I have been using for quite some time now.
If you expect your local port (6) to be reached from other machines,
make sure to use the -g option as well.

I think your problem is on the server side, on the ssh server that refuses
the tunnel.

Regards,
Fabrizio


On Thu, Aug 10, 2017 at 11:25 AM, Russell Warren  wrote:

> Does dropbear support tunnelling? I can't find any references for it, but
> may be searching for the wrong keywords. "tunnel" exists only once in the
> source tree, for example.
>
> My expectation is that it does not support it, but would like to confirm.
>
> I'm asking because, when I tried to set up a tunnel it did not work.  Here
> is what failed:
>
> I tried to set up the tunnel on my client like this:
>
> ssh -p 1018 -v -v -v -L 6:localhost:5433 ad...@example.com
>
> and tried to connect through it with this (also on the client):
>
> psql -h localhost -p 6
>
> the initial connection gives this output:
>
> debug1: Connection to port 6 forwarding to localhost port 5433
> requested.
> debug2: fd 9 setting TCP_NODELAY
> debug2: fd 9 setting O_NONBLOCK
> debug3: fd 9 is O_NONBLOCK
> debug1: channel 3: new [direct-tcpip]
> channel 3: *open failed: administratively prohibited*:
> debug2: channel 3: zombie
> debug2: channel 3: garbage collecting
> debug1: channel 3: free: direct-tcpip: listening port 6 for
> localhost port 5433, connect from ::1 port 57636 to ::1 port 6,
> nchannels 4
> debug3: channel 3: status: The following connections are open:
>   #2 client-session (t4 r0 i0/0 o0/0 fd 6/7 cc -1)
>
> If it matters, the end intent here is actually to use ssh tunneling to
> access postgres running on the server with dropbear (usign standard tools,
> like pgadmin3, which presumably expect standard tunneling implementations).
> The above tunnel attempt was while trying to debug connection failures with
> these tools.
>
>

Re: Getting dbclient to time out when network goes down with reverse proxy usage

[Fabrizio Bertocci]

Hmm dbclient worked well for me after that patch. But I was connecting to a
dropbear server, not OpenSSL server...

I've migrated to OpenWRT with 8MB of flash too, and I ended up rewriting my
own tunnel solution based on OpenSSL. There are much smaller SSL clients
out there that can be used for free for non-commercial products, but
requires to pay for a license for commercial use. I don't remember exactly
the name of the one we looked at (that was few years ago).

Regards,
Fabrizio



On Sat, Jul 5, 2014 at 2:14 AM, Jesse Molina je...@opendreams.net wrote:


 Fabrizio Bertocci contacted me and let me know that this seems to be a
 known issue.

 https://www.mail-archive.com/dropbear@ucc.asn.au/msg00701.html

 https://www.mail-archive.com/dropbear@ucc.asn.au/msg00980.html



 The work I am doing is on an OpenWRT device with 8MB of flash, so local
 space is very limited. I had to install the OpenSSL client yesterday, which
 took up nearly an additional 2MB of space, but at least it works. It would
 be nice to use dbclient instead, but it's idle timer is just straight-up
 broken when used with -N -R.

 This works as expected with OpenSSL client:

 ssh -i $SSH_KEYFILE -o ServerAliveInterval=15 -o ServerAliveCountMax=4
 -N -R $SSH_PROXY_PORT:localhost:22 $SSH_USER@$SSH_HOST




 On 7/4/14, 3:57, Jesse Molina wrote:


 Hello

 I am doing this:

 ssh -K 3 -I 60 -i keyfile -N -R :localhost:22 user@host

 I am intending a dropbear ssh client to set up a reverse proxy connection
 to a server, so I am using -N and -R.

 I am also using -K and -I so that the connection sends keepalives and
 will timeout if the network is disrupted.

 My problem is that the above results in the session dying 60 seconds
 after setup is finished because the idle timeout is being hit.  I am not
 sure how -I is metering inbound traffic, but it's apparently not picking up
 anything.

 Note that I have ClientAliveInterval 15 set on the sshd_config server
 side. I would expect dropbear to count this traffic towards -I.

 Without -I above, it took my device 18 minutes to figure out that I had
 pulled the network out from under it by shutting down the interface. That
 isn't acceptable.

 Can dropbear do this, or do I need to use openssh?  I get the feeling
 after reading what I have read that dropbear is too simple to figure out
 when the server has gone away in most situations.



 Relevant:

 https://www.mail-archive.com/dropbear@ucc.asn.au/msg00978.html

 https://www.mail-archive.com/dropbear@ucc.asn.au/msg00648.html

 https://www.mail-archive.com/dropbear@ucc.asn.au/msg00402.html

 Thanks in advance.

Re: Timeout dead connections

[Fabrizio Bertocci]

I remember reporting this problem and sending a patch long time ago (for
version 0.52).

The problem with the keep-alive (if I remember correctly) was that every
time dropbear was sending the keep-alive message, it was also resetting the
timeout counter... so dropbear or dbclient never detect the dropped
connection.
Here is an extract from my old email sent on 9/29/2010:

Hope this help,
Regards,
Fabrizio



First Issue: When keep-alive messages are sent, they reset the idle timeout
counter. (-I counter).
I would expect that SENT messages (in particular keep-alive packets) do not
affect the idle timeout...
This is in function write_packet() (file packet.c)
When a message is written, it stores the current time in both the registers
for the last packet transmitted *AND* last packet (for the idle timeout):
ses.last_trx_packet_time = time(NULL);
ses.last_packet_time = time(NULL);

(beside that, this cause two system calls, to read the time, when only one
would be needed... just optimizing :) )
This is a little unexpected because I would think that the idle timeout
works only on received packets, not about sent packets.
Basically if I start dropbear with -I and -K options, the idle timeout will
never kick in... because the keepalive will always reset the timer even if
the connection is dead.

I'm proposing to simply remove the line:
ses.last_packet_time = time(NULL);
So the idle timeout does not get reset when any packet is sent.

Watch out: after this change, the semantic of the argument -I is different
than before, as it only consider received packets... but at least it makes
more sense.
Here is a scenario WITHOUT this modification:
1. Start the server with: dropbear -K 15 -I 20  [...]
2. Start the client with dbclient -K 15 [...]
3. On my device, start a program that sends data over one tunneled port
Everything works fine, connection is up and data is exchanging.
Now...
4. Unplug my embedded device (the one running dbclient)
- The server does not detect the connection is down. Any attempt to access
a tunneled port cause the caller to hang.

now, after this change, with the same scenario, after I unplug my box, the
server detects it after 20 seconds and closes the connection.


Second Issue: When a keepalive message is received, the idle timeout timer
(for received packets) is NOT updated.
I'm referring here to the function 'process_packet()' in file
'process-packet.c'.
Here the timer update:
ses.last_packet_time = time(NULL);
is performed AFTER the first switch where we check for SSH_MSG_IGNORE,
SSH_MSG_DEBUG, SSH_MSG_UNIMPLEMENTED, and SSH_MSG_DISCONNECT.
So, in few words: although a keep-alive message (that is a message of type
SSH_MSG_IGNORE) is correctly ignored, but the timer is not reset.

Here is what happen:
1. Start my server again with dropbear -I 20 [...]
2. Start my client with dropbear -K 15 [...]
(this time I'm not starting my application to send data over a tunneled
port)

Without doing anything, the server will close the connection after 20
seconds. No matter if the client have sent the keep-alivemessages...

After moving that statement:
ses.last_packet_time = time(NULL);
BEFORE the first switch(), now a keep-alive message cause the idle timer to
reset, and the previous test case works as expected (server does't
disconnect).

So, in conclusion, as you see, these two small changes are critical for my
situation, and I believe they could also benefit others with similar needs.











On Wed, Mar 27, 2013 at 11:24 AM, Mattias Walström 
mattias.walst...@westermo.se wrote:

 Hi!
 I am running dropbear 2013.56, connecting to the server with a PC but
 not performing a clean close (I pulled my ethernet cable), this caused
 dropbear to never drop its connection.

 Looking at the utmp entries, I could see that the connection never got
 dropped,
 the utmp entries was kept forever, and running with debug indicates that
 also.
  Tried to use -K to send keepalive, but it just keeps sending keepalives
 to the peer,
 even it is no longer there, and not possible to reach. Shouldn't
 the connection be dropped if the keepalive does not reach its destination?

 I know there is the -I option, but that does not really do what I want,
 I want the connection to be tear down when the peer is unreachable, not
 when the user has been idle for a while.

 Regards
  Mattias

Re: Timeout dead connections

[Fabrizio Bertocci]

Yep, you're right Matt... the latest version contains those fixes... (the
truth is that I'm still working with my patched 0.52 that is rock solid for
my usage)...
Regards,
Fabrizio


On Wed, Mar 27, 2013 at 11:47 AM, Matt Johnston m...@ucc.asn.au wrote:

 I thought those were fixed in 0.53 or perhaps 2011.54:

 2011.54 - Tuesday 8 November 2011
 - Fixed case where -K 1 keepalive for dbclient would cause a
 SSH_MSG_IGNORE
   packet to be sent
 0.53 - Thurs 24 February 2011
 - Make -K (keepalive) and -I (idle timeout) work together sensibly in the
 client.
   The idle timeout is no longer reset by SSH_MSG_IGNORE packets.

 If the network cable has been pulled out, shouldn't the OS send a TCP RST
 packet eventually after some traffic and close the connection?

 Cheers,
 Matt


 On Wed, Mar 27, 2013 at 11:41:40AM -0400, Fabrizio Bertocci wrote:
  I remember reporting this problem and sending a patch long time ago (for
  version 0.52).
 
  The problem with the keep-alive (if I remember correctly) was that every
  time dropbear was sending the keep-alive message, it was also resetting
 the
  timeout counter... so dropbear or dbclient never detect the dropped
  connection.
  Here is an extract from my old email sent on 9/29/2010:
 
  Hope this help,
  Regards,
  Fabrizio
 
 
 
 
  First Issue: When keep-alive messages are sent, they reset the idle
 timeout
  counter. (-I counter).
  I would expect that SENT messages (in particular keep-alive packets) do
 not
  affect the idle timeout...
  This is in function write_packet() (file packet.c)
  When a message is written, it stores the current time in both the
 registers
  for the last packet transmitted *AND* last packet (for the idle timeout):
  ses.last_trx_packet_time = time(NULL);
  ses.last_packet_time = time(NULL);
 
  (beside that, this cause two system calls, to read the time, when only
 one
  would be needed... just optimizing :) )
  This is a little unexpected because I would think that the idle timeout
  works only on received packets, not about sent packets.
  Basically if I start dropbear with -I and -K options, the idle timeout
 will
  never kick in... because the keepalive will always reset the timer even
 if
  the connection is dead.
 
  I'm proposing to simply remove the line:
  ses.last_packet_time = time(NULL);
  So the idle timeout does not get reset when any packet is sent.
 
  Watch out: after this change, the semantic of the argument -I is
 different
  than before, as it only consider received packets... but at least it
 makes
  more sense.
  Here is a scenario WITHOUT this modification:
  1. Start the server with: dropbear -K 15 -I 20  [...]
  2. Start the client with dbclient -K 15 [...]
  3. On my device, start a program that sends data over one tunneled port
  Everything works fine, connection is up and data is exchanging.
  Now...
  4. Unplug my embedded device (the one running dbclient)
  - The server does not detect the connection is down. Any attempt to
 access
  a tunneled port cause the caller to hang.
 
  now, after this change, with the same scenario, after I unplug my box,
 the
  server detects it after 20 seconds and closes the connection.
 
 
  Second Issue: When a keepalive message is received, the idle timeout
 timer
  (for received packets) is NOT updated.
  I'm referring here to the function 'process_packet()' in file
  'process-packet.c'.
  Here the timer update:
  ses.last_packet_time = time(NULL);
  is performed AFTER the first switch where we check for SSH_MSG_IGNORE,
  SSH_MSG_DEBUG, SSH_MSG_UNIMPLEMENTED, and SSH_MSG_DISCONNECT.
  So, in few words: although a keep-alive message (that is a message of
 type
  SSH_MSG_IGNORE) is correctly ignored, but the timer is not reset.
 
  Here is what happen:
  1. Start my server again with dropbear -I 20 [...]
  2. Start my client with dropbear -K 15 [...]
  (this time I'm not starting my application to send data over a tunneled
  port)
 
  Without doing anything, the server will close the connection after 20
  seconds. No matter if the client have sent the keep-alivemessages...
 
  After moving that statement:
  ses.last_packet_time = time(NULL);
  BEFORE the first switch(), now a keep-alive message cause the idle timer
 to
  reset, and the previous test case works as expected (server does't
  disconnect).
 
  So, in conclusion, as you see, these two small changes are critical for
 my
  situation, and I believe they could also benefit others with similar
 needs.
 
 
 
 
 
 
 
 
 
 
 
 
  On Wed, Mar 27, 2013 at 11:24 AM, Mattias Walström 
  mattias.walst...@westermo.se wrote:
 
   Hi!
   I am running dropbear 2013.56, connecting to the server with a PC but
   not performing a clean close (I pulled my ethernet cable), this caused
   dropbear to never drop its connection.
  
   Looking

Re: Starting Dropbear

[Fabrizio Bertocci]

Dropbearkey only generates the keys, is not the real server.
You need to start the server on one machine (use dropbear), and the client
from another machine.
Well...
Get help page from dropbear for a list of arguments. You need to provide at
least your dsa or rsa keys to start the server side (dropbear).
On the client side you can use dbclient to connect to the server side.
Again use 'dbclient -h' for a list of command line parameters accepted.
Fab

On Fri, Apr 13, 2012 at 3:35 AM, Rayne lancer6...@yahoo.com wrote:

 Hi,

 I've just installed Dropbear, but can't figure out how to start it.

 I did

 ./configure
 make
 make install
 ./dropbearkey -t rsa -f dropbear_rsa_host_key

 When I did a ps -ef | grep dropbear, I don't see it running. Running
 ./dbclient IP address of the dropbear server also gave me the error
 ./dbclient: Exited: Error connecting: Connection refused.

 How do I start dropbear?

 Thank you.

 Regards,
 Rayne

Multiple auth requests?

[Fabrizio Bertocci]

Hi guys,
I'm working on a project that uses dropbear, and I'm modifying the code to
add a custom lookup mechanism for pub/priv keys that uses a database
instead of a file.
While debugging it, I've noticed that the server sometimes receives message
type 50 (that I understand it means auth. request) more than once.
The server, every time it receives an auth request, always attempts to
authenticate the client like it's the first time.
To limit the load on the server and reduce the number of calls to the
database, I was wondering if somebody (Matt?) can help me understanding if
it is safe to 'cache' the auth state (or, since it's already present in
ses.authstate, reuse that value) and send back immediately the previous
auth state.

Unfortunately right now I'm on dropbear 0.52 (it's very stable for me and
I'm not very motivated to upgrade to the latest version yet).

Any help is highly appreciated!!
Regards,
Fabrizio