Errorcodes
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
Re: Restrictions for password logins
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 >
Re: SV: Restrictions for password logins
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: ssh login stuck at "expecting SSH2_MSG_KEX_ECDH_REPLY"
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: > ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hell
Re: combining multihop and -J command for proxy connect
> 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: MAX_USERNAME_LEN set too low
> 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: dropbear and new host keys?
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
AW: OpenWRT Dropbear v2020.80: Exit before auth: No matching algo kex
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 man-gr
restrict access
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: restrict access
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
AW: restrict access
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(&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 >>>
AW: restrict access
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)
Add filter to restrict access
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 = &svr_opts.pidfile; break; +case 'D': + next = &svr_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(&remoteaddr, &remote_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: Only do connection if I already know the destination?
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.
libssh + dropbear problem ?
Hello list, We have found a strage issue with dropbear 2022.83 and libssh2 1.11. after the dropbear update we notice that processes got stuck. It turned out that libssh2 got stuck in channel_free(), fun fact the other things seem to work normaly. Did anyone see this before ? WH