SCP with Dropbear not working #3296
Comments
|
@Gill-Bates
This is a very clear and informational message, isn't it? Why do you want to hide it? Since |
|
@MichaIng Connect & Login works fine even with Dropbear and WinSCP. Try to edit & save a file to get the error message. |
|
@Gill-Bates therefore you would need to switch to OpenSSH if you like to use SCP It should not take more than 2-3 minutes to switch the SSH Server using |
|
@MichaIng No! Its not a blocker to switch. But Dropbear is more lightweight. So I was thinking to modify Dropbear to get it running with WinSCP |
|
I am confused now. SCP for what I found is just a non-interactive SFTP client implementation, so instead of having an interactive SFTP session which allows shell-like file manipulation besides upload of course, SCP does a single upload and exists immediately. But it requires an SFTP server regardless. For SFTP/SCP, the SSH server needs to have the SFTP protocol implemented/invoked, and this should be not the case with Dropbear, I am not totally mistaken. But one can simply install the OpenSSH SFTP server as standalone module: https://packages.debian.org/buster/openssh-sftp-server |
|
@MichaIng @Gill-Bates
afterwards you should be able to use SCP protocol with your WinSCP client |
Yes, but this is the client, not the server, hence it will not allow you to upload something via WinSCP to your DietPi. This is why I tried to clarify with above, as the |
|
@MichaIng |
|
@Joulinar EDIT: Okay verified: SCP works without SFTP server and requires
|
|
Okay, I mark this issue as closed. Basically: And SCP + SFTP via Dropbear works OOTB 👍. |
|
I know it's old issue, but I have simple solution (maybe it will be helpful for someone). This allows us to copy files using scp or pscp right after installation. |
|
And you think this is simpler than installing the OpenSSH client package? 😄 Another note when someone lands here: The above link is only valid on Raspbian Bullseye based images (DietPi ARMv6 RPi image) and it is the currently latest package, but may not be available anymore when a new package was shipped. The newest one can be found here, for Bullseye the second-latest one (the latest one is for Raspbian Bookworm): http://raspbian.raspberrypi.org/raspbian/pool/main/o/openssh/?C=M;O=D |
|
yap going with |
|
Yes, I realize that this solution is not perfect and it is not automatic (occasionally you need to update the download link). But it works for my usage scenario: I need the immediate ability to copy files using spc right after automatic installation before even logging into the server. And those few lines of code get the job done. |
|
You are probably right, and maybe it's better to install the whole openssh-client package (after all, this can also be done via Automation_Custom_Script.sh) |
|
you could automatically install OpenSSH Cient automatically during first inital setup. This is how I do it for all my systems. |
|
A manual install works just the same way on DietPi an non-DietPi systems, btw: #3296 (comment) |
|
Maybe a small and late advice, you can always enable "legacy" mode for ssh client ( |
|
For something sensitive like SSH clients and server's I'd always keep them updated. Stable Debian package upgrades are always either bug fixes or security patches, carefully tested to not cause breaking changes, so for SSH I'd call it irresponsible to knowingly delay the update 😉. Also I'm not sure how package upgrades are related to this topic? |
|
You're right that
So you can expect more people coming here as for me reason for finding your issue was moving from openssh 8.9 to 9. :-) |
|
Ah yes, The issue here however was not a client without SFTP support, but that the Dropbear SSH server does not come with SFTP and SCP support, and hence requires apt install gesftpserver
ln -s /usr/libexec/gesftpserver /usr/lib/sftp-server |
|
how about an option in DietPi-Software, where Green End comes in: None ...? |
|
Makes sense. I use the Dropbear + Green End combination successfully for a while now on a few systems. I mean also the OpenSSH SFTP server works well fine, not sure why one could be preferred over the other 🤔. |
|
I would say smaller footprint: |
|
Wrong comparison 😉: https://packages.debian.org/bullseye/arm64/openssh-sftp-server/filelist Newer SFTP protocol version is an argument, but since OpenSSH uses version 3, I guess most clients do not support newer versions either and most admins don't know about the new syntax, if they use the SFTP console manually anyway. One downside of Green End is that it doesn't install to a default path, so clients do not find it unless you pass |
|
and somehow Green End is much slower for me for large filetransfers: |
|
Did you compare with OpenSSH SSH server + Green End SFTP server, respectively Dropbear + OpenSSH SFTP server? Probably it's Dropbear which slows down transfers, not Green End. AFAIK, the protocol version does not affect speed but only refines/defines SFTP syntax/commands. But I might be wrong. Interesting that SCP is faster. Quite nasty since SCP is deprecated and will probably be removed in the future, in favour of SFTP only. |
|
Speed: https://www.jscape.com/blog/scp-vs-sftp regarding you hint for comparison - good point... |
|
from what I can see so far it seems Dropbear doesn't use AES Acceleration (mkj/dropbear#166) or the OpenSSL implementation is much faster... |
root@Rock5-4GB:~# openssl speed -elapsed aes-128-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128 cbc for 3s on 16 size blocks: 33583349 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 64 size blocks: 9086473 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 256 size blocks: 2298588 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 1024 size blocks: 580377 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 8192 size blocks: 72749 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 16384 size blocks: 36389 aes-128 cbc's in 3.00s
OpenSSL 1.1.1n 15 Mar 2022
built on: Fri Jun 24 20:22:19 2022 UTC
options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr)
compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/openssl-rqLv6p/openssl-1.1.1n=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128 cbc 179111.19k 193844.76k 196146.18k 198102.02k 198653.27k 198732.46k
root@Rock5-4GB:~# openssl speed -elapsed -evp aes-128-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128-cbc for 3s on 16 size blocks: 120753717 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 64 size blocks: 62404556 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 256 size blocks: 19951169 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 5315248 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 8192 size blocks: 680927 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 16384 size blocks: 341512 aes-128-cbc's in 3.00s
OpenSSL 1.1.1n 15 Mar 2022
built on: Fri Jun 24 20:22:19 2022 UTC
options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr)
compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/openssl-rqLv6p/openssl-1.1.1n=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128-cbc 644019.82k 1331297.19k 1702499.75k 1814271.32k 1859384.66k 1865110.87kok, e.g. taking type 16384 is almost 10 times faster accelerated... |
|
Can this be compared since Dropbear uses libtomcrypt? |
|
yes, as libtomcrypt does not (yet) have AES acceleration... |
|
Okay makes sense. What would be still interesting if OpenSSH SFTP server or Green End performs better (or equal) with Dropbear and/or OpenSSH SSH server. I'll find time for testing in a few days when back home from vacation. |
|
I hope I find time before, but the first week is more busy than expected... |
ok, new finding - it gets weird... OpenSSH (with SCP) ~ 850 MBit/s (just to be clear, the 2GB file goes from RAMDisk to RAMDisk...) |
|
Bad test with NanoPi R6S Wi-Fi 5 dongle, other system GiB Ethernet attached, transferring a 1 GiB file to and from RAM disk (ImDisk on Windows): All combinations (Dropbear+OpenSSH SFTP, Dropbear+GeSFTP, OpenSSH+GeSFTP) maxxed at 12.5 MiB/s (=100 MBit/s). Not sure why so slow, as it's 434.0 MBit/s link, however the speed remains quite consistently. Only OpenSSH+OpenSSH SFTP was slightly faster with 12.8 MiB/s max. Interestingly, in my case SCP (with OpenSSH server) was significantly slower at max 8.65 MiB/s. With Dropbear + SCP however it maxxed at 12.8 MiB/s. All results can be replicated consistently, I rotated back and forth quite a few times. I also tried with OpenSSH's "internal-sftp" module, which again maxxes at 12.5 MiB/s, i.e. (repeatedly) a little slower than the dedicated With "Transfer on background by default" indeed all combinations' transfer speeds are higher at up to 13.5 MiB/s, which is very strange. I wonder whether it is a dump visual error, like showing "MB" (powers of 1000) instead of "MiB" (powers of 1024) or such, as to me it doesn't make any sense why there would be a difference, or something is badly programmed 😄. However, when I find time I'll do some cable-connected R6S from/to Odroid N2 tmpfs. Your tests were all done on OpenSSH SSH server, or on Dropbear or mixed? I still do not see whether Green End is slower in your case or Dropbear. We have a theory why Dropbear may be slower, but in your results I do not see which SSH server was used. What I faced with Dropbear is a dropping connection at every ~450 MiB. This happens with both: Green End as well as OpenSSH SFTP server (Dropbear SSH server!), so it is indeed Dropbear responsible for this. Is this what you mean with your dropping connection, indicating that you always combined Dropbear with Green End and OpenSSH only with its own SFTP server? |
|
Hi MichaIng, ok, i did not mention this but very good that you pointed it out: I still think that the missing AES accel is responsible, looking at the CPU load during transfer... |
ADMIN EDIT
Solution
The OpenSSH client package includes the
scpbinary invoked by Dropbear when SCP clients access.The same way, SFTP can be enabled:
This installs the
/usr/lib/sftp-serverinvoked by Dropbear on SFTP client access.Only take care to not install the
openssh-serverpackage, which enables the conflicting OpenSSH server service (sshd), which blocks port 22 by default, used by Dropbear already for initial SSH access.Dropbear is the primary SSH-Server on the Dietpi-Ecosystem. Transferring files with WinSCP failed with following error code:
"Cannot execute SCP to start transfer. Please make sure that SCP is installed on the server and path to it is included in PATH. You may also try SFTP instead of SCP. Command failed with return code 127.".Switching to OpenSSH will solve this issue. But it would be great, when I get rid of this annoying error message with Dropbear.
A short edit of the
default.cfgwill solve this issue:cp /etc/profile /var/tmp echo "export PATH=$PATH:/var/tmp/bin" >> /var/tmp/profile mount -o bind /var/tmp/profile /etc/profile mkdir /var/tmp/bin ln -s /var/tmp/dropbear /var/tmp/bin/scpThe text was updated successfully, but these errors were encountered: