Dropbear -c options

Installing and Using OpenWrt
1

Hello:

Using rsync over ssh from my box with a GbE port to a WD-MBL is really very expensive, more so in the light of my not needing compression or encryption since everything is done inside my local network with no access from the outside.

Compression can be disabled but not encryption.

By expensive I mean the highest throughput obtained being under 7.50MiB /s with CPU load of ~ 100% (kswap 9% + Dropbear 67% + rsync 22%).

For a GbE to GbE link it is nonsensical.

I was advised that Dropbear does not support -c none but today I came across this:

Dropbear - Features and Changes:
[https://matt.ucc.asn.au/dropbear/CHANGES]

--- snip ---
2013.56 - Thursday 21 March 2013
Allow specifying cipher (-c) and MAC (-m) lists for dbclient
Allow using 'none' cipher or MAC (off by default, use options.h). Encryption
is used during authentication then disabled, similar to OpenSSH HPN mode
--- snip ---

I queried it via command line and got this:

root@OpenWrt:~# ssh -c none
ssh: This Dropbear program does not support 'none' cipher algorithm
ssh: Exited: No valid ciphers specified for '-c'
root@OpenWrt:~#

How can it be enabled?

It would be a great thing to be able to use ssh in situations where you don't need encryption, such as a local network file transfer.

Thanks in advance,

PCL

2

I assume you would have to compile a version with "none" enabled.

Interesting. TBH, you are the first person I've experienced that ever mentioned SSH without encryption...I assume people just use telnet or some other thing.

3

Hello:

I see.
I'm afraid that's way over my head.

Given the load that the use of encryption puts on the WD-MBL hardware (APM82181 800MHz+256MB RAM) and a great many other similar but perfectly suitable candidates for running on OpenWRT, I think it is a valid proposition.

See: Can a pocket router go fast?
[https://www.glidk.com/2021/12/22/benchmarking-crappy-router]

The best alternative I have seems to be using rsync/rsyncd but it is much less convenient and straightforward. ie: a real PITA to configure, still working on it.

To add insult to injury, the MBL seems to have some sort of issue with respect to ethernet throughput (hardware/software/driver, no idea) resulting in a max. of ~20MiB /s - using rsync/rsyncd, less with other options.

I'm not setting any trend here.

See this from 2015: [https://serverfault.com/questions/116875/how-can-i-disable-encryption-on-openssh#comment839117_665383]

I have many pogoplugv4 (800Mhz arm version = slow) and they often peg the cpu with ssh. this is why people seek the none cipher. ssh/sshd cpu usage at 100% means its not a network problem!

The whole thread is about that specific need: ssh without encryption.

The fact is that the none option is available in dropbear (and openssh?) clearly means that someone working on dropbear actually thought about it.

Of course, one could argue that ssh with no encryption defeats the purpose of a secure shell but that argument negates the fact that ssh is more than a secure shell: it is a very efficient and easy to use shell for file transfer which can also be made very secure.

I expect it would not be too much hassle for OpenWRT developers to add this option, so that it is available only via command line to those who need it and avoid having to jump through the rsync/rsyncd hoops.

Thanks a lot for your input.

Best,

PCL

4

Could nc be an alternative, to non-encrypting ssh?

5

Hello:

I don't think so.
I need rsync's most important feature incremental file transfer.

Just enabling dropbear's -c none at compilation time would do the trick.

Thanks for your input.

Best,

PCL

6

Did you try @takimata's suggestion in your other thread?

1 Like
7

Hello:

Yes.
I've been dealing with that for a couple of days now. =^/

There seems to be a permissions problem somewhere.

rsync: [receiver] mkstemp "/.firefox.oldfile.EDjmBD" (in stuff) failed: Permission denied (13)

My user owns everything in /mnt/sda3:

groucho@OpenWrt:~$ ls -l /mnt/sda3
drwxrwxrwx    4 groucho  groucho       4096 Apr 25 19:03 bkups
drwxrwxrwx    2 groucho  groucho       4096 Apr 28 17:53 stuff
drwxrwxrwx    2 groucho  groucho       4096 Apr 28 17:53 testdir
groucho@OpenWrt:~$

My user is member to the right clubs:

groucho@OpenWrt:~$ groups
daemon adm ftp users network ntp groucho
groucho@OpenWrt:~$

No idea what could be wrong.
May have to start another thread for that.

Thank you for your input.

Best,

PCL

8

You might go through these possibilities...

...or consider using restic instead of rsync -

9

Hello:

Yes, I've been to that stackoverflow page.
Still working on it. =^/

With respect to restic: my problem is a low spec board in this MBL NAS thingy plus some yet unclear (to me at least) issues which were not present in the original WD formware resulting in a cap of 20MiB /s on eth0. There's a post about that somewhere here at the forum.

This is a common trait to all these WD appliances and the two or three solutions I have come across (in this or similar NASs) involve rsync without ssh, using rsh or rsyncd.

Anything that uses ssh in low powered NASs will put the CPU at 100% load.

To a user such as me, whose NAS is on a local network with no exposure to the web, ssh does not make any sense.

eg:
rsync - make it fast!
[https://www.hsteffin.de/systems/mbwe/rsync.html]
Can a pocket router go fast?
[https://www.glidk.com/2021/12/22/benchmarking-crappy-router]

From what I have read, I don't think restic will use less CPU than ssh, but even if it did, there's a definite deal breaker in it:

Warning
Remembering your password is important! If you lose it, you won’t be able to access data stored in the repository.

The main object of using this WD thing as a NAS is to back up files I am already backing up in my box, so whatever happens, short of a NAS drive disaster, I want to be able to access the partition with my files and retrieve them without having to remember a password. ie: worst case scenario, take out the NAS drive and hook it up in to a SATA/USB adapter.

I'll attempt to ask OpenWRT to compile dropbear with the -c none option enabled.
Maybe I'll get a yes?
It won't change anything for anyone save those who need the same things I do.

Meanwhile, I'll insist on the rsyncd option.

Thanks for your input.

Best,

PCL

10

Hello:

Done. 8^D
Was able to fix the issues I was having with rsyncd and get ~19MiB/s albeit with a CPU load of ~90%.

I think it is too much load for too little throughput for a GbE link, taking into account that (I have read here somewhere) that the original WD firmware was able to get up to ~40MiB/s.

If you are curious about the details, see this thread at stackexchange:

Permission issue with rsyncd
[https://unix.stackexchange.com/questions/700966/permission-issue-with-rsyncd-between-linux-box-and-nas]

Thanks to all who pitched in.

Best,

PCL

11

It's rsync(d) which has that load? I'm wondering what it is doing then. Could it be that compression is an issue? You could put a

dont compress = *

in your rsync.conf, but of course you should be careful with that. If the box can do 40MiB/sec uncompressed vs 19MiB compressed, it is possible that the actual gain is zero. On the other hand, most files are already compressed these days (media files, office docs), so trying to compress it only eats CPU without adding anything.

12

Hello:

Yes. 8^/

The WD-MBL's specs are no big deal:

CPU Applied Micro APM82181 @ 800 MHz
RAM 256 MB
HDD: WDC WD10EURX -  64MB - SATA 6.0Gb/s - 7,200 rpm

No idea.

I already have dont compress = *.gz *.tgz *.zip *.z *.rpm *.deb *.iso ... etc. as a global option. ie: the usual referenced in the rsyncd man pages.

I'll try now with dont compress = *.
---> Hold on ...
No, no change.
The total time is the same and the load goes from 83% to 100% like before.

Maybe I should tailor the dont compress = list a bit.
eg: include *.jpg / *.jpeg for one.
---> Hold on ...
No, the above addition did not change anything.

The WD-MBL's original firmware relied on a 64 kB block size for a better r/w speed, but this meant that the data was inaccessible to OpenWrt and other systems.
ie: a real PITA if/when things went south.

I don't know how much difference the 64 kB block size made.

Maybe it is the ethenet driver used by OpenWRT:

root@OpenWrt:~# ethtool -i eth0
driver: ibm_emac        # <--
version: 3.54               # <--
firmware-version: 
expansion-rom-version: 
bus-info: PPC 4xx EMAC-0 /plb/opb/etherne
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no
root@OpenWrt:~#

ie: maybe some optimisation required?

Any other idea will be appreciated.

Thanks for your input.

Best,

PCL

13

Pretty much none at all. For the longest time there was the assumption that the linux-default 16 kB block size was performing worse than the 64 kB block size of WD's custom firmware. Which turned out to be wrong, it was the unoptimized SATA driver all along.

Apparantly there's some optimization potential in rsync, though. I get significantly better speeds via SMB (I think I remember something like 30 to 35 MB/s, but don't quote me on that, it's been a while).

That being said, rsync at roughly 20 MB/s is doing its job perfectly fine in a day-to-day scenario as long as you don't sync huge amounts of data (or whole disks). Personally, for a few hundred MB per daily (automated) sync process I don't really care enough about the speed to invest significant effort into optimization.

14

Hello:

I see ...
I assume that the patch got pulled in.
Yes?

OpenWRT has rsync latest version and so does my Devuan box with a backported kernel.
ie: 3.2.3 protocol version 31

Still can't get past ~18.5 MiB /s at ~83 to 100% CPU load.
Based on no compression/no cipher, I had hopes for figures above ~ 25MiB /s
Nevertheless, a huge improvement over what I had with ssh.

Yes, I get the idea.

But my NAS is not on all day nor are my jobs automated for the time being.
All is manual for now.

It's a pity to get such a low value on a GbE link.

Thank you very much for your input.
Best,

PCL

15

Yes, ages ago, in 2018. What I linked is the actual commit to the tree.

16

Hello:

Ooops.
Sorry, didn't look. 8^/

Thank you very much for your input.
Best

PCL

17

If you need speed without encryption have a look at NFS.

18

Hello:

I'll check on that.
Thanks for your input.

Best,

PCL