5 ms·

SSH is problematic for several use cases. It is easy to future-proof the crypto for anything other than a quantum computer: Ciphers chacha20-poly1305@open

by chasil 5y ago

SSH is problematic for several use cases. It is easy to future-proof the crypto for anything other than a quantum computer: Ciphers chacha20-poly1305@openssh.com KexAlgorithms curve25519-sha256@libssh.org That is also the fastest cipher for any hardware lacking AES acceleration, but clients configured this way will never talk to older servers (or vice versa). File transfer is a real problem for SSH. The scp command is being slowly excised because of its security problems. https://lwn.net/Articles/835962/ https://lwn.net/Articles/835962/ The replacement sftp protocol simply does not perform well, and the performance problems are explicitly not a development priority. https://daniel.haxx.se/blog/2010/12/08/making-sftp-transfers-fast/ https://daniel.haxx.se/blog/2010/12/08/making-sftp-transfers... Redesigns are on the table: https://www.psc.edu/hpn-ssh-home https://www.psc.edu/hpn-ssh-home At this point, if someone baked the chacha20 cipher into vsftpd (replacing TLS), I would take it for internal use. Wireguard is also an option, allowing us to simply use telnet and cleartext ftp (promiscuous mode on localhost would be a potential path to abuse). In any case, people where I work have standardized on scp and sftp for communication between many disparate architectures, and few realized the problems this would bring.

devwastaken 5y ago
Sftp is also not that great. To transfer a folder with children you have to create an empty folder of the same name on the server. Only then you can transfer the client folder, but it doesn't go into the server folder of the same name. Perhaps stack overflow was just entirely incorrect, but that's how I've had to do it with limited systems in the past.
- mzs 5y ago
  $ tar cf - foo bar | ssh user@host tar -C baz -xvf -
  - chasil 5y ago
    That can bite you if the remote tar allows absolute paths.
  - loxias 5y ago
    high five It truly is the best, no? My pipelines look a bit different than yours (they usually have `lzop`/`zstd`, `cd`, and occasionally `pv`), but tar truly is the best file copy utility. I rarely use `cp -a` even when copying locally. `tar` is so much faster.
    - spockz 5y ago
      Then why isn’t cp-a and alias for tar?
      - loxias 5y ago
        Because that's not how you use it. :) But you raise a decent point. I'll write a short script you could alias to cp in most cases, put it somewhere, and edit this comment in a day with a link.
  - technofiend 5y ago
    I use this locally as well, simply because I know and prefer tar's behavior to that of cp. For example tar cf - . | (cd /some/where/else; tar xvf -). It's possible to do this using cpio as well but it always seemed like cpio needed so many more switches to do the same thing.
- xioxox 5y ago
  You can also use lftp to transfer a directory tree using the sftp protocol: $ lftp sftp://hostname lftp ~> cd somedir lftp ~> mirror . lftp ~> quit
adrian_b 5y ago
rsync over ssh works perfectly (i.e. with the rsync option --rsh="ssh"). Not only it works much faster than scp or sftp, but it also does not lose any file metadata. I have not verified if newer ssh versions have corrected this, but a few years ago scp and sftp failed to copy extended attributes and on some file systems they truncated timestamps.
- chasil 5y ago
  I understand and sympathize with rsync advocacy, but there are two major problems here. The first is the license. Because rsync is under the GPL, it will never be bundled in the OpenSSH.com distribution. It is even missing from OpenBSD base (just confirmed, and loaded it with pkg_add - there are two versions, one with iconv). So let's take Microsoft's implementation, which will forever lack rsync (as they haven't touched it in well over a year). The file transfer agent needs to be under the same license.
  - adrian_b 5y ago
    rsync is a different program than ssh, installed as a different package, so it does not matter what license it has. In most cases, ssh will run a bash at the remote end, which also has the GPL license, so it should be obvious that it is irrelevant what license have the programs launched by ssh. When you run rsync over ssh, the local rsync starts the local ssh client, which connects to the ssh server, which runs the remote rsync, while the data is piped through the ssh connection. rsync is available for most operating systems, but it is not usually installed by default. OpenBSD might be the only exception without a rsync package, but it has openrsync. I assume that it uses the same protocol so rsync to/from OpenBSD should work as well as to/from Linux, Windows, MacOS or any *BSD. If you have the right to transfer files to a computer then normally it is very simple to install rsync, only for your own user if do not have admin rights. In most cases, you can initially just copy the rsync executable file to the target computer using scp, and then do any other file transfers with rsync over ssh. After I have abandoned both scp and sftp many years ago, I no longer had any problems with the performance or data integrity of file transfers over ssh.
tialaramex 5y ago
> if someone baked the chacha20 cipher into vsftpd (replacing TLS), I would take it for internal use. Um. TLS can do chacha20 just fine if that's what you want. In particular in TLS 1.3 you can insist on only doing TLS_CHACHA20_POLY1305_SHA256 if for some reason you really don't like AES or maybe block ciphers in general.
- chasil 5y ago
  The overriding goal was simplicity for an embedded solution. Yes, throwing up an stunnel in front of port 23 enables telnet-ssl, but this is a bit heavy for a small machine. I actually have an emulated VAX running VMS 7.3, and the C compiler on this machine does not support 64-bit "long long" so AES-CTR is the best that it can do (and chacha20 won't compile here). In this case, a version of chacha20 for K&R C would be very handy. As you can imagine, sftp for this machine has been a unique challenge.
xorcist 5y ago
rsync has almost the same syntax as scp, and is really what scp should have been. Use it instead.
deleted 5y ago
[deleted]

by chasil 5y ago

devwastaken 5y ago

Sftp is also not that great. To transfer a folder with children you have to create an empty folder of the same name on the server. Only then you can transfer the client folder, but it doesn't go into the server folder of the same name. Perhaps stack overflow was just entirely incorrect, but that's how I've had to do it with limited systems in the past.

mzs 5y ago
$ tar cf - foo bar | ssh user@host tar -C baz -xvf -
- chasil 5y ago
  That can bite you if the remote tar allows absolute paths.
- loxias 5y ago
  high five It truly is the best, no? My pipelines look a bit different than yours (they usually have `lzop`/`zstd`, `cd`, and occasionally `pv`), but tar truly is the best file copy utility. I rarely use `cp -a` even when copying locally. `tar` is so much faster.
  - spockz 5y ago
    Then why isn’t cp-a and alias for tar?
    - loxias 5y ago
      Because that's not how you use it. :) But you raise a decent point. I'll write a short script you could alias to cp in most cases, put it somewhere, and edit this comment in a day with a link.
- technofiend 5y ago
  I use this locally as well, simply because I know and prefer tar's behavior to that of cp. For example tar cf - . | (cd /some/where/else; tar xvf -). It's possible to do this using cpio as well but it always seemed like cpio needed so many more switches to do the same thing.
xioxox 5y ago
You can also use lftp to transfer a directory tree using the sftp protocol: $ lftp sftp://hostname lftp ~> cd somedir lftp ~> mirror . lftp ~> quit

adrian_b 5y ago

rsync over ssh works perfectly (i.e. with the rsync option --rsh="ssh"). Not only it works much faster than scp or sftp, but it also does not lose any file metadata. I have not verified if newer ssh versions have corrected this, but a few years ago scp and sftp failed to copy extended attributes and on some file systems they truncated timestamps.

chasil 5y ago
I understand and sympathize with rsync advocacy, but there are two major problems here. The first is the license. Because rsync is under the GPL, it will never be bundled in the OpenSSH.com distribution. It is even missing from OpenBSD base (just confirmed, and loaded it with pkg_add - there are two versions, one with iconv). So let's take Microsoft's implementation, which will forever lack rsync (as they haven't touched it in well over a year). The file transfer agent needs to be under the same license.
- adrian_b 5y ago
  rsync is a different program than ssh, installed as a different package, so it does not matter what license it has. In most cases, ssh will run a bash at the remote end, which also has the GPL license, so it should be obvious that it is irrelevant what license have the programs launched by ssh. When you run rsync over ssh, the local rsync starts the local ssh client, which connects to the ssh server, which runs the remote rsync, while the data is piped through the ssh connection. rsync is available for most operating systems, but it is not usually installed by default. OpenBSD might be the only exception without a rsync package, but it has openrsync. I assume that it uses the same protocol so rsync to/from OpenBSD should work as well as to/from Linux, Windows, MacOS or any *BSD. If you have the right to transfer files to a computer then normally it is very simple to install rsync, only for your own user if do not have admin rights. In most cases, you can initially just copy the rsync executable file to the target computer using scp, and then do any other file transfers with rsync over ssh. After I have abandoned both scp and sftp many years ago, I no longer had any problems with the performance or data integrity of file transfers over ssh.

tialaramex 5y ago

> if someone baked the chacha20 cipher into vsftpd (replacing TLS), I would take it for internal use. Um. TLS can do chacha20 just fine if that's what you want. In particular in TLS 1.3 you can insist on only doing TLS_CHACHA20_POLY1305_SHA256 if for some reason you really don't like AES or maybe block ciphers in general.

chasil 5y ago
The overriding goal was simplicity for an embedded solution. Yes, throwing up an stunnel in front of port 23 enables telnet-ssl, but this is a bit heavy for a small machine. I actually have an emulated VAX running VMS 7.3, and the C compiler on this machine does not support 64-bit "long long" so AES-CTR is the best that it can do (and chacha20 won't compile here). In this case, a version of chacha20 for K&R C would be very handy. As you can imagine, sftp for this machine has been a unique challenge.

xorcist 5y ago

rsync has almost the same syntax as scp, and is really what scp should have been. Use it instead.

deleted 5y ago

[deleted]