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

[Walter Harms]

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.

Add filter to restrict access

[Walter Harms]

lately there was a discussion who to restrict access to a dropbear server. The 
result were some solutions outside dropbear. I have attached a patch to show 
how this could be done. It uses fnmatch() what means the patch is small and the 
pattern is simple. (Try -D 192.168.1.*)

re,
 wh
--- svr-runopts.c~	2020-10-29 14:35:50.0 +0100
+++ svr-runopts.c	2021-05-29 23:01:01.087078502 +0200
@@ -102,6 +102,7 @@
 	"-W  (default %d, larger may be faster, max 1MB)\n"
 	"-K   (0 is never, default %d, in seconds)\n"
 	"-I   (0 is never, default %d, in seconds)\n"
+	"-D   (Host deny pattern e.g. 192.168.1.*)\n"
 #if DROPBEAR_PLUGIN
 "-A [,]\n"
 "   Enable external public key auth through \n"
@@ -163,6 +164,7 @@
 	svr_opts.hostkey = NULL;
 	svr_opts.delay_hostkey = 0;
 	svr_opts.pidfile = DROPBEAR_PIDFILE;
+	svr_opts.deny = NULL;
 #if DROPBEAR_SVR_LOCALTCPFWD
 	svr_opts.nolocaltcp = 0;
 #endif
@@ -247,6 +249,9 @@
 case 'P':
 	next = _opts.pidfile;
 	break;
+case 'D':
+	next = _opts.deny;
+	break;
 #if DO_MOTD
 /* motd is displayed by default, -m turns it off */
 case 'm':
--- svr-main.c~	2020-10-29 14:35:50.0 +0100
+++ svr-main.c	2021-05-29 23:32:29.106964013 +0200
@@ -23,6 +23,7 @@
  * SOFTWARE. */
 
 #include "includes.h"
+#include 
 #include "dbutil.h"
 #include "session.h"
 #include "buffer.h"
@@ -249,6 +250,15 @@
 			/* Limit the number of unauthenticated connections per IP */
 			getaddrstring(, _host, NULL, 0);
 
+			if (debug_trace)
+			  printf("%s:%s %s\n",__func__,remote_host,svr_opts.deny);
+		  /* ignore  certain IPs*/
+			if  (svr_opts.deny)
+			{
+			  if (fnmatch(svr_opts.deny,remote_host,FNM_PATHNAME) == 0)
+			goto out;
+			}
+			
 			num_unauthed_for_addr = 0;
 			num_unauthed_total = 0;
 			for (j = 0; j < MAX_UNAUTH_CLIENTS; j++) {
--- runopts.h~	2021-06-06 14:57:29.591763229 +0200
+++ runopts.h	2021-05-29 22:48:27.789528236 +0200
@@ -124,6 +124,7 @@
 	char * pidfile;
 
 	char * forced_command;
+	char *deny;
 
 #if DROPBEAR_PLUGIN 
 char *pubkey_plugin;

AW: restrict access

[Walter Harms]

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)

AW: restrict access

[Walter Harms]

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 complicated 
situations. The limits of this approach needs to be evaluated. 


Von: Dropbear  im Auftrag von Sebastian Gottschall 

Gesendet: Sonntag, 23. Mai 2021 02:34
An: Hans Harder
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.


i know .but consider that this was not my request. i was just answering
a question and giving a suggestion.
so i have no intentions to implement this on my side

Am 21.05.2021 um 16:56 schrieb 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
>>>

AW: restrict access

[Walter Harms]

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 ?

re,
 wh

Von: Dropbear  im Auftrag von Sebastian Gottschall 

Gesendet: Donnerstag, 20. Mai 2021 15:53
An: dropbear@ucc.asn.au
Betreff: Re: restrict access



isnt that a job for netfilter?

Am 20.05.2021 um 15:23 schrieb Walter Harms:
> Hello List,
> actually i expected this would be a FAQ but i can not find an answer:
> How can i restrict the  hosts that are allowed to access the
> dropbear server ?
>
> re,
>   wh

restrict access

[Walter Harms]

Hello List,
actually i expected this would be a FAQ but i can not find an answer:
How can i restrict the  hosts that are allowed to access the
dropbear server ?

re,
 wh

AW: OpenWRT Dropbear v2020.80: Exit before auth: No matching algo kex

[Walter Harms]

This is caused by changes in ssh_config. You can try:
  ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 USER@TARGET 

or persistent in ssh_config 
KexAlgorithms=+diffie-hellman-group1-sha1 

your mileage may vary etc.

re,
 wh

Von: Dropbear [dropbear-boun...@ucc.asn.au] im Auftrag von Piotr Jurkiewicz 
[piotr.jerzy.jurkiew...@gmail.com]
Gesendet: Donnerstag, 22. Oktober 2020 20:33
An: dropbear@ucc.asn.au
Betreff: OpenWRT Dropbear v2020.80: Exit before auth: No matching algo kex

Hi,

when trying to connect to OpenWRT router (mipsel_24kc architecture) with
PyCharm (uses sshj v0.29.0 client library) I started to get the
following error:

 Exit before auth from : No matching algo kex

I remember that couple of month ago it worked fine. I have downgraded
Dropbear package on the router to version from the previous OpenWRT
release (v2020.78) and indeed I am able to connect to it.

I have tried removing the ed25519 hostkey in v2020.80, but it does not help.

Below I am pasting hex dumps of negotiation on both versions:

Dropbear v2020.80 (No matching algo kex):

  53 53 48 2d 32 2e 30 2d  53 53 48 4a 5f 30 2e 32 SSH-2.0- SSHJ_0.2
0010  39 2e 30 0d 0a   9.0..
   53 53 48 2d 32 2e 30 2d  64 72 6f 70 62 65 61 72 SSH-2.0-
dropbear
 0010  0d 0a 00 00 01 84 07 14  be 21 14 d9 76 eb d7 98 
.!..v...
 0020  a7 14 cd b1 ee ce 91 14  00 00 00 82 63 75 72 76 
curv
 0030  65 32 35 35 31 39 2d 73  68 61 32 35 36 2c 63 75 e25519-s
ha256,cu
 0040  72 76 65 32 35 35 31 39  2d 73 68 61 32 35 36 40 rve25519
-sha256@
 0050  6c 69 62 73 73 68 2e 6f  72 67 2c 64 69 66 66 69 libssh.o
rg,diffi
 0060  65 2d 68 65 6c 6c 6d 61  6e 2d 67 72 6f 75 70 31 e-hellma
n-group1
 0070  34 2d 73 68 61 32 35 36  2c 64 69 66 66 69 65 2d 4-sha256
,diffie-
 0080  68 65 6c 6c 6d 61 6e 2d  67 72 6f 75 70 31 34 2d hellman-
group14-
 0090  73 68 61 31 2c 6b 65 78  67 75 65 73 73 32 40 6d sha1,kex
guess2@m
 00A0  61 74 74 2e 75 63 63 2e  61 73 6e 2e 61 75 00 00 att.ucc.
asn.au..
 00B0  00 20 73 73 68 2d 65 64  32 35 35 31 39 2c 72 73 . ssh-ed
25519,rs
 00C0  61 2d 73 68 61 32 2d 32  35 36 2c 73 73 68 2d 72 a-sha2-2
56,ssh-r
 00D0  73 61 00 00 00 33 63 68  61 63 68 61 32 30 2d 70 sa...3ch
acha20-p
 00E0  6f 6c 79 31 33 30 35 40  6f 70 65 6e 73 73 68 2e oly1305@
openssh.
 00F0  63 6f 6d 2c 61 65 73 31  32 38 2d 63 74 72 2c 61 com,aes1
28-ctr,a
 0100  65 73 32 35 36 2d 63 74  72 00 00 00 33 63 68 61 es256-ct
r...3cha
 0110  63 68 61 32 30 2d 70 6f  6c 79 31 33 30 35 40 6f cha20-po
ly1305@o
 0120  70 65 6e 73 73 68 2e 63  6f 6d 2c 61 65 73 31 32 penssh.c
om,aes12
 0130  38 2d 63 74 72 2c 61 65  73 32 35 36 2d 63 74 72 8-ctr,ae
s256-ctr
 0140  00 00 00 17 68 6d 61 63  2d 73 68 61 31 2c 68 6d hmac
-sha1,hm
 0150  61 63 2d 73 68 61 32 2d  32 35 36 00 00 00 17 68 ac-sha2-
256h
 0160  6d 61 63 2d 73 68 61 31  2c 68 6d 61 63 2d 73 68 mac-sha1
,hmac-sh
 0170  61 32 2d 32 35 36 00 00  00 04 6e 6f 6e 65 00 00 a2-256..
..none..
 0180  00 04 6e 6f 6e 65 00 00  00 00 00 00 00 00 00 00 ..none..

 0190  00 00 00 fd 9d 4e 7a a7  2d 49   .Nz. -I
0015  00 00 08 d4 07 14 71 12  38 a7 62 81 7d 79 63 ca ..q. 8.b.}yc.
0025  3c fb a3 f1 1e 8c 00 00  02 9c 63 75 72 76 65 32 <... ..curve2
0035  35 35 31 39 2d 73 68 61  32 35 36 2c 63 75 72 76 5519-sha 256,curv
0045  65 32 35 35 31 39 2d 73  68 61 32 35 36 40 6c 69 e25519-s ha256@li
0055  62 73 73 68 2e 6f 72 67  2c 64 69 66 66 69 65 2d bssh.org ,diffie-
0065  68 65 6c 6c 6d 61 6e 2d  67 72 6f 75 70 2d 65 78 hellman- group-ex
0075  63 68 61 6e 67 65 2d 73  68 61 32 35 36 2c 65 63 change-s ha256,ec
0085  64 68 2d 73 68 61 32 2d  6e 69 73 74 70 35 32 31 dh-sha2- nistp521
0095  2c 65 63 64 68 2d 73 68  61 32 2d 6e 69 73 74 70 ,ecdh-sh a2-nistp
00A5  33 38 34 2c 65 63 64 68  2d 73 68 61 32 2d 6e 69 384,ecdh -sha2-ni
00B5  73 74 70 32 35 36 2c 64  69 66 66 69 65 2d 68 65 stp256,d iffie-he
00C5  6c 6c 6d 61 6e 2d 67 72  6f 75 70 2d 65 78 63 68 llman-gr oup-exch
00D5  61 6e 67 65 2d 73 68 61  31 2c 64 69 66 66 69 65 ange-sha 1,diffie
00E5  2d 68 65 6c 6c 6d 61 6e  2d 67 72 6f 75 70 31 2d -hellman -group1-
00F5  73 68 61 31 2c 64 69 66  66 69 65 2d 68 65 6c 6c sha1,dif fie-hell
0105  6d 61 6e 2d 67 72 6f 75  70 31 34 2d 73 68 61 31 man-grou p14-sha1
0115  2c 64 69 66 66 69 65 2d  68 65 6c 6c 6d 61 6e 2d ,diffie- hellman-
0125  67 72 6f 75 70 31 34 2d  73 68 61 32 35 36 2c 64 group14- sha256,d
0135  69 66 66 69 65 2d 68 65  6c 6c 6d 61 6e 2d 67 72 iffie-he llman-gr
0145  6f 75 70 31 35 2d 73 68  61 35 31 32 2c 64 69 66 oup15-sh a512,dif
0155  66 69 65 2d 68 65 6c 6c  6d 61 6e 2d 67 72 6f 75 fie-hell 

Re: dropbear and new host keys?

[walter harms]

Am 12.12.2019 13:01, schrieb Joakim Tjernlund:
> On Wed, 2019-12-11 at 18:00 +0100, Joakim Tjernlund wrote:
>> On Wed, 2019-12-11 at 23:53 +0800, Matt Johnston wrote:
>>> Hi Joakim,
>>>
>>> The server needs to be stopped and restarted. If this is for new keys at
>>> first-boot you could look at the -R option.
>>
>> It's not first boot :(
>> This is when a user wants to replace the current keys for some reason. 
>> Ideally the
>> next new session should read the new keys automatically.
>>
>> 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 ?
>>
> 
> W.r.t -R option, will it dectect a bad key and regenerate a new one ?
> One problem we have with using -R is that we need to convert dropbear keys to 
> openssh
> format as well and I cannot see a way to automatically trigger 
> dropbearconvert etc.
> if we do use -R, is there a way?
> 
>  Jocke

Can you use brute force ?
Kill the sshd that should cause a restart
of the daemon no matter what (killall -9 sshd)

re,
 wh

Re: MAX_USERNAME_LEN set too low

[Walter Harms]

> Matt Johnston  hat am 1. März 2019 um 15:24 geschrieben:
> 
> 
> Hi Mike,
> 
> The limit's arbitrary so 32 would be fine. Maybe even something like 100.
> I'll increase it for the next release.
> 
> Cheers,
> Matt
> 
> > On Fri 1/3/2019, at 8:28 am, W. Michael Petullo  wrote:
> > 
> > Dropbear's auth.h defines MAX_USERNAME_LEN as 25 and provides the
> > commentary "arbitrary for the moment."
> > 
> > The useradd utility from shadow-utils on Linux supports usernames with
> > up to 32 characters.
> > 
> > This means that some valid users cannot make use of SSH, namely users
> > for which len(username) is larger than 25 but less than 32.
> > 
> > 32 seems pretty common. Can we modify Dropbear to use 32 instead of 25?
> > 
> > -- 
> > Mike
> > 
> > :wq
> 

just my 2 cents:
 there is an UT_NAMESIZE

may be that can be used.

re,
 wh

Re: combining multihop and -J command for proxy connect

[Walter Harms]

> Hans Harder  hat am 4. August 2018 um 12:58 geschrieben:
> 
> 
> 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;
> +   }

same  notes;

if you use "" for pproxycmd you may have it more easy with sprintf() below
instead of malloc/snprintf would it be possible to use asprintf() ?



> 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);

the "-B" looks very close to the %s

just my 2 cents
re,
 wh


>  #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: ssh login stuck at "expecting SSH2_MSG_KEX_ECDH_REPLY"

[walter harms]

Hello Hari,
nothing special just a hint
when sending logs just replace real IPs with something like 192.168.1.*
otherwise you may reveal information you do not want to reveal.
Just remember that searchengines will find you post now and in 10 years.

re,
 wh


Am 23.10.2017 13:12, schrieb Hariharasubramanian Ramasubramanian:
> 
> ssh login gets stuck at "expecting SSH2_MSG_KEX_ECDH_REPLY" at random.
> 
> However forcing ssh to use 3des cipher suite makes the login go through.
> 
> What causes the login to succeed when cipher suite is forced but fail
> otherwise ?
> 
> Here are the debug for 3 different use cases:
> 1) successful login attempt
> 2) failed login attempt
> 3) forced 3des cipher suite
> 
> ==
> 1) Successful login attempt
> ==
> -bash-4.1$ ssh -vvv root@wsbmc011
> OpenSSH_5.8p2, OpenSSL 1.0.0g 18 Jan 2012
> debug1: Reading configuration
> data /gsa/ausgsa/projects/i/indiateam04/hramasub/.ssh/config
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: Applying options for *
> debug2: ssh_connect: needpriv 0
> debug1: Connecting to wsbmc011 [9.3.21.42] port 22.
> debug1: Connection established.
> debug3: Incorrect RSA1 identifier
> debug3: Could not load
> "/gsa/ausgsa/projects/i/indiateam04/hramasub/.ssh/id_rsa" as a RSA1 public
> key
> debug2: key_type_from_name: unknown key type '-BEGIN'
> debug3: key_read: missing keytype
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug3: key_read: missing whitespace
> debug2: key_type_from_name: unknown key type '-END'
> debug3: key_read: missing keytype
> debug1: identity
> file /gsa/ausgsa/projects/i/indiateam04/hramasub/.ssh/id_rsa type 1
> debug1: identity
> file /gsa/ausgsa/projects/i/indiateam04/hramasub/.ssh/id_rsa-cert type -1
> debug1: identity
> file /gsa/ausgsa/projects/i/indiateam04/hramasub/.ssh/id_dsa type -1
> debug1: identity
> file /gsa/ausgsa/projects/i/indiateam04/hramasub/.ssh/id_dsa-cert type -1
> debug1: identity
> file /gsa/ausgsa/projects/i/indiateam04/hramasub/.ssh/id_ecdsa type -1
> debug1: identity
> file /gsa/ausgsa/projects/i/indiateam04/hramasub/.ssh/id_ecdsa-cert type -1
> debug1: Remote protocol version 2.0, remote software version
> dropbear_2016.74
> debug1: no match: dropbear_2016.74
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_5.8
> debug2: fd 3 setting O_NONBLOCK
> debug3: load_hostkeys: loading entries for host "wsbmc011" from file
> "/gsa/ausgsa/projects/i/indiateam04/hramasub/.ssh/known_hosts"
> debug3: load_hostkeys: found key type RSA in
> file /gsa/ausgsa/projects/i/indiateam04/hramasub/.ssh/known_hosts:23
> debug3: load_hostkeys: loaded 1 keys
> debug3: order_hostkeyalgs: prefer hostkeyalgs:
> ssh-rsa-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ssh-rsa
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug2: kex_parse_kexinit:
> 

Re: SV: Restrictions for password logins

[walter harms]

Am 19.05.2017 16:34, schrieb Henrik Uggla:
> Permission to run one command, everything else should be denied.

why not modify .profile (or /bin/sh in /etc/profile) ?
anything else feels complicated.

re,
 wh


> 
> /HU
> 
> Från: Matt Johnston 
> Skickat: den 19 maj 2017 14:46
> Till: Henrik Uggla
> Kopia: dropbear@ucc.asn.au
> Ämne: Re: Restrictions for password logins
> 
> On Fri, May 19, 2017 at 07:42:21AM +, Henrik Uggla wrote:
>> Hi!
>>
>>
>> How can I set restrictions, like those given in authorized_keys, to all 
>> password logins?
> 
> Hi Henrik,
> 
> You can't set all of those restrictions like command= though
> you can disable TCP forwarding at compile time in options.h
> 
> What restrictions were you looking at?
> 
> Cheers,
> Matt

Re: Restrictions for password logins

[walter harms]

Am 19.05.2017 09:42, schrieb Henrik Uggla:
> Hi!
> 
> 
> How can I set restrictions, like those given in authorized_keys, to all 
> password logins?
> 
> 
did you try the generalsetup at /etc/ssh/ssh_config ?

re,
 wh



> regards
> 
> HU
> 

Errorcodes

[walter harms]

Hi List,
i am using dropbear is a script and was testing error codes.
I noticed that DB returns 0 (success) even when authentication does not work.
(OpenSSH returns here 255).

Is there somewhere a list of error codes to find ?

General i noticed that the errorcodes are not divers enough so i had to
rely on message strings.

re,
 wh