Martin Donnelly | 2 May 12:44 2013
Picon

[PATCH] Notify clients of PAM error messages

This patch adds support for relaying PAM_ERROR_MSG to clients. This
is useful when PAM_ERROR_MSG returns meaningful information, an
example of this is when pam_nologin is being used and '/etc/nologin'
contains a message for clients attempting to connect.

-Martin
diff -ubNr dropbear-2013.58.orig/auth.h dropbear-2013.58/auth.h
--- dropbear-2013.58.orig/auth.h	2013-04-18 15:58:14.000000000 +0100
+++ dropbear-2013.58/auth.h	2013-04-30 17:37:33.317480220 +0100
 <at>  <at>  -36,6 +36,7  <at>  <at> 
 void recv_msg_userauth_request();
 void send_msg_userauth_failure(int partial, int incrfail);
 void send_msg_userauth_success();
+void send_msg_userauth_banner(buffer **msg);
 void svr_auth_password();
 void svr_auth_pubkey();
 void svr_auth_pam();
diff -ubNr dropbear-2013.58.orig/common-session.c dropbear-2013.58/common-session.c
--- dropbear-2013.58.orig/common-session.c	2013-04-18 15:58:14.000000000 +0100
+++ dropbear-2013.58/common-session.c	2013-05-01 15:55:20.687368142 +0100
 <at>  <at>  -122,6 +122,8  <at>  <at> 

 	ses.allowprivport = 0;

+	ses.pam_err = NULL;
+
 	TRACE(("leave session_init"))
 }
(Continue reading)

Christopher Meng | 13 May 11:27 2013
Picon

Add support for aarch64

Hi,

As dropbear doesn't support AArch64, I hope the author can do something in order to fix it. In fact I'm the packager of dropbear, some users asked us why not support aarch64.


To fix this, you can:

1. Use at least autoconf 2.69 to reconfigure.
2. A patch at 


which updates config.guess and config.sub to recognize aarch64.

But I think the latter one is for downstream to include it into the package, for upstream, will you fix this?

Thanks!



Yours sincerely,
Christopher Meng

Always playing in Fedora Project
Yuan-Yi Chang | 3 May 08:44 2013
Picon

A solution for PAM with nonexistent user

Hi, 


After configured with --enable-pam and modified the option.h:

//#define ENABLE_SVR_PASSWORD_AUTH
#define ENABLE_SVR_PAM_AUTH

The Dropbear would be with the PAM functionality.

When I used the PAM module to pass the account login flow, but I got the message: "Login attempt for nonexistent user". I know there should be a white list for most popular applications, I still think there is another way for convenience usage on Dropbear.

There is a patch for choose a system account for nonexistent user at PAM mode (The coding style of this patch may not good enough):

$ /path/dropbear -h
...
-c username choose a system account for nonexistent user at PAM mode
...

$ cat /etc/pam.d/sshd
auth required /path/pam_myway.so
account required /path/pam_myway.so
$ /path/dropbear -p 222 -r /path/testkey -c root -E -F

If login account is nonexistent user, it would choose "root" account to use.

Best Regards, 
Yuan-Yi Chang
Ed Sutter | 29 Apr 16:48 2013

Re: Performance testing ssh (was Re: question)

Yep, thanks, I've been running with WireShark...
(running it on the same machine as the client, so no need for mirroring 
here).
>
> Ed,
>
> I would also tcpdump all the network traffic during the test... using 
> a real hub or switch with port mirroring or vswitch promiscuous mode.
>
> At least then you could eliminate any lower level issues.
>
> Good luck.
>
> --
> http://www.realthought.net/
>
> El 26/04/2013 05:02, "Ed Sutter" <ed.sutter <at> alcatel-lucent.com 
> <mailto:ed.sutter <at> alcatel-lucent.com>> escribió:
>
>     Hi,
>     I have a modified version of the dropbear ssh server running in
>     a multitasking RTOS environment that is not POSIX compliant.
>     In almost all cases it is running perfectly...
>     I run load tests on it by just using a simple expect script
>     that spawns an ssh client and sends commands and expects
>     responses (in a loop).
>     If, within that loop, I occasionally (every ~30 minutes)
>     disconnect and reconnect then I can let that run *forever*
>     (haven't fully tested that).  :-(
>
>     The problem I run into is if I just make an initial connection
>     and put the script in a loop that simply keeps issuing commands
>     and responses (I never disconnect; just maintain the initial session).
>     After some unpredictable amount of time (usually it takes an hour or
>     more); having invoked a few thousand commands, suddenly everything
>     just stops.  The server is sitting in the select of the session_loop,
>     and the client (in the expect script) is just waiting for a response.
>
>     It seems like everything is where its supposed to be, but the client
>     is not able to send any characters to the server.  It appears that the
>     connection dropped; however, I'm fairly certain that it has not.
>
>     So, I apparently broke something; hence my question...
>
>     After the client/server transactions for key exchange,
>     login/password etc..
>     are complete and basically both sides are just passing encrypted
>     data back
>     and forth, is there any other periodic responsibility (on the
>     servers' part)
>     to issue any "keep-alive" type of commands (or something similar)
>     that I
>     have not implemented?
>
>     Thanks,
>     Ed
>

Kevin Johnson | 29 Apr 16:20 2013
Picon

segfault in svr-authpasswd.c

For users with locked accounts, dropbear segfaults on password
authentication. The call to crypt() with glibc 2.17 returns NULL if
the passwd field is '!'. Strcmp() segfaults on the NULL value. Here's
a patch against 2013.58 that adds a check.

--- svr-authpasswd.c.old
+++ svr-authpasswd.c
 <at>  <at>  -66,6 +66,12  <at>  <at> 
     m_burn(password, passwordlen);
     m_free(password);

+    if (testcrypt == NULL) {
+        dropbear_log(LOG_WARNING, "Crypt against user '%s' password
failed, rejected",
+                ses.authstate.pw_name);
+        send_msg_userauth_failure(0, 1);
+        return;
+    }
     /* check for empty password */
     if (passwdcrypt[0] == '\0') {
         dropbear_log(LOG_WARNING, "User '%s' has blank password, rejected",

--
thx,
Kevin Johnson

Ed Sutter | 25 Apr 20:57 2013

question

Hi,
I have a modified version of the dropbear ssh server running in
a multitasking RTOS environment that is not POSIX compliant.
In almost all cases it is running perfectly...
I run load tests on it by just using a simple expect script
that spawns an ssh client and sends commands and expects
responses (in a loop).
If, within that loop, I occasionally (every ~30 minutes)
disconnect and reconnect then I can let that run *forever*
(haven't fully tested that).  :-(

The problem I run into is if I just make an initial connection
and put the script in a loop that simply keeps issuing commands
and responses (I never disconnect; just maintain the initial session).
After some unpredictable amount of time (usually it takes an hour or
more); having invoked a few thousand commands, suddenly everything
just stops.  The server is sitting in the select of the session_loop,
and the client (in the expect script) is just waiting for a response.

It seems like everything is where its supposed to be, but the client
is not able to send any characters to the server.  It appears that the
connection dropped; however, I'm fairly certain that it has not.

So, I apparently broke something; hence my question...

After the client/server transactions for key exchange, login/password etc..
are complete and basically both sides are just passing encrypted data back
and forth, is there any other periodic responsibility (on the servers' part)
to issue any "keep-alive" type of commands (or something similar) that I
have not implemented?

Thanks,
Ed

Yuan-Yi Chang | 19 Apr 10:24 2013
Picon

About "DEFAULT_PATH" and "_PATH_SSH_PROGRAM" variables

Hi, 


I'm new to Embedded System World.  There are some problems, "scp not found", when I use dropbear-scp to copy some files. I trace the source code to find the DEFINE variables: DEFAULT_PATH & _PATH_SSH_PROGRAM.

Could we redefine it at configure or make process without modify the source code?

like that:
===
+#ifndef _PATH_SSH_PROGRAM
 #define _PATH_SSH_PROGRAM "/usr/bin/dbclient"
+#endif

+#ifndef DEFAULT_PATH
 #define DEFAULT_PATH "/usr/bin:/bin"
+#endif

and then:
===
$ ./configure
$ CFLAGS=' -D_PATH_SSH_PROGRAM="/path/dbclient" -DDDEFAULT_PATH="/usr/bin:/bin:/mnt/ubi_boot/bin"  ' make
$ CFLAGS=' -D_PATH_SSH_PROGRAM="/path/dbclient" -DDDEFAULT_PATH="/usr/bin:/bin:/mnt/ubi_boot/bin"  ' make scp


Best Regards, 
Yuan-Yi Chang
Jonathan Chetwynd | 19 Apr 10:20 2013

howto: send the X commands to the X server on your host.

does dbclient take a command similar to -X in ssh?
to send the X commands to the X server on your host.

if not is there a workaround or plans to implement?

kind regards

--

-- 
Jonathan Chetwynd
http://www.gnote.org
Eyetracking in HTML5

Matt Johnston | 18 Apr 17:10 2013
Picon
Picon

Dropbear 2013.58 released

Hi all,

I've put up a new release 2013.58 that fixes building
2013.57 without zlib, and a couple of other things
thanks to Hans Harder.

As usual https://matt.ucc.asn.au/dropbear/dropbear.html

Cheers,
Matt

2013.58 - Thursday 18 April 2013

- Fix building with Zlib disabled, thanks to Hans Harder and cuma <at> freetz

- Use % as a separator for ports, fixes scp in multihop mode, from Hans Harder

- Reject logins for other users when running as non-root, from Hans Harder

- Disable client immediate authentication request by default, it prevents
  passwordless logins from working

Hans Harder | 17 Apr 14:23 2013

Patch multihop scp with different ports

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 <at> host1/2222,user <at> 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 <at> host1#2222,user <at> 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.000000000 -0600
+++ cli-runopts.c  2013-04-17 06:14:56.000000000 -0600
 <at>  <at>  -611,6 +611,7  <at>  <at>  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;

Hans Harder | 17 Apr 14:12 2013

Patch for usermode server

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.000000000 -0600
+++ loginrec.c     2013-04-17 06:01:57.000000000 -0600
 <at>  <at>  -329,8 +329,6  <at>  <at>  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.000000000 -0600
+++ svr-auth.c     2013-04-17 06:00:22.000000000 -0600
 <at>  <at>  -226,6 +226,7  <at>  <at>  static int checkusername(unsigned char *

        char* listshell = NULL;
        char* usershell = NULL;
+       int   uid;
        TRACE(("enter checkusername"))
        if (userlen > MAX_USERNAME_LEN) {
                return DROPBEAR_FAILURE;
 <at>  <at>  -255,6 +256,18  <at>  <at>  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"))


Gmane