Re: Only do connection if I already know the destination?

[Hans Harder]

So you want to break off the connection if it isn't in the .ssh/known_host file.
Currently there is no way to do that, but with a little adaption it is possible

attached a small patch to look for an env var SSH_ASKHOSTKEY
if it is set to "y" or "n"  it will use that as answer instead of
asking that on the tty.

There are multiple ways of doing this...this is just one.

Hans

On Fri, Feb 10, 2023 at 12:24 PM Walter Harms  wrote:
>
> would it be possible to add an option to add an non-interactive mode ?
> Getting yes/no questions (or else) in a script is clearly not helpful.
>
> re,
>  wh
>
>
> 
> Von: Dropbear  im Auftrag von Matt Johnston 
> 
> Gesendet: Montag, 21. November 2022 16:20:25
> An: M Rubon
> Cc: dropbear@ucc.asn.au
> Betreff: Re: Only do connection if I already know the destination?
>
> On 2022-11-21 11:05 pm, M Rubon wrote:
> > I have an automated remote script that connects to a set of known
> > servers.  I never want be prompted to add a new host key if the server
> > is missing from .ssh/known_hosts.   If the key is missing, the client
> > should just immediately exit.
> >
> > Dropbear seems to give me the option of relaxing the host key checks
> > (-y -y).  Is there an option to make them more strict?
>
> I don't think there's any way to do that at the moment.
>
> Cheers,
> Matt
>
> >
> > M
> >
> > p.s. OpenSSH client option "StrictHostKeyChecking yes" is basically
> > what I am looking for.
210d209
<   char *askhostkey = NULL;
221,228d219
< 
<   askhostkey = getenv("SSH_ASKHOSTKEY");
<   if (askhostkey && strchr("yn",*askhostkey)!=NULL) {
<   m_free(fp);
<   if (*askhostkey == 'y') {
<   return;
<   }
<   } else {
246d237
<   }

Re: restrict access

[Hans Harder]

or when you have no root access...

On Tue, May 25, 2021 at 11:14 AM Walter Harms  wrote:
>
> yes, under normal circumstances you would use iptables to block the port. But 
> when you are forced to byte-counting and you do not want to install other 
> programms (and maintains them) on your embedded system, this is clearly an 
> option.
>
> re,
>  wh
> 
> Von: Steffen Nurpmeso 
> Gesendet: Dienstag, 25. Mai 2021 02:40:50
> An: Walter Harms
> Cc: dropbear@ucc.asn.au
> Betreff: Re: restrict access
>
> WARNUNG: Diese E-Mail kam von außerhalb der Organisation. Klicken Sie nicht 
> auf Links oder öffnen Sie keine Anhänge, es sei denn, Sie kennen den/die 
> Absender*in und wissen, dass der Inhalt sicher ist.
>
>
> Walter Harms wrote in
>  :
>  |I did a little experiment and it worked.
>  |
>  | if (fnmatch("192.168.1.*",remote_host,FNM_PATHNAME) != 0)
>  |   goto out;
>  |
>  |this will allow only connections from 192.168.1.* to the server
>  |that shows the change can be very simple. I did not try with more compli\
>  |cated situations. The limits of this approach needs to be evaluated.
>
> Since the begin of this thread this sounds like a 100% firewall
> thing to me.  Why would you like to compile this in?
>
> I mean, i can imagine the NetBSD/FreeBSD black(now block)list
> approach in which a server software who "knows" what has happened
> acts via a hook instead of let some expensive log parser
> reevaluate state which is known in the moment the log happens.
>
> But this?  I am not an administrator and thus firewall guru, but
> i for example have in my net-qos.sh:fwcore_start() (heavily
> vaporised this is)
>
>change_chain INPUT
>new_chain i_good i_alien i_sshorvpn i_tcp_new
>
>add_rule -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
>
>add_rule -j i_good
>add_rule -j i_alien
>
>add_rule -p tcp --syn -m conntrack --ctstate NEW -j i_tcp_new
>
>change_chain i_tcp_new
>
>fwcore_has_i ssh && add_rule -p tcp --dport ${p_ssh} -j i_sshorvpn
>
>change_chain i_sshorvpn
>
> So and in here you can allow or deny ssh-specific anyway you want
> to, add, remove and change, use "-m recent" and hitcounts etc.,
> and all without recompilation.  (Having real address and/or CIDR
> tables which could be managed separately would be cool though.)
>
> --steffen
> |
> |Der Kragenbaer,The moon bear,
> |der holt sich munter   he cheerfully and one by one
> |einen nach dem anderen runter  wa.ks himself off
> |(By Robert Gernhardt)

Re: restrict access

[Hans Harder]

You can add some small code  in svr_main.c for allowing/denying remote
servers based on their ip address

getaddrstring(, _host, NULL, 0);
/* HH hostallow start */
   /* Check if remote host is allowed */
if (hostallow_check(remote_host) == 0) {
fprintf(stderr,"Not allowed, closing connection\n");
goto out;
}
/* HH hostallow end */
/* Limit the number of unauthenticated
connections per IP */
num_unauthed_for_addr = 0;
num_unauthed_total = 0;
for (j = 0; j < MAX_UNAUTH_CLIENTS; j++) {

just add something like this in svr_main.c in the  the main_noinetd function
I check in the hostallow_check function if there is a certain file
like  host_.allow in a certain directory
if not it will close the connection.

Hans


On Thu, May 20, 2021 at 5:05 PM Sebastian Gottschall
 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: multiuser disabled - fail more gracefully

[Hans Harder]

Indeed that is the correct question, because you can easily do

#if DROPBEAR_SVR_MULTIUSER
   if (getuid() != ses.authstate.pw_uid) {
  setgid and setuid part
   }
#endif


On Wed, Mar 10, 2021 at 11:41 AM Geoff Winkless  wrote:
>
> On Tue, 9 Mar 2021 at 15:43, Kazuo Kuroi  wrote:
> > That's a good suggestion. but I suggest that if your code can't run on
> > UNIX platforms that it would need an include guard against it.
>
> I completely understand your concern.
>
> I would hope that the changes would be system-agnostic: the idea would
> merely be that if the setgroups (or indeed setuid) call fails, it
> checks if the current running user is the same as the login user and
> ignores the failure if so.
>
> It could be simplified further by just skipping all the setuid and
> setgroup code if the login user is the same as the running user, but
> I'm not sure if that would always be acceptable (there may be some
> systems where the group calls need to be made even if the users are
> the same?) so I thought it would be best to add the check after
> failure.
>
> Geoff

Re: [PATCH] Introduce extra delay before closing unauthenticated sessions

[Hans Harder]

The change is also by putting a delay in the connection close it is
going to work against you.
Suppose this happens constantly, will you be able to make a valid connection ?

I use a different approach, allow only a fix src ip access and drop
any other connection.
You can do that with iptables, so dropbear gets only connection
request from valid ip's

Hans

On Tue, Jan 26, 2021 at 11:38 AM Thomas De Schampheleire
 wrote:
>
> Hi Matt,
>
> El dom, 24 ene 2021 a las 14:30, Matt Johnston () escribió:
> >
> > On Wed 20/1/2021, at 8:15 pm, Thomas De Schampheleire 
> >  wrote:
> > >
> > >> # HG changeset patch
> > >> Introduce extra delay before closing unauthenticated sessions
> > >
> > > Any comments on this patch?
> > >
> >
> > Hi Thomas,
> >
> > Sorry for the delay getting back to you. I've applied the patch, it seems 
> > like it could be good as a simple brute force countermeasure. I'm sure a 
> > lot of the SSH bots are using varying source IPs from botnets etc, but 
> > there doesn't seem much harm in an extra delay.
>
> For batch login attempts from multiple IPs, there are already some
> existing options:
>
> /* Specify the number of clients we will allow to be connected but
>  * not yet authenticated. After this limit, connections are rejected */
> /* The first setting is per-IP, to avoid denial of service */
> #define MAX_UNAUTH_PER_IP 5
>
> /* And then a global limit to avoid chewing memory if connections
>  * come from many IPs */
> #define MAX_UNAUTH_CLIENTS 30
>
> So per IP, you have only 5 simultaneous attempts. Globally there is a
> max of 30, meaning 6 clients can attempt 5 simultaneous attempts.
> With the new extra delay, this means that these 30 connection slots
> will be held for 30 seconds, which should reduce the effectiveness of
> an attack greatly.
> It does mean that legitimate attempts may also be blocked for a while,
> but I think this basically already happens today although that block
> is shorter.
> Would you agree?
>
> >
> > I'll add an option to disable it at runtime just in case it ends up causing 
> > problems (resource usage of waiting connections would be my concern).
>
> Sure, thanks.
>
> Best regards,
> Thomas

Re: MIN_RSA_KEYLEN compare goes wrong

[Hans Harder]

Hi Matt,

It was a key generated with an old version of ssh-keygen, and then
converted to dropbear format.
The public key length shows 1024 bits with ssh-keygen -l

When I use this private key with dropbear it issued the warning that
the  key was < MIN_RSA_KEYLEN
In dropbear the keylen was reported by function mp_count_bits as 1023

I worked around it by adapting the MIN_RSA_KEYLEN to 1023 and did a recompile..
It is not problematic...


Hans

On Thu, Oct 29, 2020 at 1:21 PM Matt Johnston  wrote:
>
> Hi Hans,
>
> Sorry I missed replying to this message a while ago.
>
> What program created the key? As far as I can tell the test
> is correct, the top bit might be unset?
>
> Cheers,
> Matt
>
> On Thu, Aug 27, 2020 at 07:36:26AM +0200, Hans Harder wrote:
> > HI,
> >
> > I noticed that I got warnings that the RSA key was too short.
> > Further investigation showed that I was using a 1024 bits RSA key but
> > the mp_count_bits function return 1023 count (probably 0 based)
> >
> > in rsa.c  it states:if (mp_count_bits(key->n) < MIN_RSA_KEYLEN)
> >
> > Is this intentional  or should I just define the MIN_RSA_KEYLEN as
> > 1023 instead of the 1024 now in sysoptions.h
> >
> > Hans

MIN_RSA_KEYLEN compare goes wrong

[Hans Harder]

HI,

I noticed that I got warnings that the RSA key was too short.
Further investigation showed that I was using a 1024 bits RSA key but
the mp_count_bits function return 1023 count (probably 0 based)

in rsa.c  it states:if (mp_count_bits(key->n) < MIN_RSA_KEYLEN)

Is this intentional  or should I just define the MIN_RSA_KEYLEN as
1023 instead of the 1024 now in sysoptions.h

Hans

Re: Dropbear 2020.79

[Hans Harder]

Does anybody have an example of the external public-key authentication api
Sounds interesting, but I am not sure how to use this...

thx
Hans

On Mon, Jun 15, 2020 at 5:53 PM Matt Johnston  wrote:

> Hi all,
>
> Dropbear 2020.79 is now released. Particular thanks to Vladislav Grishenko
> for adding ed25519 and chacha20-poly1305 support which have
> been wanted for a while.
>
> This release also supports rsa-sha2 signatures which will be
> required by OpenSSH in the near future - rsa with sha1 will
> be disabled. This doesn't require any change to
> hostkey/authorized_keys files.
>
> Required versions of libtomcrypt and libtommath have been
> increased, if the system library is older Dropbear can use
> its own bundled copy.
>
> As usual downloads are at
> https://matt.ucc.asn.au/dropbear/dropbear.html
> https://mirror.dropbear.nl/mirror/dropbear.html
>
> Cheers,
> Matt
>
> 2020.79 - 15 June 2020
>
> - Support ed25519 hostkeys and authorized_keys, many thanks to Vladislav
> Grishenko.
>   This also replaces curve25519 with a TweetNaCl implementation that
> reduces code size.
>
> - Add chacha20-poly1305 authenticated cipher. This will perform faster
> than AES
>   on many platforms. Thanks to Vladislav Grishenko
>
> - Support using rsa-sha2 signatures. No changes are needed to
> hostkeys/authorized_keys
>   entries, existing RSA keys can be used with the new signature format
> (signatures
>   are ephemeral within a session). Old ssh-rsa signatures will no longer
>   be supported by OpenSSH in future so upgrading is recommended.
>
> - Use getrandom() call on Linux to ensure sufficient entropy has been
> gathered at startup.
>   Dropbear now avoids reading from the random source at startup, instead
> waiting until
>   the first connection. It is possible that some platforms were running
> without enough
>   entropy previously, those could potentially block at first boot
> generating host keys.
>   The dropbear "-R" option is one way to avoid that.
>
> - Upgrade libtomcrypt to 1.18.2 and libtommath to 1.2.0, many thanks to
> Steffen Jaeckel for
>   updating Dropbear to use the current API. Dropbear's configure script
> will check
>   for sufficient system library versions, otherwise using the bundled
> versions.
>
> - CBC ciphers, 3DES, hmac-sha1-96, and x11 forwarding are now disabled by
> default.
>   They can be set in localoptions.h if required.
>   Blowfish has been removed.
>
> - Support AES GCM, patch from Vladislav Grishenko. This is disabled by
> default,
>   Dropbear doesn't currently use hardware accelerated AES.
>
> - Added an API for specifying user public keys as an authorized_keys
> replacement.
>   See pubkeyapi.h for details, thanks to Fabrizio Bertocci
>
> - Fix idle detection clashing with keepalives, thanks to jcmathews
>
> - Include IP addresses in more early exit messages making it easier for
> fail2ban
>   processing. Patch from Kevin Darbyshire-Bryant
>
> - scp fix for CVE-2018-20685 where a server could modify name of output
> files
>
> - SSH_ORIGINAL_COMMAND is set for "dropbear -c" forced command too
>
> - Fix writing key files on systems without hard links, from Matt Robinson
>
> - Compatibility fixes for IRIX from Kazuo Kuroi
>
> - Re-enable printing MOTD by default, was lost moving from options.h.
> Thanks to zciendor
>
> - Call fsync() is called on parent directory when writing key files to
> ensure they are flushed
>
> - Fix "make install" for manpages in out-of-tree builds, from Gabor Z. Papp
>
> - Some notes are added in DEVELOPER.md
>
>

Re: dropbear and new host keys?

[Hans Harder]

>   The bigger issue here is why not reread keys at every new session? That
seems to like the right thing to do in any case?

Performance...
Why should you do that.
You should not change your host keys everytime, because the connecting
client will have a conflict and get a warning about a possible man in the
middle attack because it cannot verify the host since the hostkey is
changed.

Simple way is to generate the new hostkeys, kill the main dropbear and
start it again.
Should be a very simple script...  and the current running sessions are not
affected.

Hans


On Thu, Dec 12, 2019 at 2:58 PM Joakim Tjernlund <
joakim.tjernl...@infinera.com> wrote:

> On Thu, 2019-12-12 at 13:31 +, Geoff Winkless wrote:
> >
> > On Wed, 11 Dec 2019 at 17:00, Joakim Tjernlund
> >  wrote:
> > > In out case we cannot just restart dropbear and rebooting just for new
> keys is not an option either.
> > > Could dropbear gain automatic reread of keys ?
> >
> > You know if you kill the parent process the child processes keep
> > running? So you can restart it without disconnecting everyone.
>
> Yes, but in our case dropbear start/stop script is connected with several
> other daemons, but yes it can be
> worked around.
>
> The bigger issue here is why not reread keys at every new session? That
> seems to like the
> right thing to do in any case?
>
>  Jocke
>

verbose level of trace information

[Hans Harder]

I usually build the version without trace information, until I run
into troubles.
Then when building the trace version it gives out too much infomation.

Ever thought about given out limited trace information depending on
the number of -v given...

So basicly whenever I face a connection problem, I need to know:
verbose level 1:
- can it reach the destination
- what is the remote sshd version
- what kind of authorizations are enabled
- which authorisations fail or succeed
verbose level 2:
- know the selected algoritme, hmac and compression
verbose level 3
- available algoritmes, hmacs on both client and server
verbose level 4
- anything else

Maybe each level should be enabled optional during build time, so
level 2-4 can be left out to reduce the build size.

Is it interesting to receive patches for this ?

Hans


examples:
dropbear-git# ./dbclient -v  test@192.168.1.5
TRACE  (23078) 0.00: user='test' host='192.168.1.5' port='22'
TRACE  (23078) 0.000124: enter session_init
TRACE  (23078) 0.012324: remoteident: SSH-2.0-dropbear_2017.75
TRACE  (23078) 0.102050: Methods (len 18): 'publickey,password'
TRACE  (23078) 0.102099: auth method 'publickey' valid
TRACE  (23078) 0.102141: auth method 'password' valid
TRACE  (23078) 0.102165: try  auth method publickey
TRACE  (23078) 0.102205: try  auth method password
test@192.168.1.5's password:
TRACE  (23078) 3.399641: leave cli_auth_try success
testhost:~$

dropbear-git# ./dbclient -v -v  test@192.168.1.5
TRACE  (23085) 0.00: user='test' host='192.168.1.5' port='22'
TRACE  (23085) 0.000166: enter session_init
TRACE  (23085) 0.012650: remoteident: SSH-2.0-dropbear_2017.75
TRACE  (23085) 0.012831: kex algo curve25519-sha...@libssh.org
TRACE  (23085) 0.012890: hostkey algo ssh-rsa
TRACE  (23085) 0.012945: enc  c2s is aes128-ctr
TRACE  (23085) 0.013044: enc  s2c is aes128-ctr
TRACE  (23085) 0.013101: hmac c2s is hmac-sha1
TRACE  (23085) 0.013195: hmac s2c is hmac-sha1
TRACE  (23085) 0.013263: comp c2s is z...@openssh.com
TRACE  (23085) 0.013360: comp s2c is z...@openssh.com
TRACE  (23085) 0.105168: enter cli_auth_getmethods
TRACE  (23085) 0.106062: Methods (len 18): 'publickey,password'
TRACE  (23085) 0.106119: auth method 'publickey' valid
TRACE  (23085) 0.106217: auth method 'password' valid
TRACE  (23085) 0.106274: enter cli_auth_try
TRACE  (23085) 0.106337: try  auth method publickey
TRACE  (23085) 0.106436: try  auth method password
test@192.168.1.5's password:
TRACE  (23085) 4.383544: cli_auth_try lastauthtype 4
TRACE  (23085) 4.383631: leave cli_auth_try success
TRACE  (23085) 4.419022: received msg_userauth_success
testhost:~$

Re: combining multihop and -J command for proxy connect

[Hans Harder]

Underneath the patch against the current git version
Hans

diff -w dropbear-git/cli-runopts.c dropbear-patch/cli-runopts.c
--- dropbear-git/cli-runopts.c
+++ dropbear-patch/cli-runopts.c
@@ -629,9 +629,7 @@
/* Set up the proxycmd */
unsigned int cmd_len = 0;
char *passthrough_args = multihop_passthrough_args();
-   if (cli_opts.proxycmd) {
-   dropbear_exit("-J can't be used with multihop mode");
-   }
+   char *pproxycmd = NULL;
if (cli_opts.remoteport == NULL) {
cli_opts.remoteport = "22";
}
@@ -639,14 +637,27 @@
+ strlen(cli_opts.remotehost) +
strlen(cli_opts.remoteport)
+ strlen(passthrough_args)
+ 30;
+   /* if proxycmd is filled, pass it also with every exec */
+   if (cli_opts.proxycmd) {
+   int proxylen = strlen(cli_opts.proxycmd) + 10;
+   /* save original proxycmd to insert in new cmd */
+   pproxycmd = m_malloc(proxylen);
+   snprintf(pproxycmd,proxylen,"-J \"%s\"
",cli_opts.proxycmd);
+   cli_opts.proxycmd = NULL;
+   /* increase cmd_len with proxycmd length */
+   cmd_len += proxylen;
+   }
cli_opts.proxycmd = m_malloc(cmd_len);
-   snprintf(cli_opts.proxycmd, cmd_len, "%s -B %s:%s %s %s",
-   argv0, cli_opts.remotehost, cli_opts.remoteport,
-   passthrough_args, remainder);
+   snprintf(cli_opts.proxycmd, cmd_len, "%s %s-B %s:%s %s %s",
+   argv0, (pproxycmd)?pproxycmd:"",
+   cli_opts.remotehost,
cli_opts.remoteport, passthrough_args, remainder);
 #ifndef DISABLE_ZLIB
/* The stream will be incompressible since it's encrypted. */
opts.compress_mode = DROPBEAR_COMPRESS_OFF;
 #endif
+   if (pproxycmd) {
+   m_free(pproxycmd);
+   }
m_free(passthrough_args);
}
m_free(hostbuf);

combining multihop and -J command for proxy connect

[Hans Harder]

I have to do a multihop behind after a proxy connect...

so I do something like:
dbclient -J "corkscrew proxyserver proxyport makado 22"  user@makado
,user@canyons

but I get the message :   Exited: -J can't be used with multihop mode

Basicly what I see in cli-runopts.c that if multihop is detected it
prevents that -J is used, because multihop uses itself the -J option...
Any suggestion how I get this working ?

Hans

dropbear as ssh honeypot

[Hans Harder]

Hi Matt,

I was looking for a SSH honeypot... so I thought about adapting dropbear.

Seems to me it would be easy to disable any successfull logins by adapting
the
file svr_auth.c  with

/* Send a success message to the user, and set the "authdone" flag */
void send_msg_userauth_success() {

#if DROPBEAR_SVR_HONEYPOT
send_msg_userauth_failure(0, 1);
#else
... original code
#endif
}

Is it really that easy to prevent any logins like that or am I forgetting
something.

I prefer dropbear besides all the other ssh honeypot implementations,
because I already use dropbear and I know the code

Hans

Running dropbear as non root daemon

[Hans Harder]

configured with:
./configure  --disable-pam --disable-syslog --disable-shadow \
 --disable-lastlog --disable-utmp --disable-utmpx \
 --disable-wtmp --disable-wtmpx --disable-loginfunc \
 --disable-pututline --disable-pututxline


For Linux:   no problems

For AIX:

I could not get dropbear run as a normal user with the generated config.h
After changes in sshpty.c I got it working for AIX, basicly it does now:

master = open ("/dev/ptc", O_RDWR | O_NOCTTY);
if (grantpt (master))   goto fail;
if (unlockpt (master))  goto fail;
slave_name = ptsname (master);
slave = open (slave_name, O_RDWR | O_NOCTTY);
if (termp) tcsetattr (slave, TCSAFLUSH, termp);
if (winp)  ioctl (slave, TIOCSWINSZ, winp);

I also disabled the pty_release function which otherwise fails changing the
ownership back to root
After this, you can run dropbear as a normal user.


For HPux:
Compiles fine, but when running dropbear and connecting to it:
-  getnameinfo() in netio.c   failed lookup: address family was not
recognised
   using NI_NUMERICHOST | NI_NUMERICSERV   so without host_lookup
-  pty error, after open on /dev/ptmx fails on grandpt  even when before
that doing a signal SIGCHLD to SiG_DFL

Unable to get it working on HPux
If someone has got dropbear working on HPux, some help will be appreciated.

Hans

Re: Running Dropbear Without Root Permissions

[Hans Harder]

I have it running as a separate daemon on a few systems as a non root user
without problems..
I changed the config.h to disable all the features which might require more
rights than the user has or uses OS functions  for instance
 DISABLE_PAM, DISABLE_LASTLOG,  DISABLE_SYSLOG
I only use the user daemon with ssh keys...

Also I changed the locations of all the needed files to a local locaition
for instance in the options.h file  where the hostkeys are located
 (removed the /etc path from it)

That should make it work I believe


Hans


On Fri, Jun 10, 2016 at 10:43 AM, Nixon, Kent W  wrote:

> Hi all,
>
> I'm currently testing my (default) compile settings of dropbear 2016.73 on
> an x86_64 Ubuntu 14.04 machine. I'm running the dropbear server from the
> terminal of a standard user account and attempting to connect using
> dbclient as that same user from the same machine just to test/learn how to
> use dropbear before I attempt to cross-compile it and run it on an Android
> system.
>
> I currently run the following command to start the server:
>
> dropbear -F -p  -E -R -m
>
> And attempt to connect (using the same machine) as the same user that is
> running dropbear using:
>
> dbcleint -p  -y @127.0.0.1
>
> Everything seems to work well, except that after I enter the appropriate
> password, the client is rejected by the server which posts the message:
>
> User account '' is locked
>
> However, following the same steps as above, but running the dropbear
> server with root permissions, everything works as expected (i.e. I am able
> to open a remote shell without any problems).
>
> What changes when dropbear is run with standard user permissions that is
> causing the account to be 'locked'? Do I need to locate the rsa/dss/ecdsa
> keys somewhere else other than /etc/dropbear/?
>
> Thanks in advance for your time and consideration!
>
> ~ Kent
>

X11 forwarding in dbclient

[Hans Harder]

How difficult is it to get X11 forwarding in the dbclient.

currently I only have it working when using openssh with -X option.
But because of multihop (more than 2 hops)  I have to use dbclient, but it
doesn't support X11 forwarding.

thx

Hans

[Patch] Restricting access to certain ip numbers.

[Hans Harder]

Perhaps not something to have default in dropbear, put perhaps of interest
for someone...

In order to restrict  access from certain ip addresses only, you can, with
this patch, start a dropbear with option -S
This will only allow password logins if a corresponding file
/etc/dropbear/ip_ipnumber_any.allow exists.

It will also check for /etc/dropbear/ip_ipnumber_username.allow for
granting access to specific usernames only

If you start dropbear with -S -S  it will also use this restriction for
pubkey validation

Example:
# blocking password and pubkey from unknown locations, using a valid pubkey
root@core ~# ./dropbear -S -S  -F  -p 2022
[24472] Oct 04 12:30:21 Not backgrounding
[24473] Oct 04 12:30:40 Child connection from :::192.168.1.10:49799
[24473] Oct 04 12:30:40 Exit before auth (user 'root', 0 fails): Remote
address :::192.168.1.10:49799 is not allowed to connect with public key
or password

# blocking password from unknown locations, using a valid pubkey
root@core ~# ./dropbear -S   -F  -p 2022
[24486] Oct 04 12:30:55 Not backgrounding
[24487] Oct 04 12:31:10 Child connection from :::192.168.1.10:49801
[24487] Oct 04 12:31:11 Pubkey auth succeeded for 'root' with key md5
14:07:9a:1d:d9:64:45:db:88:d8:78:62:45:1e:88:21 from :::
192.168.1.10:49801

# blocking password from unknown locations, using a valid password
root@core ~# ./dropbear -S   -F  -p 2022
[24551] Oct 04 12:31:25 Not backgrounding
[24552] Oct 04 12:32:06 Child connection from :::192.168.1.10:49802
[24552] Oct 04 12:32:09 IP access denied : file
/etc/dropbear/ip_192.168.1.10_root.allow not found
[24552] Oct 04 12:32:09 IP access denied : file
/etc/dropbear/ip_192.168.1.10_any.allow not found
[24552] Oct 04 12:32:09 Exit before auth (user 'root', 0 fails): Remote
address :::192.168.1.10:49802 is not allowed to connect with password

# grant  connections for root from 192.168.1.10, using a valid publickey
root@core ~# touch /etc/dropbear/ip_192.168.1.10_root.allow
root@core ~# ./dropbear -S -S  -F  -p 2022
[24578] Oct 04 12:33:02 Not backgrounding
[24579] Oct 04 12:33:20 Child connection from :::192.168.1.10:49803
[24579] Oct 04 12:33:20 IP access allowed : file
/etc/dropbear/ip_192.168.1.10_root.allow found
[24579] Oct 04 12:33:20 Pubkey auth succeeded for 'root' with key md5
14:07:9a:1d:d9:64:45:db:88:d8:78:62:45:1e:88:21 from :::
192.168.1.10:49803


Have fun with it...

Hans
--- ../dropbear-2014.65/options.h   2014-09-11 02:37:28.0 -0600
+++ options.h   2014-10-04 01:28:55.0 -0600
@@ -20,6 +20,10 @@
 #endif
 
 /* Default hostkey paths - these can be specified on the command line */
+#ifndef CONFIG_DIRECTORY
+#define CONFIG_DIRECTORY /etc/dropbear
+#endif
+/* Default hostkey paths - these can be specified on the command line */
 #ifndef DSS_PRIV_FILENAME
 #define DSS_PRIV_FILENAME /etc/dropbear/dropbear_dss_host_key
 #endif
--- ../dropbear-2014.65/runopts.h   2014-08-08 07:40:47.0 -0600
+++ runopts.h   2014-10-04 01:25:22.0 -0600
@@ -87,6 +87,7 @@ typedef struct svr_runopts {
 
int norootlogin;
 
+   int restrictlogins;
int noauthpass;
int norootpass;
int allowblankpass;
--- ../dropbear-2014.65/svr-runopts.c   2014-08-08 07:40:47.0 -0600
+++ svr-runopts.c   2014-10-04 02:58:05.0 -0600
@@ -68,6 +68,7 @@ static void printhelp(const char * progn
-m Don't display the motd 
on login\n
 #endif
-w Disallow root logins\n
+   -S Enable logins from 
restricted addresses\n
 #if defined(ENABLE_SVR_PASSWORD_AUTH) || defined(ENABLE_SVR_PAM_AUTH)
-s Disable password 
logins\n
-g Disable password logins 
for root\n
@@ -127,6 +128,7 @@ void svr_getopts(int argc, char ** argv)
svr_opts.forkbg = 1;
svr_opts.norootlogin = 0;
svr_opts.noauthpass = 0;
+   svr_opts.restrictlogins = 0;
svr_opts.norootpass = 0;
svr_opts.allowblankpass = 0;
svr_opts.inetdmode = 0;
@@ -244,6 +246,9 @@ void svr_getopts(int argc, char ** argv)
case 'I':
next = idle_timeout_arg;
break;
+   case 'S':
+   svr_opts.restrictlogins++;
+   break;
 #if defined(ENABLE_SVR_PASSWORD_AUTH) || defined(ENABLE_SVR_PAM_AUTH)
case 's':
svr_opts.noauthpass = 1;
--- ../dropbear-2014.65/svr-auth.c  2014-08-08 07:40:47.0 -0600
+++ svr-auth.c  2014-10-04 05:35:21.0 -0600
@@ -79,6 +79,46 @@ static void authclear() {

 }
 
+/* check if a file  ip_ipnumber_user.allow 

Problems when connecting to dropbear server running as non-root

[Hans Harder]

I am trying to connect using ssh: -v -i privkey -p 7000 hans@host hostname
And I get:

debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending command: hostname
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
[28924] Jul 15 17:40:24 Exit (hans): Couldn't change user as non-root
TRACE  (28924) 1373910024.524936: enter session_cleanup
TRACE  (28924) 1373910024.525004: enter chancleanup
TRACE  (28924) 1373910024.525021: channel 0 closing
TRACE  (28924) 1373910024.525037: enter remove_channel
TRACE  (28924) 1373910024.525050: channel index is 0


Dropbear is running on the host as a non-root user hans with  dropbear -v
-F -P 7000  and gives (small part)

TRACE  (28923) 1373910024.518919: enter recv_msg_channel_request 0x82ca4e8
TRACE  (28923) 1373910024.518942: enter chansessionrequest
TRACE  (28923) 1373910024.518961: type is exec
TRACE  (28923) 1373910024.519100: enter sessioncommand
TRACE  (28923) 1373910024.519138: enter noptycommand
TRACE  (28923) 1373910024.519370: setnonblocking: 8
TRACE  (28923) 1373910024.519411: leave setnonblocking
TRACE  (28923) 1373910024.519429: setnonblocking: 7
TRACE  (28923) 1373910024.519451: leave setnonblocking
TRACE  (28923) 1373910024.519475: setnonblocking: 10
TRACE  (28923) 1373910024.519497: leave setnonblocking
TRACE  (28924) 1373910024.519758: back to normal sigchld
TRACE  (28923) 1373910024.525685: enter sigchld handler
TRACE  (28923) 1373910024.525735: sigchld handler: pid 28924
TRACE  (28923) 1373910024.525761: using lastexit
TRACE  (28923) 1373910024.525811: leave sigchld handler
TRACE  (28923) 1373910024.525836: parent side: lastexitpid is 28924
TRACE  (28923) 1373910024.525857: found match for lastexitpid
TRACE  (28923) 1373910024.525876: leave noptycommand
TRACE  (28923) 1373910024.525905: leave chansessionrequest
TRACE  (28923) 1373910024.525925: leave recv_msg_channel_request
TRACE  (28923) 1373910024.525945: sesscheckclose, pid is 28924
TRACE  (28923) 1373910024.525999: sesscheckclose, pid is 28924
TRACE  (28923) 1373910024.526022: might send data, flushing
TRACE  (28923) 1373910024.526041: send data readfd
TRACE  (28923) 1373910024.526060: enter send_msg_channel_data
TRACE  (28923) 1373910024.526080: enter send_msg_channel_data isextended 0
fd 8
TRACE  (28923) 1373910024.526104: maxlen 16375
TRACE  (28923) 1373910024.526127: CLOSE some fd 8
TRACE  (28923) 1373910024.526154: leave send_msg_channel_data: len 0 read
err 4 or EOF for fd 8
TRACE  (28923) 1373910024.526183: send data errfd
TRACE  (28923) 1373910024.526202: enter send_msg_channel_data
TRACE  (28923) 1373910024.526220: enter send_msg_channel_data isextended 1
fd 10
TRACE  (28923) 1373910024.526245: maxlen 16371
TRACE  (28923) 1373910024.526269: send_msg_channel_data: len 761 fd 10
TRACE  (28923) 1373910024.526338: closing from channel, flushing out.
TRACE  (28923) 1373910024.526360: CLOSE some fd 10

On 2 other boxes it works perfectly, so there is something on this host
which is breaking it...

Anybody got a hint where to look for.

thx
Hans

Patch for usermode server

[Hans Harder]

Added check that only the dropbear user is allowed to login if it is
running as non-root.
Removed the log message,



--- loginrec.c 2013-04-15 08:01:58.0 -0600
+++ loginrec.c 2013-04-17 06:01:57.0 -0600
@@ -329,8 +329,6 @@ login_write (struct logininfo *li)
 {
 #ifndef HAVE_CYGWIN
if ((int)geteuid() != 0) {
- dropbear_log(LOG_WARNING,
- Attempt to write login records by non-root
user (aborting));
  return 1;
}
 #endif
--- svr-auth.c 2013-04-15 08:01:58.0 -0600
+++ svr-auth.c 2013-04-17 06:00:22.0 -0600
@@ -226,6 +226,7 @@ static int checkusername(unsigned char *

char* listshell = NULL;
char* usershell = NULL;
+   int   uid;
TRACE((enter checkusername))
if (userlen  MAX_USERNAME_LEN) {
return DROPBEAR_FAILURE;
@@ -255,6 +256,18 @@ static int checkusername(unsigned char *
return DROPBEAR_FAILURE;
}

+   /* check if we are running as non-root, and login user is
different from the server */
+   uid=geteuid();
+   if (uid != 0  uid != ses.authstate.pw_uid) {
+   TRACE((running as nonroot, only server uid is allowed))
+   dropbear_log(LOG_WARNING,
+   Login attempt with wrong user %s from %s,
+   ses.authstate.pw_name,
+   svr_ses.addrstring);
+   send_msg_userauth_failure(0, 1);
+   return DROPBEAR_FAILURE;
+   }
+
/* check for non-root if desired */
if (svr_opts.norootlogin  ses.authstate.pw_uid == 0) {
TRACE((leave checkusername: root login disabled))

Patch multihop scp with different ports

[Hans Harder]

I had some problems with the multihop for scp using different portnumbers.
The original syntax uses / as separator, which conflicts with the
current code in scp for detecting source and destination
Ex.  scp file user@host1/,user@host2/22:.

Simplest way of solvng this was to allow also another char as
separator for a port, like '#'
So you can do: scp file user@host1#,user@host2#22:.

Just a one liner, which allows now to use both chars as a separator


--- cli-runopts.c  2013-04-15 08:01:57.0 -0600
+++ cli-runopts.c  2013-04-17 06:14:56.0 -0600
@@ -611,6 +611,7 @@ static void parse_hostname(const char* o
}

port = strchr(cli_opts.remotehost, '/');
+if (!port)  port = strchr(cli_opts.remotehost, '#');
if (port) {
*port = '\0';
cli_opts.remoteport = port+1;