From themiron.ru at gmail.com Sun Apr 26 08:48:34 2020 From: themiron.ru at gmail.com (Vladislav Grishenko) Date: Sun, 26 Apr 2020 05:48:34 +0500 Subject: [PATCH] Add Chacha20-Poly1305 and AES-GCM ciphers Message-ID: <007d01d61b64$6b1f6ef0$415e4cd0$@gmail.com> Hello, Chacha20-Poly1305 an AES-GCM are authenticated encryption ciphers, widely supported by multiple ssh servers and clients. ? Chacha20-Poly1305 is faster than AES256 on CPU w/o dedicated AES instructions, having the same key size. ? AES-GCM is combination of AES CTR mode and GHASH, slower than AES-CTR on CPU w/o dedicated AES/GHASH instructions. Since LibTomCrypt has no AES/GHASH acceleration support (AES-NI/ARM AES/etc), AES-GCM is disabled by default, Chacha20-Poly1305 gets the highest prio. Transferring 256Gb local file with scp on x86_64: 3des-cbc: 16.8MB/s aes128-cbc: 57.1MB/s aes256-cbc: 52.1MB/s aes128-ctr: 56.8MB/s aes256-ctr: 51.7MB/s aes128-gcm at openssh.com: 42.1MB/s aes256-gcm at openssh.com: 39.0MB/s chacha20-poly1305 at openssh.com: 105.2MB/s As seen, Chacha20-Poly1305 is ~two times faster than aes-ctr, aes-gcm highly relies on ghash therefore slower (or maybe LibTomCrypt approach is not really optimal). So far, DROPBEAR_CHACHA20POLY1305 increases dropbear binary by ~5,5Kb on X86-64, DROPBEAR_ENABLE_GCM_MODE ? by ~6kB, using LibTomCrypt routines. Related PR against current sources is here https://github.com/mkj/dropbear/pull/93 Also, current sources does not allow CBC & CTR modes to be fully disabled, resulting in build errors. Independent PR against current sources is here https://github.com/mkj/dropbear/pull/95 If both patches are applied, newly introduced sysoptions.h check needs to be enhanced with DROPBEAR_AEAD_MODE as well, I can?t make PR because it makes no sense unless both things are there. In text form it will be just: -#if !(DROPBEAR_ENABLE_CBC_MODE || DROPBEAR_ENABLE_CTR_MODE) +#if !(DROPBEAR_ENABLE_CBC_MODE || DROPBEAR_ENABLE_CTR_MODE || DROPBEAR_AEAD_MODE) Review and/or any suggestios will be highly appreciated. Thank you and Best Regards, Vladislav Grishenko -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20200426/f481b16d/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-Chacha20-Poly1305-authenticated-encryption.patch Type: application/octet-stream Size: 26463 bytes Desc: not available Url : https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20200426/f481b16d/attachment-0004.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-AES128-GCM-and-AES256-GCM-authenticated-encrypti.patch Type: application/octet-stream Size: 12291 bytes Desc: not available Url : https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20200426/f481b16d/attachment-0005.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Fix-CBC-mode-can-t-be-fully-disabled.patch Type: application/octet-stream Size: 1060 bytes Desc: not available Url : https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20200426/f481b16d/attachment-0006.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Fix-CBC-mode-can-t-be-the-only-mode.patch Type: application/octet-stream Size: 1627 bytes Desc: not available Url : https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20200426/f481b16d/attachment-0007.obj From themiron.ru at gmail.com Sun Apr 26 08:53:40 2020 From: themiron.ru at gmail.com (Vladislav Grishenko) Date: Sun, 26 Apr 2020 05:53:40 +0500 Subject: [PATCH] Add Ed25519 keys support In-Reply-To: References: <005b01d5f3c5$e322e740$a968b5c0$@gmail.com> Message-ID: <008701d61b65$2119e3c0$634dab40$@gmail.com> Hi, Matt Thank you very much for merging. There?s additional minor patch https://github.com/mkj/dropbear/pull/94 that adds Ed25519 mentions in dropbearkey.1 man. Best Regards, Vladislav Grishenko From: Matt Johnston Sent: Wednesday, March 11, 2020 9:16 PM To: Vladislav Grishenko Cc: dropbear at ucc.asn.au Subject: Re: [PATCH] Add Ed25519 keys support Thank you Vladislav, I've merged this now via github, https://secure.ucc.asn.au/hg/dropbear/rev/d32bcb5c557d It's a nice clean and thorough implementation. Cheers, Matt On Fri 6/3/2020, at 10:45 pm, Vladislav Grishenko > wrote: Hello, Initially inspired by P?ter Szab? work from 2017, but made with general approach: * Curve25519/Ed25519 implementation based on TweetNaCl version 20140427, old Google's curve25519_donna dropped as unnecessary, saves a lot of size. * SHA512 reused from LibTomCrypt, no need to keep own copy * Sign/Verify require no additional memory allocation * Dropbear's API made ~similar to LibTomCrypt devel to ease possible switch, if necessary. Anyway, LibTomCrypt is based on TweetNaCl as well. * Default private key path is key/etc/dropbear/dropbear_ed25519_host_key * Implemented general import from / export to OpenSSH private keys, can be reused for other key types on necessary * Implemented *25519 fuzzers, but still need corresponding data from dropbear-fuzzcorpus * Man, license, commens updated to fit Ed25519 So far, DROPBEAR_CURVE25519 increases dropbear binary by ~2,5Kb on X86-64 vs ~8Kb of current curve25519_donna implementation. DROPBEAR_ED25519 adds ~7,5Kb to dropbear and ~1kB to dropbearconvert for OpenSSH import/export. Related PR against current sources is here https://github.com/mkj/dropbear/pull/91, patches are attached. Review and/or any suggestios will be highly appreciated. Thank you and Best Regards, Vladislav Grishenko <0001-Add-support-for-Ed25519-as-a-public-key-type.patch><0002-Add-curve25519-and-ed25519-fuzzers.patch><0003-Add-import-and-export-of-Ed25519-keys.patch> -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20200426/8e8ef8d3/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Mention-Ed25519-in-dropbearkey-man.patch Type: application/octet-stream Size: 861 bytes Desc: not available Url : https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20200426/8e8ef8d3/attachment.obj From nsz at port70.net Fri May 1 02:46:04 2020 From: nsz at port70.net (Szabolcs Nagy) Date: Thu, 30 Apr 2020 20:46:04 +0200 Subject: bug: stdio pipe is root owned so reopening it fails Message-ID: <20200430184604.GI23945@port70.net> hello, when dropbear server runs on host $ echo hi | ssh user at host 'cat' works as expected (so reading stdin works), but $ echo hi | ssh user at host 'cat /proc/self/fd/0' fails with EPERM (the open syscall in cat that is). it seems the /proc file is user owned but it's a magic symlink to a pipe that is owned by root so reopening it fails: $ ssh user at host 'stat -L /proc/self/fd/0' File: /proc/self/fd/0 Size: 0 Blocks: 0 IO Block: 4096 fifo Device: bh/11d Inode: 7193 Links: 1 Access: (0600/prw-------) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2020-04-30 18:29:01.000000000 Modify: 2020-04-30 18:29:01.000000000 Change: 2020-04-30 18:29:01.000000000 i haven't seen this behaviour with openssh and affects some scripts that use /dev/stdin, /dev/stdout, /dev/stderr (which just point to /proc/self/fd/{1,2,3}) if there is a simple workaround i'd like to hear about it. thanks From matt at ucc.asn.au Fri May 1 20:43:45 2020 From: matt at ucc.asn.au (Matt Johnston) Date: Fri, 1 May 2020 20:43:45 +0800 Subject: bug: stdio pipe is root owned so reopening it fails In-Reply-To: <20200430184604.GI23945@port70.net> References: <20200430184604.GI23945@port70.net> Message-ID: Hi Szabolcs, Ah, that's a bit nasty. I guess the difference is that OpenSSH runs the daemon as the user, while Dropbear runs as root. The procfs manpage mentions the problem. http://man7.org/linux/man-pages/man5/proc.5.html Note that for file descriptors referring to inodes (pipes and sockets, see above), those inodes still have permission bits and ownership information distinct from those of the /proc/[pid]/fd entry, and that the owner may differ from the user and group IDs of the process. An unprivileged process may lack permissions to open them, as in this example: $ echo test | sudo -u nobody cat test $ echo test | sudo -u nobody cat /proc/self/fd/0 cat: /proc/self/fd/0: Permission denied Not really sure of a good workaround. Cheers, Matt > On Fri 1/5/2020, at 2:46 am, Szabolcs Nagy wrote: > > hello, when dropbear server runs on host > > $ echo hi | ssh user at host 'cat' > > works as expected (so reading stdin works), but > > $ echo hi | ssh user at host 'cat /proc/self/fd/0' > > fails with EPERM (the open syscall in cat that is). > > it seems the /proc file is user owned but it's a magic symlink > to a pipe that is owned by root so reopening it fails: > > $ ssh user at host 'stat -L /proc/self/fd/0' > File: /proc/self/fd/0 > Size: 0 Blocks: 0 IO Block: 4096 fifo > Device: bh/11d Inode: 7193 Links: 1 > Access: (0600/prw-------) Uid: ( 0/ root) Gid: ( 0/ root) > Access: 2020-04-30 18:29:01.000000000 > Modify: 2020-04-30 18:29:01.000000000 > Change: 2020-04-30 18:29:01.000000000 > > i haven't seen this behaviour with openssh and affects some > scripts that use /dev/stdin, /dev/stdout, /dev/stderr > (which just point to /proc/self/fd/{1,2,3}) > > if there is a simple workaround i'd like to hear about it. > thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20200501/7fdb821c/attachment.htm From jamie at shareable.org Sat May 2 00:14:39 2020 From: jamie at shareable.org (Jamie Lokier) Date: Fri, 1 May 2020 17:14:39 +0100 Subject: bug: stdio pipe is root owned so reopening it fails In-Reply-To: References: <20200430184604.GI23945@port70.net> Message-ID: <20200501161439.zpg4xl6qwg7nrcpr@mail5> Hi Matt, Matt Johnston wrote: > Not really sure of a good workaround. You can fchmod() or fchown() the pipe descriptor, with fchown() being more secure. # echo hello | (ls -lL /proc/self/fd/0; sudo -u nobody cat /proc/self/fd/0) prw------- 1 root root 0 May 1 17:06 /proc/self/fd/0 cat: /proc/self/fd/0: Permission denied # echo hello | (chmod a+rw /proc/self/fd/0; ls -lL /proc/self/fd/0; sudo -u nobody cat /proc/self/fd/0) prw-rw-rw- 1 root root 0 May 1 17:05 /proc/self/fd/0 hello # echo hello | (chown nobody: /proc/self/fd/0; ls -lL /proc/self/fd/0; sudo -u nobody cat /proc/self/fd/0) prw------- 1 nobody nogroup 0 May 1 17:06 /proc/self/fd/0 hello Best, - Jamie Matt Johnston wrote: > Hi Szabolcs, > > Ah, that's a bit nasty. I guess the difference is that OpenSSH runs the daemon > as the user, while Dropbear runs as root. > > The procfs manpage mentions the problem. [1]http://man7.org/linux/man-pages/ > man5/proc.5.html > > Note that for file descriptors referring to inodes (pipes and > sockets, see above), those inodes still have permission bits > and ownership information distinct from those of the > /proc/[pid]/fd entry, and that the owner may differ from the > user and group IDs of the process. An unprivileged process > may lack permissions to open them, as in this example: > > $ echo test | sudo -u nobody cat > test > $ echo test | sudo -u nobody cat /proc/self/fd/0 > cat: /proc/self/fd/0: Permission denied > > Not really sure of a good workaround. From nsz at port70.net Sat May 2 02:59:03 2020 From: nsz at port70.net (Szabolcs Nagy) Date: Fri, 1 May 2020 20:59:03 +0200 Subject: bug: stdio pipe is root owned so reopening it fails In-Reply-To: <20200501161024.55fmqp2x6felhxx7@mail5> References: <20200430184604.GI23945@port70.net> <20200501161024.55fmqp2x6felhxx7@mail5> Message-ID: <20200501185903.GA26190@port70.net> * Jamie Lokier [2020-05-01 17:10:24 +0100]: > Hi Matt, > > > Not really sure of a good workaround. > > You can fchmod() or fchown() the pipe descriptor, with fchown() being more secure. > > # echo hello | (ls -lL /proc/self/fd/0; sudo -u nobody cat /proc/self/fd/0) > prw------- 1 root root 0 May 1 17:06 /proc/self/fd/0 > cat: /proc/self/fd/0: Permission denied > > # echo hello | (chmod a+rw /proc/self/fd/0; ls -lL /proc/self/fd/0; sudo -u nobody cat /proc/self/fd/0) > prw-rw-rw- 1 root root 0 May 1 17:05 /proc/self/fd/0 > hello > > # echo hello | (chown nobody: /proc/self/fd/0; ls -lL /proc/self/fd/0; sudo -u nobody cat /proc/self/fd/0) > prw------- 1 nobody nogroup 0 May 1 17:06 /proc/self/fd/0 > hello > > Best wishes, > - Jamie > > Matt Johnston wrote: > > Hi Szabolcs, > > > > Ah, that's a bit nasty. I guess the difference is that OpenSSH runs the daemon > > as the user, while Dropbear runs as root. isn't it better security design to drop privs as soon as possible so everything in the process that's managing a user's session runs as that user and not as root? but i guess that requires more changes than fchown on 0/1/2 fds. i can rebuild dropbear so if the fchwon is a simple patch that works for me. thanks. > > > > The procfs manpage mentions the problem. [1]http://man7.org/linux/man-pages/ > > man5/proc.5.html > > > > Note that for file descriptors referring to inodes (pipes and > > sockets, see above), those inodes still have permission bits > > and ownership information distinct from those of the > > /proc/[pid]/fd entry, and that the owner may differ from the > > user and group IDs of the process. An unprivileged process > > may lack permissions to open them, as in this example: > > > > $ echo test | sudo -u nobody cat > > test > > $ echo test | sudo -u nobody cat /proc/self/fd/0 > > cat: /proc/self/fd/0: Permission denied > > > > Not really sure of a good workaround. From a.fiergolski at gmail.com Sun May 3 23:38:34 2020 From: a.fiergolski at gmail.com (Adrian Fiergolski) Date: Sun, 3 May 2020 17:38:34 +0200 Subject: dbclient v2019.78: proxyJump Message-ID: <1f124bdc-67be-9f79-fc07-27a7449b8036@gmail.com> Hi, I am having troubles connecting to another host though a ssh proxy. The command: ??? $>dbclient -i /my_dir/id_rsa -J "dbclient -i /my_dir/id_rsa username1 at server1" username2 at server2 and ? ??? $>dbclient -i /my_dir/id_rsa -J "dbclient -t -i /my_dir/id_rsa username1 at server1" username2 at server2 return: ??? dbclient: Failed reading termmodes ??? dbclient: Connection to username1 at server1:22 exited: Failed to set raw TTY mode ??? dbclient: Connection to username2 at server2:22 exited: Remote closed the connection I have also tried? ??? $>dbclient -i /my_dir/id_rsa -J "dbclient -T -i /my_dir/id_rsa username1 at server1" username2 at server2 but it doesn't connect to the server2 neither. The connection to the first host ??? dbclient -i /my_dir/id_rsa username1 at server1 works properly. What am I doing wrong? How to connect to the final server through the ssh proxy using dropbear? Regards, Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature Url : https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20200503/8afbbde7/attachment-0001.sig From matt at ucc.asn.au Mon May 4 21:21:27 2020 From: matt at ucc.asn.au (Matt Johnston) Date: Mon, 4 May 2020 21:21:27 +0800 Subject: dbclient v2019.78: proxyJump In-Reply-To: <1f124bdc-67be-9f79-fc07-27a7449b8036@gmail.com> References: <1f124bdc-67be-9f79-fc07-27a7449b8036@gmail.com> Message-ID: <3CF2A8F1-2F3B-48FD-8C63-B2DA3CF1A0B0@ucc.asn.au> Hi Adrian, With dropbear you should be able to list the hosts comma separated dbclient -i /mydir/id_rsa username1 at server1,username2 at server2 Does that work? It should do something equivalent to the first one though, unless I've missed something. Cheers, Matt > On Sun 3/5/2020, at 11:38 pm, Adrian Fiergolski wrote: > > Hi, > > I am having troubles connecting to another host though a ssh proxy. The > command: > > $>dbclient -i /my_dir/id_rsa -J "dbclient -i /my_dir/id_rsa > username1 at server1" username2 at server2 > > and > > $>dbclient -i /my_dir/id_rsa -J "dbclient -t -i /my_dir/id_rsa > username1 at server1" username2 at server2 > > return: > > dbclient: Failed reading termmodes > dbclient: Connection to username1 at server1:22 exited: Failed to set > raw TTY mode > dbclient: Connection to username2 at server2:22 exited: Remote closed > the connection > > I have also tried > > $>dbclient -i /my_dir/id_rsa -J "dbclient -T -i /my_dir/id_rsa > username1 at server1" username2 at server2 > > but it doesn't connect to the server2 neither. > > The connection to the first host > > dbclient -i /my_dir/id_rsa username1 at server1 > > works properly. > > What am I doing wrong? How to connect to the final server through the > ssh proxy using dropbear? > > Regards, > > Adrian > > From a.fiergolski at gmail.com Tue May 5 02:38:51 2020 From: a.fiergolski at gmail.com (Adrian Fiergolski) Date: Mon, 4 May 2020 20:38:51 +0200 Subject: dbclient v2019.78: proxyJump In-Reply-To: <3CF2A8F1-2F3B-48FD-8C63-B2DA3CF1A0B0@ucc.asn.au> References: <1f124bdc-67be-9f79-fc07-27a7449b8036@gmail.com> <3CF2A8F1-2F3B-48FD-8C63-B2DA3CF1A0B0@ucc.asn.au> Message-ID: <54450459-4051-f6bf-3c42-e7c139edfc92@gmail.com> Hi Matt, Thank you for your reply. I have just given it a try and in what you proposed, /'username1 at server1,username2' /becomes a user name and server2 is a hostname. At the end, I solved the issue by switching to openssh-client. Cheers, Adrian ? On 04.05.2020 at 15:21, Matt Johnston wrote: > Hi Adrian, > > With dropbear you should be able to list the hosts comma separated > > dbclient -i /mydir/id_rsa username1 at server1,username2 at server2 > > Does that work? It should do something equivalent to the first one though, unless I've missed something. > > Cheers, > Matt > >> On Sun 3/5/2020, at 11:38 pm, Adrian Fiergolski wrote: >> >> Hi, >> >> I am having troubles connecting to another host though a ssh proxy. The >> command: >> >> $>dbclient -i /my_dir/id_rsa -J "dbclient -i /my_dir/id_rsa >> username1 at server1" username2 at server2 >> >> and >> >> $>dbclient -i /my_dir/id_rsa -J "dbclient -t -i /my_dir/id_rsa >> username1 at server1" username2 at server2 >> >> return: >> >> dbclient: Failed reading termmodes >> dbclient: Connection to username1 at server1:22 exited: Failed to set >> raw TTY mode >> dbclient: Connection to username2 at server2:22 exited: Remote closed >> the connection >> >> I have also tried >> >> $>dbclient -i /my_dir/id_rsa -J "dbclient -T -i /my_dir/id_rsa >> username1 at server1" username2 at server2 >> >> but it doesn't connect to the server2 neither. >> >> The connection to the first host >> >> dbclient -i /my_dir/id_rsa username1 at server1 >> >> works properly. >> >> What am I doing wrong? How to connect to the final server through the >> ssh proxy using dropbear? >> >> Regards, >> >> Adrian >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20200504/c98548ca/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature Url : https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20200504/c98548ca/attachment.sig From themiron.ru at gmail.com Sat May 9 19:38:16 2020 From: themiron.ru at gmail.com (Vladislav Grishenko) Date: Sat, 9 May 2020 16:38:16 +0500 Subject: [PATCH] Add Chacha20-Poly1305 and AES-GCM ciphers In-Reply-To: <007d01d61b64$6b1f6ef0$415e4cd0$@gmail.com> References: <007d01d61b64$6b1f6ef0$415e4cd0$@gmail.com> Message-ID: <00f501d625f6$5567d920$00378b60$@gmail.com> Hello, Previous patch adds regression: dbclient throws error "Sorry, I won't let you use password auth unencrypted." with Chacha20-Poly1305 negotiated despite the fact encryption is here. Please refer fixed version attached, https://github.com/mkj/dropbear/pull/93 is also updated. Best Regards, Vladislav Grishenko From: Vladislav Grishenko Sent: Sunday, April 26, 2020 5:49 AM To: dropbear at ucc.asn.au Cc: 'Matt Johnston' Subject: [PATCH] Add Chacha20-Poly1305 and AES-GCM ciphers Hello, Chacha20-Poly1305 an AES-GCM are authenticated encryption ciphers, widely supported by multiple ssh servers and clients. ? Chacha20-Poly1305 is faster than AES256 on CPU w/o dedicated AES instructions, having the same key size. ? AES-GCM is combination of AES CTR mode and GHASH, slower than AES-CTR on CPU w/o dedicated AES/GHASH instructions. Since LibTomCrypt has no AES/GHASH acceleration support (AES-NI/ARM AES/etc), AES-GCM is disabled by default, Chacha20-Poly1305 gets the highest prio. Transferring 256Gb local file with scp on x86_64: 3des-cbc: 16.8MB/s aes128-cbc: 57.1MB/s aes256-cbc: 52.1MB/s aes128-ctr: 56.8MB/s aes256-ctr: 51.7MB/s aes128-gcm at openssh.com : 42.1MB/s aes256-gcm at openssh.com : 39.0MB/s chacha20-poly1305 at openssh.com : 105.2MB/s As seen, Chacha20-Poly1305 is ~two times faster than aes-ctr, aes-gcm highly relies on ghash therefore slower (or maybe LibTomCrypt approach is not really optimal). So far, DROPBEAR_CHACHA20POLY1305 increases dropbear binary by ~5,5Kb on X86-64, DROPBEAR_ENABLE_GCM_MODE ? by ~6kB, using LibTomCrypt routines. Related PR against current sources is here https://github.com/mkj/dropbear/pull/93 Also, current sources does not allow CBC & CTR modes to be fully disabled, resulting in build errors. Independent PR against current sources is here https://github.com/mkj/dropbear/pull/95 If both patches are applied, newly introduced sysoptions.h check needs to be enhanced with DROPBEAR_AEAD_MODE as well, I can?t make PR because it makes no sense unless both things are there. In text form it will be just: -#if !(DROPBEAR_ENABLE_CBC_MODE || DROPBEAR_ENABLE_CTR_MODE) +#if !(DROPBEAR_ENABLE_CBC_MODE || DROPBEAR_ENABLE_CTR_MODE || DROPBEAR_AEAD_MODE) Review and/or any suggestios will be highly appreciated. Thank you and Best Regards, Vladislav Grishenko -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20200509/503bef9d/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-Chacha20-Poly1305-authenticated-encryption.patch Type: application/octet-stream Size: 23776 bytes Desc: not available Url : https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20200509/503bef9d/attachment-0001.obj From shaken at usa.net Tue May 12 18:26:58 2020 From: shaken at usa.net (bruno) Date: Tue, 12 May 2020 12:26:58 +0200 Subject: scp command exemple Message-ID: <670yeLkZ78432Set.1589279218@web13.cms.usa.net> Hello, anyone has an exemple of scp dropbear use ? it seems that : scp my_file root at targetserver:/tmp/ result is scp connection to root at my_file existed connect failed : error resolving "my_file" port "22". name does not resolve Not the same syntax as a standard scp command ? any help ? From matt at ucc.asn.au Tue May 12 20:07:47 2020 From: matt at ucc.asn.au (Matt Johnston) Date: Tue, 12 May 2020 20:07:47 +0800 Subject: scp command exemple In-Reply-To: <670yeLkZ78432Set.1589279218@web13.cms.usa.net> References: <670yeLkZ78432Set.1589279218@web13.cms.usa.net> Message-ID: <798D4D10-9DE5-402C-AA55-157C55C508F6@ucc.asn.au> Hi Bruno, That syntax should work. What platform is it? Have you tried typing it manually in case there were strange unicode characters copy/pasted? Cheers, Matt > On Tue 12/5/2020, at 6:26 pm, bruno wrote: > > Hello, anyone has an exemple of scp dropbear use ? > > it seems that : > > scp my_file root at targetserver:/tmp/ > > result is > > scp connection to root at my_file existed connect failed : error resolving > "my_file" port "22". name does not resolve > > Not the same syntax as a standard scp command ? > > any help ? > From samarth.seksaria at persquarebyte.com Sat Jun 6 02:29:46 2020 From: samarth.seksaria at persquarebyte.com (samarth seksaria) Date: Fri, 5 Jun 2020 23:59:46 +0530 Subject: Dropbear Server started from within app on Android 10 not allowing connection Message-ID: Hello, I am using dropbear on Android phones to connect to each other. I am using a cross-compiled single file binary of dropbear for Android. I am using the "command=? option in authorized_keys and also using the public key for auth. The server when started from within my Android app is not allowing the ssh connection to be successful. However, if I run the server from an adb shell, the connection is successful and my command from authorized_keys is executed like a charm. Dropbear version: Dropbear v2017.75 My phone: Nokia 8.1 (Android 10) Command to start the server: libdropbear.so -vFp 21210 -r .ssh/id_ecdsa Location of authorized_keys: /data/user/0/com.batnpad.appname.debug/.ssh/authorized_keys (Permission is 600) Command used on the client side: ./libdbclient.so -yp 21210 -I 30 -i ../.ssh/id_ecdsa u0_a340 at 192.168.1.142 Output on the client side in case of failure: ./libdbclient.so: Connection to u0_a340 at 192.168.1.142:21210 exited: Remote closed the connection I checked the verbose server logs in both cases. To keep it concise, I will only paste the lines with a difference: Log from server started from within the app: TRACE (10836) 34.244358: enter checkfileperm(/data/user/0/) TRACE (10836) 34.244452: leave checkfileperm: success TRACE (10836) 34.244458: enter checkfileperm(/data/user/0//.ssh) TRACE (10836) 34.244469: leave checkfileperm: success TRACE (10836) 34.244473: enter checkfileperm(/data/user/0//.ssh/authorized_keys) TRACE (10836) 34.244485: leave checkfileperm: success TRACE (10836) 34.244490: leave checkpubkeyperms Log from server started from an adb shell: TRACE (10481) 8.908210: enter checkfileperm(/data/user/0/com.batnpad.appname.debug) TRACE (10481) 8.908333: leave checkfileperm: success TRACE (10481) 8.908346: enter checkfileperm(/data/user/0/com.batnpad.appname.debug/.ssh) TRACE (10481) 8.908359: leave checkfileperm: success TRACE (10481) 8.908381: enter checkfileperm(/data/user/0/com.batnpad.appname.debug/.ssh/authorized_keys) TRACE (10481) 8.908396: leave checkfileperm: success TRACE (10481) 8.908402: leave checkpubkeyperms I have been trying to solve this for days. Any pointers will be of great help. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20200605/4042fc27/attachment.htm From matt at ucc.asn.au Mon Jun 15 23:52:51 2020 From: matt at ucc.asn.au (Matt Johnston) Date: Mon, 15 Jun 2020 23:52:51 +0800 Subject: Dropbear 2020.79 Message-ID: <20200615155251.GA31032@ucc.gu.uwa.edu.au> 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 From guilhem at fripost.org Tue Jun 16 09:58:07 2020 From: guilhem at fripost.org (Guilhem Moulin) Date: Tue, 16 Jun 2020 03:58:07 +0200 Subject: "Bad public key options" (Was: Dropbear 2020.79) In-Reply-To: <20200615155251.GA31032@ucc.gu.uwa.edu.au> References: <20200615155251.GA31032@ucc.gu.uwa.edu.au> Message-ID: <20200616015807.GB3702611@fripost.org> Hi Matt, On Mon, 15 Jun 2020 at 23:52:51 +0800, Matt Johnston wrote: > Dropbear 2020.79 is now released. \o/ congrats! > - [?] x11 forwarding are now disabled by default. I have no opinion about disabling this at compile-time, however the current implementation locks out (?Bad public key options?) users with ?no-X11-forwarding? in their authorized_keys(5) files. Wouldn't it make sense to move the #ifdefs to make the option a no-op instead? (Same thing for ?no-agent-forwarding? actually.) Attached is the patch I applied to ?fix? the regression in the Debian package. Cheers -- Guilhem. -------------- next part -------------- A non-text attachment was scrubbed... Name: authorized_keys-options-parsing.patch Type: text/x-diff Size: 1367 bytes Desc: not available Url : https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20200616/9cf6e39c/attachment.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: not available Url : https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20200616/9cf6e39c/attachment.sig From hans at atbas.org Wed Jun 17 18:38:05 2020 From: hans at atbas.org (Hans Harder) Date: Wed, 17 Jun 2020 12:38:05 +0200 Subject: Dropbear 2020.79 In-Reply-To: <20200615155251.GA31032@ucc.gu.uwa.edu.au> References: <20200615155251.GA31032@ucc.gu.uwa.edu.au> Message-ID: 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20200617/e1d286aa/attachment.htm From matt at ucc.asn.au Wed Jun 17 20:14:21 2020 From: matt at ucc.asn.au (Matt Johnston) Date: Wed, 17 Jun 2020 20:14:21 +0800 Subject: Dropbear 2020.79 In-Reply-To: References: <20200615155251.GA31032@ucc.gu.uwa.edu.au> Message-ID: <3097E63F-7920-4893-B45B-6FFD8353F29C@ucc.asn.au> There are various examples at https://github.com/fabriziobertocci/dropbear-epka Cheers, Matt > On Wed 17/6/2020, at 6:38 pm, Hans Harder wrote: > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20200617/403ace3f/attachment.htm From matt at ucc.asn.au Wed Jun 17 20:18:58 2020 From: matt at ucc.asn.au (Matt Johnston) Date: Wed, 17 Jun 2020 20:18:58 +0800 Subject: "Bad public key options" (Was: Dropbear 2020.79) In-Reply-To: <20200616015807.GB3702611@fripost.org> References: <20200615155251.GA31032@ucc.gu.uwa.edu.au> <20200616015807.GB3702611@fripost.org> Message-ID: > On Tue 16/6/2020, at 9:58 am, Guilhem Moulin wrote: >> - [?] x11 forwarding are now disabled by default. > > I have no opinion about disabling this at compile-time, however the > current implementation locks out (?Bad public key options?) users with > ?no-X11-forwarding? in their authorized_keys(5) files. Thanks, I'll apply that and organise a bug fix release (waiting to see if there are an other immediate regressions). For Debian I think it might be worth keeping x11 forwarding enabled. I disabled x11 forwarding because most embedded platforms (Dropbear's most common usecase (?)) wouldn't have any use for it. On a general distro it can be useful. Cheers, Matt From dropbear at ukku.uk Wed Jun 17 20:19:18 2020 From: dropbear at ukku.uk (Geoff Winkless) Date: Wed, 17 Jun 2020 13:19:18 +0100 Subject: Dropbear 2020.79 In-Reply-To: <20200615155251.GA31032@ucc.gu.uwa.edu.au> References: <20200615155251.GA31032@ucc.gu.uwa.edu.au> Message-ID: On Mon, 15 Jun 2020 at 16:52, Matt Johnston wrote: > 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. > Apologies if I'm being obtuse; with newer version of openssh client the new dropbear won't accept rsa keys: ssh -v root at 172.22.232.152 -p 2222 OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017 [snip] debug1: Next authentication method: publickey debug1: Offering RSA public key: rsa-key-20180607 debug1: *Server accepts key: pkalg rsa-sha2-256 blen 277* Authentication failed. but with older versions it does: ssh -v root at 172.22.232.152 -p 2222 OpenSSH_5.8p2, OpenSSL 0.9.8o 01 Jun 2010 [snip] debug1: Offering RSA public key: rsa-key-20180607 debug1: *Server accepts key: pkalg ssh-rsa blen 277* debug1: Authentication succeeded (publickey). Is there a config option I'm missing? Thanks Geoff -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20200617/ceee07f4/attachment.htm From guilhem at fripost.org Wed Jun 17 22:01:04 2020 From: guilhem at fripost.org (Guilhem Moulin) Date: Wed, 17 Jun 2020 16:01:04 +0200 Subject: "Bad public key options" In-Reply-To: References: <20200615155251.GA31032@ucc.gu.uwa.edu.au> <20200616015807.GB3702611@fripost.org> Message-ID: <20200617140104.GA4078977@fripost.org> On Wed, 17 Jun 2020 at 20:18:58 +0800, Matt Johnston wrote: >> On Tue 16/6/2020, at 9:58 am, Guilhem Moulin wrote: >>> - [?] x11 forwarding are now disabled by default. >> >> I have no opinion about disabling this at compile-time, however the >> current implementation locks out (?Bad public key options?) users with >> ?no-X11-forwarding? in their authorized_keys(5) files. > > Thanks, I'll apply that and organise a bug fix release (waiting to see > if there are an other immediate regressions). Awesome thanks :-) > For Debian I think it might be worth keeping x11 forwarding enabled. > I disabled x11 forwarding because most embedded platforms (Dropbear's > most common usecase (?)) wouldn't have any use for it. On a general > distro it can be useful. I considered that before the upload: my gut feeling based on popcon and bug reports to the Debian BTS is that most users of the Debian package don't have X11 alongside the SSHd. I mentioned the change in the NEWS file; might reconsider if someone complains. Would rather stick to the upstream compiled-in code as the rest is less likely to be battle-tested :-P -- Guilhem. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: not available Url : https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20200617/e7b591b4/attachment.sig From dropbear at ukku.uk Wed Jun 17 22:29:28 2020 From: dropbear at ukku.uk (Geoff Winkless) Date: Wed, 17 Jun 2020 15:29:28 +0100 Subject: Dropbear 2020.79 In-Reply-To: References: <20200615155251.GA31032@ucc.gu.uwa.edu.au> Message-ID: On Wed, 17 Jun 2020 at 13:19, I wrote: > Apologies if I'm being obtuse; with newer version of openssh client the > new dropbear won't accept rsa keys: > Just to update the list in case anyone else hits the same problem I did, the issue was caused by running an out-of-date version of Pageant (the PuTTY authentication agent). As you were. Geoff > -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20200617/ab0aa8f7/attachment-0001.htm From dropbear at niksoggia.it Mon Jun 22 18:35:18 2020 From: dropbear at niksoggia.it (Nik Soggia) Date: Mon, 22 Jun 2020 12:35:18 +0200 Subject: Dropbear Digest, Vol 171, Issue 1 In-Reply-To: References: Message-ID: <80ba51c2-71a3-bee4-b25d-88a3ffa76876@niksoggia.it> Il 16/06/20 06:00, dropbear-request at ucc.asn.au ha scritto: > Dropbear 2020.79 is now released. Hello, I can't compile DB 2020.79 with uClibc-ng (1.0.32, looking at the 1.0.34 sources nothing has changed) unless I add "#define _GNU_SOURCE" on top of "dbrandom.c" (it is required by sys/random.h, line 11 https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/libc/sysdeps/linux/common/sys/random.h). The alternative is to #include manually. Which is best? Cheers diff -Naubr dropbear-2020.79.old/config.h.in dropbear-2020.79.new/config.h.in --- dropbear-2020.79.old/config.h.in 2020-06-15 17:38:40.000000000 +0200 +++ dropbear-2020.79.new/config.h.in 2020-06-22 12:31:03.000000000 +0200 @@ -162,6 +162,9 @@ /* Define to 1 if you have the header file. */ #undef HAVE_LINUX_PKT_SCHED_H +/* Define to 1 if you have the header file. */ +#undef HAVE_LINUX_RANDOM_H + /* Have login() function */ #undef HAVE_LOGIN diff -Naubr dropbear-2020.79.old/configure.ac dropbear-2020.79.new/configure.ac --- dropbear-2020.79.old/configure.ac 2020-06-15 17:38:08.000000000 +0200 +++ dropbear-2020.79.new/configure.ac 2020-06-22 12:31:03.000000000 +0200 @@ -371,7 +371,7 @@ pty.h libutil.h libgen.h inttypes.h stropts.h utmp.h \ utmpx.h lastlog.h paths.h util.h netdb.h security/pam_appl.h \ pam/pam_appl.h netinet/in_systm.h sys/uio.h linux/pkt_sched.h \ - sys/random.h]) + sys/random.h linux/random.h]) # Checks for typedefs, structures, and compiler characteristics. AC_C_CONST diff -Naubr dropbear-2020.79.old/includes.h dropbear-2020.79.new/includes.h --- dropbear-2020.79.old/includes.h 2020-06-15 17:38:08.000000000 +0200 +++ dropbear-2020.79.new/includes.h 2020-06-22 12:31:03.000000000 +0200 @@ -127,6 +127,9 @@ #ifdef HAVE_SYS_RANDOM_H #include #endif +#ifdef HAVE_LINUX_RANDOM_H +#include +#endif #ifdef BUNDLED_LIBTOM #include "libtomcrypt/src/headers/tomcrypt.h" diff -Naubr dropbear-2020.79.old/configure dropbear-2020.79.new/configure --- dropbear-2020.79.old/configure 2020-06-15 17:38:40.000000000 +0200 +++ dropbear-2020.79.new/configure 2020-06-22 12:31:03.000000000 +0200 @@ -5685,7 +5685,7 @@ pty.h libutil.h libgen.h inttypes.h stropts.h utmp.h \ utmpx.h lastlog.h paths.h util.h netdb.h security/pam_appl.h \ pam/pam_appl.h netinet/in_systm.h sys/uio.h linux/pkt_sched.h \ - sys/random.h + sys/random.h linux/random.h do : as_ac_Header=`$as_echo "ac_cv_header_$ac_header" | $as_tr_sh` ac_fn_c_check_header_mongrel "$LINENO" "$ac_header" "$as_ac_Header" "$ac_includes_default" -- /\/ / /-< From ska-dietlibc at skarnet.org Mon Jun 22 20:06:58 2020 From: ska-dietlibc at skarnet.org (Laurent Bercot) Date: Mon, 22 Jun 2020 12:06:58 +0000 Subject: Dropbear Digest, Vol 171, Issue 1 In-Reply-To: <80ba51c2-71a3-bee4-b25d-88a3ffa76876@niksoggia.it> References: <80ba51c2-71a3-bee4-b25d-88a3ffa76876@niksoggia.it> Message-ID: >I can't compile DB 2020.79 with uClibc-ng (1.0.32, looking at the 1.0.34 sources nothing has changed) unless I add "#define _GNU_SOURCE" on top of "dbrandom.c" (it is required by sys/random.h, line 11 https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/libc/sysdeps/linux/common/sys/random.h). > >The alternative is to #include manually. >Which is best? The former is best. Or, you could simply compile dropbear with -D_GNU_SOURCE in your CFLAGS. Never directly include Linux kernel headers in your application code if you can avoid it (because it requires careful namespace manipulation and not all kernel headers are suitable for this, so it can be the beginning of a looong chain of problems). -- Laurent From matt at ucc.asn.au Tue Jun 23 21:40:51 2020 From: matt at ucc.asn.au (Matt Johnston) Date: Tue, 23 Jun 2020 21:40:51 +0800 Subject: Dropbear Digest, Vol 171, Issue 1 In-Reply-To: References: <80ba51c2-71a3-bee4-b25d-88a3ffa76876@niksoggia.it> Message-ID: <5A8FDBC7-8E1F-4C82-91D3-963070C3E500@ucc.asn.au> Thanks, I've added _GNU_SOURCE Cheers, Matt > On Mon 22/6/2020, at 8:06 pm, Laurent Bercot wrote: > >> I can't compile DB 2020.79 with uClibc-ng (1.0.32, looking at the 1.0.34 sources nothing has changed) unless I add "#define _GNU_SOURCE" on top of "dbrandom.c" (it is required by sys/random.h, line 11 https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/libc/sysdeps/linux/common/sys/random.h). >> >> The alternative is to #include manually. >> Which is best? > > The former is best. Or, you could simply compile dropbear with > -D_GNU_SOURCE in your CFLAGS. > > Never directly include Linux kernel headers in your application code > if you can avoid it (because it requires careful namespace manipulation > and not all kernel headers are suitable for this, so it can be the > beginning of a looong chain of problems). > > -- > Laurent > From matt at ucc.asn.au Fri Jun 26 21:59:43 2020 From: matt at ucc.asn.au (Matt Johnston) Date: Fri, 26 Jun 2020 21:59:43 +0800 Subject: Dropbear 2020.80 Message-ID: <20200626135943.GA14533@ucc.gu.uwa.edu.au> Hi all, Dropbear 2020.80 is now available to fix a few small issues. Cheers, Matt 2020.80 - 26 June 2020 - Don't block authorized_keys logins with no-X11-forwarding or no-agent-forwarding restrictions when X11 or agent forwarding are disabled at compile time. This is more of a problem now X11 is disabled by default, reported by Guilhem Moulin - Reduce binary size by 4kB (x64) when using bundled libtommath - Define GNU_SOURCE for getrandom() on uclibc, reported by Laurent Bercot and Fabrice Fontaine - Improve checking libtomcrypt version compatibility - Add some style notes to DEVELOPING.md