Patch for stricthostkey and a multihop fix
Underneath some modifications against a stock 2013.56 version
- Added -Y option to completely ignore check for hostkeys
Needed this for connections to logical hosts, same as openssh -o
StrictHostKeychecking=no
- Added -y and -Y in function multihop_passthrough_args
- fix: in function multihop_passthrough_args there was no space kept
between the -W and -i args
so added always a space after each added arg
after last addition the last space is removed.
I am new to the dropbear sources, so perhaps I didn't see it
correctlyif so please correct me...
Overall nice sourcecode, very clean.
Hans
---
Quote: ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
diff -ruBpN dropbear-2013.56/cli-kex.c work/cli-kex.c
--- dropbear-2013.56/cli-kex.c 2013-03-21 08:29:34.0 -0700
+++ work/cli-kex.c 2013-04-07 03:01:31.0 -0600
@@ -217,6 +217,11 @@ static void checkhostkey(unsigned char*
buffer * line = NULL;
int ret;
+ if (!cli_opts.strict_hostkey) {
+ TRACE(("strict_hostkey disabled, ignoring hostkey check"));
+ return;
+}
+
hostsfile = open_known_hosts_file(&readonly);
if (!hostsfile) {
ask_to_confirm(keyblob, keybloblen);
diff -ruBpN dropbear-2013.56/cli-runopts.c work/cli-runopts.c
--- dropbear-2013.56/cli-runopts.c 2013-03-21 08:29:34.0 -0700
+++ work/cli-runopts.c 2013-04-07 03:08:59.0 -0600
@@ -62,6 +62,7 @@ static void printhelp() {
"-NDon't run a remote command\n"
"-fRun in background after auth\n"
"-yAlways accept remote
host key if unknown\n"
+ "-YAlways ignore the
remote host key\n"
"-sRequest a subsystem
(use by external sftp)\n"
#ifdef ENABLE_CLI_PUBKEY_AUTH
"-i(multiple
allowed)\n"
@@ -130,6 +131,7 @@ void cli_getopts(int argc, char ** argv)
cli_opts.backgrounded = 0;
cli_opts.wantpty = 9; /* 9 means "it hasn't been touched",
gets set later */
cli_opts.always_accept_key = 0;
+ cli_opts.strict_hostkey = 1;
cli_opts.is_subsystem = 0;
#ifdef ENABLE_CLI_PUBKEY_AUTH
cli_opts.privkeys = list_new();
@@ -215,6 +217,9 @@ void cli_getopts(int argc, char ** argv)
case 'y': /* always accept the remote hostkey */
cli_opts.always_accept_key = 1;
break;
+ case 'Y': /* always ignore the remote hostkey */
+ cli_opts.strict_hostkey = 0;
+ break;
case 'p': /* remoteport */
next = &cli_opts.remoteport;
break;
@@ -461,20 +466,32 @@ multihop_passthrough_args() {
int total;
unsigned int len = 0;
m_list_elem *iter;
- /* Fill out -i and -W options that make sense for all
+ /* Fill out -i , -W, -y and -Y options that make sense for all
* the intermediate processes */
for (iter = cli_opts.privkeys->first; iter; iter = iter->next)
{
sign_key * key = (sign_key*)iter->item;
len += 3 + strlen(key->filename);
}
- len += 20; // space for -W , terminator.
+ len += 30; // space for -W , terminator.
ret = m_malloc(len);
total = 0;
+ if (cli_opts.always_accept_key)
+ {
+ int written = snprintf(ret+total, len-total, "-y ");
+ total += written;
+ }
+
+ if (cli_opts.strict_hostkey == 0)
+ {
+ int written = snprintf(ret+total, len-total, "-Y ");
+ total += written;
+ }
+
if (opts.recv_window != DEFAULT_RECV_WINDOW)
{
- int written = snprintf(ret+total, len-total, "-W %d",
opts.recv_window);
+ int written = snprintf(ret+total, len-total, "-W %d ",
opts.recv_window);
total += written;
}
@@ -482,11 +499,17 @@ multihop_passthrough_args() {
{
sign_key * key = (sign_key*)iter->item;
const size_t size = len - total;
- int written = snprintf(ret+total, size, "-i %s", key->filename);
+ int written = snprintf(ret+total, size, "-i %s ",
key->filename);
dropbear_assert((unsigned int)written < size);
total += written;
}
-
+
+ /* if args where passed, total will be not zero, and it will
have a space at the end, so remove that */
+ if (total) total--;
+
+ /* make sure arg string is ended, especially if no args were passed. */
+ ret[total]='\0';
+
return
Re: Patch for stricthostkey and a multihop fix
Hi Matt,
No problem, that solution is even better
I was also thinking about another option for hostkey checking
One of the problems I have with logical hostnames, is that you get a
selected number of different hostkeys back.
On a 2 node cluster I can get 2 different hostkeys for the same
logical hostname.
So it would be nice to have a way that I can say that it should not
abort on the 1st hostname match if the key does not match, but
continue to look for a matching hostname AND hostkey.
Any ideas on how we could still use a hostkey check with that, instead
of being forced to ignore them ?
I was thinking about parsing the known_hosts until a match was done
with the hostname AND the hostkey
So not aborting if the first hostkey of a hostname did not match.
Should not be to difficult in making a patch for that...
Its more difficult to think of a way of how a user would provide that
on the cmdline...
Something elsethe TODO file is not up to date...
I took a look to see if I could help out with something, and I saw the
authorized_keys restrictions
But you already done that :)
Cheers,
Hans
On Thu, Apr 11, 2013 at 2:16 AM, Matt Johnston wrote:
> Hi,
>
> Thanks for the patch. I think I'll change it slightly to use
> "-y -y" rather than "-Y" - saves using another letter.
>
> Cheers,
> Matt
>
> On Sun, Apr 07, 2013 at 04:03:37PM +0200, Hans Harder wrote:
>> Underneath some modifications against a stock 2013.56 version
>>
>> - Added -Y option to completely ignore check for hostkeys
>> Needed this for connections to logical hosts, same as openssh -o
>> StrictHostKeychecking=no
>>
>> - Added -y and -Y in function multihop_passthrough_args
>>
>> - fix: in function multihop_passthrough_args there was no space kept
>> between the -W and -i args
>> so added always a space after each added arg
>> after last addition the last space is removed.
>>
>> I am new to the dropbear sources, so perhaps I didn't see it
>> correctlyif so please correct me...
>> Overall nice sourcecode, very clean.
>>
>> Hans
>> ---
>> Quote: ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
>>
>>
>> diff -ruBpN dropbear-2013.56/cli-kex.c work/cli-kex.c
>> --- dropbear-2013.56/cli-kex.c 2013-03-21 08:29:34.0 -0700
>> +++ work/cli-kex.c 2013-04-07 03:01:31.0 -0600
>> @@ -217,6 +217,11 @@ static void checkhostkey(unsigned char*
>> buffer * line = NULL;
>> int ret;
>>
>> + if (!cli_opts.strict_hostkey) {
>> + TRACE(("strict_hostkey disabled, ignoring hostkey check"));
>> + return;
>> +}
>> +
>> hostsfile = open_known_hosts_file(&readonly);
>> if (!hostsfile) {
>> ask_to_confirm(keyblob, keybloblen);
>> diff -ruBpN dropbear-2013.56/cli-runopts.c work/cli-runopts.c
>> --- dropbear-2013.56/cli-runopts.c 2013-03-21 08:29:34.0 -0700
>> +++ work/cli-runopts.c 2013-04-07 03:08:59.0 -0600
>> @@ -62,6 +62,7 @@ static void printhelp() {
>> "-NDon't run a remote command\n"
>> "-fRun in background after
>> auth\n"
>> "-yAlways accept remote
>> host key if unknown\n"
>> + "-YAlways ignore the
>> remote host key\n"
>> "-sRequest a subsystem
>> (use by external sftp)\n"
>> #ifdef ENABLE_CLI_PUBKEY_AUTH
>> "-i(multiple
>> allowed)\n"
>> @@ -130,6 +131,7 @@ void cli_getopts(int argc, char ** argv)
>> cli_opts.backgrounded = 0;
>> cli_opts.wantpty = 9; /* 9 means "it hasn't been touched",
>> gets set later */
>> cli_opts.always_accept_key = 0;
>> + cli_opts.strict_hostkey = 1;
>> cli_opts.is_subsystem = 0;
>> #ifdef ENABLE_CLI_PUBKEY_AUTH
>> cli_opts.privkeys = list_new();
>> @@ -215,6 +217,9 @@ void cli_getopts(int argc, char ** argv)
>> case 'y': /* always accept the remote
>> hostkey */
>> cli_opts.always_accept_key = 1;
>> break;
>> + case 'Y': /* always ignore the remote
>> hostkey */
>> + cli_o
Compile errors on 2013.57
I get compile errors with the new version, because I compile this in a
uclib environment without zlib.
I use ./configure --disable-zlib
In common-kex.c I run into compile errors.
common-kex.o(.text+0x203): In function `switch_keys':
: undefined reference to `gen_new_zstream_recv'
common-kex.o(.text+0x257): In function `switch_keys':
: undefined reference to `gen_new_zstream_trans'
collect2: ld returned 1 exit status
make: *** [dropbear] Error 1
Probably this will solve it.
--- common-kex.c2013-04-16 14:44:42.0 -0600
+++ common-kex.c2013-04-16 15:08:54.0 -0600
@@ -171,14 +171,18 @@ static void switch_keys() {
}
if (ses.kexstate.recvnewkeys && ses.newkeys->recv.valid) {
TRACE(("switch_keys recv"))
+#ifndef DISABLE_ZLIB
gen_new_zstream_recv();
+#endif
ses.keys->recv = ses.newkeys->recv;
m_burn(&ses.newkeys->recv, sizeof(ses.newkeys->recv));
ses.newkeys->recv.valid = 0;
}
if (ses.kexstate.sentnewkeys && ses.newkeys->trans.valid) {
TRACE(("switch_keys trans"))
+#ifndef DISABLE_ZLIB
gen_new_zstream_trans();
+#endif
ses.keys->trans = ses.newkeys->trans;
m_burn(&ses.newkeys->trans, sizeof(ses.newkeys->trans));
ses.newkeys->trans.valid = 0;
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.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
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;
Problems when connecting to dropbear server running as non-root
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] option for fixed user for all logins and env var which publickey info was used
Hi Matt,
This is a patch for the serverpart of dropbear:
- cmdline option -U forcing all user logins to use 1 fixed user
- If used, the original user will be saved in env var SSH_ORGUSER
- if a public key is used to grant a user access, the info part of the ssh
key will be saved in env.var SSD_PUBKEYINFO
ssh keylayout :
So if you do: dropbear -U osuser
and : ssh root@mysystem , user will login as osuser
and the env var SSH_ORGUSER will be set to "root"
I use this with ssh pubkey authentication only, and the SSH_PUBINFO gives
me information in my .profile which public key (=user) was used.
patchfile is against version 2014.65
Hans
--- a/auth.h2014-08-08 13:40:46.0 +
+++ b/auth.h2014-08-25 13:59:19.389599685 +
@@ -122,6 +122,8 @@ struct AuthState {
#ifdef ENABLE_SVR_PUBKEY_OPTIONS
struct PubKeyOptions* pubkey_options;
#endif
+ char *org_username;
+ char *pubkey_info;
};
#ifdef ENABLE_SVR_PUBKEY_OPTIONS
--- a/runopts.h 2014-08-08 13:40:47.0 +
+++ b/runopts.h 2014-08-25 13:32:18.220491735 +
@@ -86,6 +86,7 @@ typedef struct svr_runopts {
#endif
int norootlogin;
+ char *forceuser;
int noauthpass;
int norootpass;
--- a/svr-auth.c2014-08-08 13:40:47.0 +
+++ b/svr-auth.c2014-08-25 13:58:16.972524805 +
@@ -46,6 +46,8 @@ void svr_authinitialise() {
ses.authstate.pw_dir = NULL;
ses.authstate.pw_shell = NULL;
ses.authstate.pw_passwd = NULL;
+ ses.authstate.org_username = NULL;
+ ses.authstate.pubkey_info = NULL;
authclear();
}
@@ -76,6 +78,12 @@ static void authclear() {
if (ses.authstate.pw_passwd) {
m_free(ses.authstate.pw_passwd);
}
+ if (ses.authstate.org_username) {
+ m_free(ses.authstate.org_username);
+ }
+ if (ses.authstate.pubkey_info) {
+ m_free(ses.authstate.pubkey_info);
+ }
}
@@ -134,6 +142,16 @@ void recv_msg_userauth_request() {
m_free(methodname);
dropbear_exit("unknown service in auth");
}
+
+ /* if we need to force logins to a specific user, this is a good place
to do it. */
+ if (svr_opts.forceuser) {
+ /* first save original user */
+ ses.authstate.org_username = m_strdup(username);
+ /* now point to the user we want to have */
+ m_free(username);
+ username=m_strdup(svr_opts.forceuser);
+ userlen=strlen(username);
+ }
/* check username is good before continuing.
* the 'incrfail' varies depending on the auth method to
@@ -291,6 +309,10 @@ static int checkusername(unsigned char *
* should return some standard shells like "/bin/sh" and "/bin/csh"
(this
* is platform-specific) */
setusershell();
+ /* ignore shell check if user is forced */
+ if (svr_opts.forceuser) {
+ goto goodshell;
+ }
while ((listshell = getusershell()) != NULL) {
TRACE(("test shell is '%s'", listshell))
if (strcmp(listshell, usershell) == 0) {
--- a/svr-authpubkey.c 2014-08-08 13:40:47.0 +
+++ b/svr-authpubkey.c 2014-08-25 14:02:18.220481679 +
@@ -188,7 +188,7 @@ static int checkpubkey(unsigned char* al
char * filename = NULL;
int ret = DROPBEAR_FAILURE;
buffer * line = NULL;
- unsigned int len, pos;
+ unsigned int len, pos, infolen, infopos;
buffer * options_buf = NULL;
int line_num;
@@ -310,11 +310,17 @@ static int checkpubkey(unsigned char* al
continue;
}
- /* truncate the line at the space after the base64 data */
+ /* findout the length of the base64 data */
pos = line->pos;
for (len = 0; line->pos < line->len; len++) {
if (buf_getbyte(line) == ' ') break;
}
+ /* findout the length of the public key info */
+ infopos = line->pos;
+ for (infolen = 0; line->pos < line->len; infolen++) {
+ if (buf_getbyte(line) == ' ') break;
+ }
+ /* truncate the line at the space after the base64 data */
buf_setpos(line, pos);
buf_setlen(line, line->pos + len);
@@ -327,6 +333,12 @@ static int checkpubkey(unsigned char* al
}
if (ret == DROPBEAR_SUCCESS) {
+ /* save the (optional) public key information */
+ if (infolen) {
+ ses.authstate.pubkey_info = m_malloc(infolen +
1);
+ strncpy(ses.authstate.pubkey_info,
&line->data[infopos], infolen);
+
String too long when connecting to SunOS ssh daemon
I am getting a 'String too long' error whenever I try to connect to a SunOS
server with dbclient
In order to find out how much it is to long, I adapted 1 line in buffer.c
Now I get the message:"exited: String too long (2056 > 1400)"
That is a lot larger than 1400...
Any concerns before I increase the MAX_STRING_LEN to 2100 ?
Hans
--- a/buffer.c 2014-08-08 07:40:46.0 -0600
+++ b/buffer.c 2014-09-15 08:02:44.0 -0600
@@ -209,7 +209,7 @@ unsigned char* buf_getstring(buffer* buf
unsigned char* ret;
len = buf_getint(buf);
if (len > MAX_STRING_LEN) {
- dropbear_exit("String too long");
+ dropbear_exit("String too long (%d >
%d)",len,MAX_STRING_LEN);
}
if (retlen != NULL) {
Re: String too long when connecting to SunOS ssh daemon
active,password
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred:
gssapi-with-mic,gssapi,publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-keyex
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: gssapi,publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
Credentials cache file '/tmp/krb5cc_4' not found
debug1: Unspecified GSS failure. Minor code may provide more information
Credentials cache file '/tmp/krb5cc_4' not found
debug1: Unspecified GSS failure. Minor code may provide more information
debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: xx
debug1: read PEM private key done: type RSA
debug3: sign_and_send_pubkey
debug2: we sent a publickey packet, wait for reply
debug3: Wrote 384 bytes for a total of 1513
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug3: Wrote 64 bytes for a total of 1577
debug2: callback start
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug3: Ignored env SHELL
debug3: Ignored env TERM
debug3: Ignored env SSH_CLIENT
debug3: Ignored env SSH_USER
debug3: Ignored env SSH_TTY
debug1: Sending env LC_ALL = C
debug2: channel 0: request env confirm 0
debug3: Ignored env USER
debug3: Ignored env http_proxy
debug3: Ignored env USERSSH
debug3: Ignored env LD_LIBRARY_PATH
debug3: Ignored env LS_COLORS
debug3: Ignored env SUDO_USER
debug3: Ignored env SUDO_UID
debug3: Ignored env USERNAME
debug3: Ignored env PAGER
debug3: Ignored env PATH
debug3: Ignored env MAIL
debug3: Ignored env PWD
debug3: Ignored env EDITOR
debug1: Sending env LANG = en_GB
debug2: channel 0: request env confirm 0
debug3: Ignored env https_proxy
debug3: Ignored env SUDO_COMMAND
debug3: Ignored env HOME
debug3: Ignored env SHLVL
debug3: Ignored env LOGNAME
debug3: Ignored env SSH_CONNECTION
debug3: Ignored env LESSOPEN
debug3: Ignored env SUDO_GID
debug3: Ignored env LESSCLOSE
debug3: Ignored env HISTFILE
debug3: Ignored env _
debug3: Ignored env OLDPWD
debug2: channel 0: request shell confirm 1
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: Wrote 512 bytes for a total of 2089
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug1: Remote: Channel 0 set: LC_ALL=C
debug1: Remote: Channel 0 set: LANG=en_GB
debug2: channel 0: rcvd adjust 198560
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
On Mon, Sep 15, 2014 at 5:10 PM, Matt Johnston wrote:
> Hi Hans,
>
> I think that should be OK to increase, you might need to
> raise MAX_PROPOSED_ALGO too. Which version of SunOS is it,
> can you send me the output of "dbclient -v" or OpenSSH "ssh -vvv"
> to that server? I guess it has lots of kerberos key exchange
> methods or something. It doesn't really make sense to have a
> fixed limit (there's already the packet size limit), I'll
> put that on the todo list for the next release.
>
> Cheers,
> Matt
>
> On Mon, Sep 15, 2014 at 04:21:22PM +0200, Hans Harder wrote:
> > I am getting a 'String too long' error whenever I try to connect to a
> SunOS
> > server with dbclient
> >
> > In order to find out how much it is to long, I adapted 1 line in buffer.c
> > Now I get the message:"exited: String too long (2056 > 1400)"
> >
> > That is a lot larger than 1400...
> > Any concerns before I increase the MAX_STRING_LEN to 2100 ?
> >
> > Hans
> >
> >
> >
> > --- a/buffer.c 2014-08-08 07:40:46.0 -0600
> > +++ b/buffer.c 2014-09-15 08:02:44.0 -0600
> > @@ -209,7 +209,7 @@ unsigned char* buf_getstring(buffer* buf
> > unsigned char* ret;
> > len = buf_getint(buf);
> > if (len > MAX_STRING_LEN) {
> > - dropbear_exit("String too long");
> > + dropbear_exit("String too long (%d >
> > %d)",len,MAX_STRING_LEN);
> > }
> >
> > if (retlen != NULL) {
>
[Patch] Restricting access to certain ip numbers.
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__any.allow exists.
It will also check for /etc/dropbear/ip__.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__.allow or ip_.allow is found
+
Re: dbclient fails to honor -o options
you can use scp with -y -y option.
This is passed to dbclient with the underneath patch for scp
--- a/scp.c 2014-10-08 05:34:21.0 -0600
+++ b/scp.c 2014-10-08 05:35:38.0 -0600
@@ -324,7 +324,7 @@ main(int argc, char **argv)
addargs(&args, "%s", ssh_program);
fflag = tflag = 0;
- while ((ch = getopt(argc, argv, "dfl:prtvBCc:i:P:q1246S:o:F:")) != -1)
+ while ((ch = getopt(argc, argv, "dfl:prtvBCyc:i:P:q1246S:o:F:")) != -1)
switch (ch) {
/* User-visible flags. */
case '1':
@@ -332,6 +332,7 @@ main(int argc, char **argv)
case '4':
case '6':
case 'C':
+ case 'y':
addargs(&args, "-%c", ch);
break;
case 'o':
@@ -1145,7 +1146,7 @@ void
usage(void)
{
(void) fprintf(stderr,
- "usage: scp [-1246BCpqrv] [-c cipher] [-F ssh_config] [-i
identity_file]\n"
+ "usage: scp [-1246BCpqrvy] [-c cipher] [-F ssh_config] [-i
identity_file]\n"
" [-l limit] [-o ssh_option] [-P port] [-S program]\n"
" [[user@]host1:]file1 [...] [[user@]host2:]file2\n");
exit(1);
X11 forwarding in dbclient
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
Re: Dropbear 2016.73
Hi Matt, noticed that in sysoptions.h this is added at line 130 /* These are disabled in Dropbear 2016.73 by default since the spec draft-ietf-curdle-ssh-kex-sha2-02 is under development. */ #define DROPBEAR_DH_GROUP14_256 0 #define DROPBEAR_DH_GROUP16 0 Should that not be in options.h underneath line 174 /* Group14 (2048 bit) is recommended. Group1 is less secure (1024 bit) though is the only option for interoperability with some older SSH programs */ #define DROPBEAR_DH_GROUP1 1 #define DROPBEAR_DH_GROUP14 1 Hans On Fri, Mar 18, 2016 at 4:52 PM, Matt Johnston wrote: > Hi all, > > Dropbear 2016.73 is released. It has a few new features and > other small improvements. > > Download at https://matt.ucc.asn.au/dropbear/dropbear.html > > Cheers, > Matt > > 2016.73 - 18 March 2016 > > - Support syslog in dbclient, option -o usesyslog=yes. Patch from > Konstantin Tokarev > > - Kill a proxycommand when dbclient exits, patch from Konstantin Tokarev > > - Option to exit when a TCP forward fails, patch from Konstantin Tokarev > > - New "-o" option parsing from Konstantin Tokarev. This allows handling > some extra options > in the style of OpenSSH, though implementing all OpenSSH options is not > planned. > > - Fix crash when fallback initshells() is used, reported by Michael Nowak > and Mike Tzou > > - Allow specifying commands eg "dropbearmulti dbclient ..." instead of > symlinks > > - Various cleanups for issues found by a lint tool, patch from Francois > Perrad > > - Fix tab indent consistency, patch from Francois Perrad > > - Fix issues found by cppcheck, reported by Mike Tzou > > - Use system memset_s() or explicit_bzero() if available to clear memory. > Also make > libtomcrypt/libtommath routines use that (or Dropbear's own m_burn()). > > - Prevent scp failing when the local user doesn't exist. Based on patch > from Michael Witten. > > - Improved Travis CI test running, thanks to Mike Tzou > > - Improve some code that was flagged by Coverity and Fortify Static Code > Analyzer >
Re: Running Dropbear Without Root Permissions
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 >
wrong definition in default_options.h
I see that localoptions.h now can be used to enable/disable options which are in default_options.h and sysoptions.h... nice There is a wrong definition in the default_options.h /* Whether to support "-c" and "-m" flags to choose ciphers/MACs at runtime */ #ifndef ENABLE_USER_ALGO_LIST #define ENABLE_USER_ALGO_LIST 1 #endif Should be /* Whether to support "-c" and "-m" flags to choose ciphers/MACs at runtime */ #ifndef DROPBEAR_USER_ALGO_LIST #define DROPBEAR_USER_ALGO_LIST 1 #endif Hans
Re: wrong definition in default_options.h
Currently some settings are checked with #ifdef instead of #if : INETD_MODE and NON_INETD_MODE in svr-main.c DO_MOTD in svr-chansession.c and svr-runopts.c DROPBEAR_RSA and DROPBEAR_DSS in keyimport.c DROPBEAR_CLI_PUBKEY_AUTH in cli-runopts.c Hans On Wed, Aug 3, 2016 at 7:56 PM, Hans Harder wrote: > I see that localoptions.h now can be used to enable/disable options which > are in default_options.h and sysoptions.h... nice > > There is a wrong definition in the default_options.h > /* Whether to support "-c" and "-m" flags to choose ciphers/MACs at > runtime */ > #ifndef ENABLE_USER_ALGO_LIST > #define ENABLE_USER_ALGO_LIST 1 > #endif > > Should be > /* Whether to support "-c" and "-m" flags to choose ciphers/MACs at > runtime */ > #ifndef DROPBEAR_USER_ALGO_LIST > #define DROPBEAR_USER_ALGO_LIST 1 > #endif > > > Hans > > >
PATCH: minimum set of trace messages in dbclient
I changed the DEBUG_TRACE functionality and added a DEBUG_LEVEL setting which allows you to add only a minimum number of messages to dbclient only. By specifying 1 or more -v options you will increase verbosity. 1x -v will show connection, remoteid and auth methods 2x -v will show choosen algos 3x -v will show avalable algos This functionality will increase a static dbclient binary approx with 4kb example: dev32:~/git/dropbear# ./dbclient -v -v 192.168.1.150 TRACE (13755) 0.00: user='root' host='192.168.1.150' port='22' TRACE (13755) 0.000108: enter session_init TRACE (13755) 0.010916: remoteident: SSH-2.0-dropbear_2016.74 TRACE (13755) 0.011120: kex algo curve25519-sha...@libssh.org TRACE (13755) 0.011201: hostkey algo ssh-rsa TRACE (13755) 0.011294: enc c2s is aes128-ctr TRACE (13755) 0.011354: enc s2c is aes128-ctr TRACE (13755) 0.011486: hmac c2s is hmac-sha1 TRACE (13755) 0.011518: hmac s2c is hmac-sha1 TRACE (13755) 0.011561: comp c2s is z...@openssh.com TRACE (13755) 0.011585: comp s2c is z...@openssh.com TRACE (13755) 0.107063: enter cli_auth_getmethods TRACE (13755) 0.107875: Methods (len 18): 'publickey,password' TRACE (13755) 0.107948: auth method 'publickey' valid TRACE (13755) 0.108013: enter cli_auth_try TRACE (13755) 0.108096: try auth method publickey TRACE (13755) 0.108132: skip auth method password (not enabled) TRACE (13755) 0.108150: skip auth method interact (not enabled) TRACE (13755) 0.108199: cli_auth_try lastauthtype 2 TRACE (13755) 0.108248: leave cli_auth_try failure TRACE (13755) 0.108313: enter session_cleanup dbclient: Connection to root@192.168.1.150:22 exited: No auth methods could be used. dev32:~/git/dropbear# patch against latest git version attached.. Hans DEBUGLEVEL.patch Description: Binary data
Bad hostkey signature when compiling without ECDSA
When I compile dbclient without ECDSA support I get underneath error. However same source compiled with ECDSA the same connection works. part of the debug output, added some extra output in kexdh_init and kexdh_reply to see what values where given Seems that something goes wrong in buf_rsa_verify. Compiled with #define DROPBEAR_ECDSA 0 TRACE (32763) 0.008984: send_msg_kexdh_init() init : 0 init = normal_DH TRACE (32763) 0.009065: enter gen_kexdh_vals TRACE (32763) 0.208185: leave cli_sessionloop: done with KEXINIT_RCVD TRACE (32763) 0.208220: enter set_connect_fds TRACE (32763) 0.208305: process_packet: packet type = 31, len 567 TRACE (32763) 0.208368: got expected packet 31 during kexinit TRACE (32763) 0.208421: enter recv_msg_kexdh_reply TRACE (32763) 0.208453: type is 0 TRACE (32763) 0.208776: checkpubkey: base64_decode success TRACE (32763) 0.208847: good matching key TRACE (32763) 0.208886: enter buf_get_rsa_pub_key TRACE (32763) 0.209013: leave buf_get_rsa_pub_key: success reply = NORMAL_DH TRACE (32763) 0.406192: enter buf_put_rsa_pub_key TRACE (32763) 0.406592: leave buf_put_rsa_pub_key TRACE (32763) 0.408458: enter buf_verify TRACE (32763) 0.408546: enter buf_rsa_verify TRACE (32763) 0.409296: leave buf_rsa_verify: ret -1 TRACE (32763) 0.409367: enter session_cleanup TRACE (32763) 0.409392: enter chancleanup TRACE (32763) 0.409426: leave chancleanup TRACE (32763) 0.409477: enter cli_tty_cleanup TRACE (32763) 0.409538: leave cli_tty_cleanup: not in raw mode TRACE (32763) 0.409621: empty queue dequeing TRACE (32763) 0.409822: leave session_cleanup dbclient: Connection to test@192.168.1.51:22 exited: Bad hostkey signature Compiled with #define DROPBEAR_ECDSA 1 TRACE (651) 0.009374: send_msg_kexdh_init() init : 0 init = normal_DH TRACE (651) 0.009419: enter gen_kexdh_vals TRACE (651) 0.204902: leave cli_sessionloop: done with KEXINIT_RCVD TRACE (651) 0.204943: enter set_connect_fds TRACE (651) 0.205012: maybe_empty_reply_queue - no data allowed TRACE (651) 0.205078: enter handle_connect_fds TRACE (651) 0.205103: leave handle_connect_fds - end iter TRACE (651) 0.205274: empty queue dequeing TRACE (651) 0.205309: leave cli_sessionloop: kex_state != KEX_NOTHING TRACE (651) 0.205356: enter set_connect_fds TRACE (651) 0.267174: process_packet: packet type = 31, len 567 TRACE (651) 0.267236: got expected packet 31 during kexinit TRACE (651) 0.267277: enter recv_msg_kexdh_reply TRACE (651) 0.267355: type is 0 TRACE (651) 0.267643: checkpubkey: base64_decode success TRACE (651) 0.267685: good matching key TRACE (651) 0.267722: enter buf_get_rsa_pub_key TRACE (651) 0.267820: leave buf_get_rsa_pub_key: success reply = NORMAL_DH TRACE (651) 0.462904: enter buf_put_rsa_pub_key TRACE (651) 0.463227: leave buf_put_rsa_pub_key TRACE (651) 0.465734: enter buf_verify TRACE (651) 0.465765: enter buf_rsa_verify TRACE (651) 0.466463: success! TRACE (651) 0.466526: leave buf_rsa_verify: ret 0 TRACE (651) 0.466593: enter send_msg_newkeys TRACE (651) 0.466709: enter gen_new_keys TRACE (651) 0.467408: leave gen_new_keys TRACE (651) 0.467438: switch_keys trans TRACE (651) 0.467701: leave send_msg_newkeys .. .. dbclient: Connection to test@192.168.1.51:22 exited: No auth methods could be used. I cannot seem to find a reason for that... anybody ? Hans
Running dropbear as non root daemon
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
dropbear as ssh honeypot
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
combining multihop and -J command for proxy connect
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
Re: combining multihop and -J command for proxy connect
did some testing with a small adaption in cli-runopts.c
Basicly if a proycmd if used and multihop is used, I pass the proxycmd with
-J in each exec
Seems to work :)
underneath the complete function... didn't have time to make a diff to the
original...
Hans
static void parse_multihop_hostname(const char* orighostarg, const char*
argv0) {
char *userhostarg = NULL;
char *hostbuf = NULL;
char *last_hop = NULL;
char *remainder = NULL;
/* both scp and rsync parse a user@host argument
* and turn it into "-l user host". This breaks
* for our multihop syntax, so we suture it back together.
* This will break usernames that have both '@' and ',' in them,
* though that should be fairly uncommon. */
if (cli_opts.username
&& strchr(cli_opts.username, ',')
&& strchr(cli_opts.username, '@')) {
unsigned int len = strlen(orighostarg) + strlen(cli_opts.username) + 2;
hostbuf = m_malloc(len);
snprintf(hostbuf, len, "%s@%s", cli_opts.username, orighostarg);
} else {
hostbuf = m_strdup(orighostarg);
}
userhostarg = hostbuf;
last_hop = strrchr(userhostarg, ',');
if (last_hop) {
if (last_hop == userhostarg) {
dropbear_exit("Bad multi-hop hostnames");
}
*last_hop = '\0';
last_hop++;
remainder = userhostarg;
userhostarg = last_hop;
}
parse_hostname(userhostarg);
if (last_hop) {
/* Set up the proxycmd */
unsigned int cmd_len = 0;
char *passthrough_args = multihop_passthrough_args();
char *pproxycmd = NULL;
if (cli_opts.remoteport == NULL) {
cli_opts.remoteport = "22";
}
cmd_len = strlen(argv0) + strlen(remainder)
+ 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 %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);
}
>
Re: combining multihop and -J command for proxy connect
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);
verbose level of trace information
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: verbose level of trace information
Underneath patch files which adds options to specify how much debug trace info is compiled in and how much output is shown during execution. This will add a small amount to your executable size. For dbclient this will : level 1 = init/exit info + remoteid + auth method information level 2 = choosen kex algos level 3 = available algos level 4 = all others, same as DEBUG_TRACE Patches are done against latest git version Hans common-kex.c.patch Description: Binary data common-algo.c.patch Description: Binary data cli-auth.c.patch Description: Binary data cli-main.c.patch Description: Binary data cli-runopts.c.patch Description: Binary data dbutil.c.patch Description: Binary data dbutil.h.patch Description: Binary data debug.h.patch Description: Binary data default_options.h.patch Description: Binary data common-session.c.patch Description: Binary data dropbearconvert.c.patch Description: Binary data sysoptions.h.patch Description: Binary data svr-runopts.c.patch Description: Binary data
Re: dropbear and new host keys?
> 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 >
Re: Dropbear 2020.79
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 > >
MIN_RSA_KEYLEN compare goes wrong
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: MIN_RSA_KEYLEN compare goes wrong
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
Re: [PATCH] Introduce extra delay before closing unauthenticated sessions
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: multiuser disabled - fail more gracefully
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: restrict access
You can add some small code in svr_main.c for allowing/denying remote
servers based on their ip address
getaddrstring(&remoteaddr, &remote_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: restrict access
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: Only do connection if I already know the destination?
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
< }
