However, I expect plenty of people to be in the same case.
A simpler invocation could run it through (unencrypted) inetd/socket activation.
SELINUX really throws fits of hysteria when running this, however.
$ cat sftp-tls.sh
#!/bin/sh
exec nc --ssl server 52345
$ sftp -S ./sftp-tls.sh bogus
Connected to bogus.
sftp> cd /nobody
sftp> get sftp-tls
Fetching /nobody/sftp-tls to sftp-tls
/nobody/sftp-tls 100% 15 8.9KB/s 00:00
sftp> quit
# cat /etc/stunnel/sftp-ssl.conf
#GLOBAL####
;sslVersion = TLSv1.2
TIMEOUTidle = 6000
renegotiation = no
FIPS = no
options = NO_SSLv2
options = NO_SSLv3
options = SINGLE_DH_USE
options = SINGLE_ECDH_USE
options = CIPHER_SERVER_PREFERENCE
syslog = yes
debug = debug
setuid = nobody
setgid = nobody
# chroot = /var/empty/stunnel
libwrap = no
service = sftp-ssl
; cd /var/empty; mkdir -p stunnel/etc; cd stunnel/etc;
; echo 'sftp-ssl: ALL EXCEPT localhost' >> hosts.deny;
; chcon -t stunnel_etc_t hosts.deny
; https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/
ciphers=ECDH+AESGCM:ECDH+CHACHA20:DH+AESGCM:RSA+AESGCM:!aNULL:!MD5:!DSS
curve = secp521r1
#CREDENTIALS####
# verify = 4
cert = /etc/stunnel/sftp-ssl.pem
#ROLE####
exec = /usr/libexec/openssh/sftp-server
# execargs= sftp-server -d /home/nobody
# execargs= sftp-server -l DEBUG3Rsync's ssh support is generally good, so might be about equivalent, but it's not always handy.
1: https://www.cyberciti.biz/faq/howto-use-tar-command-through-...
Also rsync does not exist on windows, for instance git bash has only scp AFAIK.
https://docs.microsoft.com/en-us/previous-versions/windows/d...
scp wins on brevity of commandline syntax
Would be nice to be able to just type sftp user@domain:/file and have it do the right thing.
* scp(1): Relating to the above changes to scp(1); the scp protocol
relies on the remote shell for wildcard expansion, so there is no
infallible way for the client's wildcard matching to perfectly
reflect the server's. If there is a difference between client and
server wildcard expansion, the client may refuse files from the
server. For this reason, we have provided a new "-T" flag to scp
that disables these client-side checks at the risk of
reintroducing the attack described above.
The scp protocol is outdated, inflexible and not readily fixed. We
recommend the use of more modern protocols like sftp and rsync for
file transfer instead.
[1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6111
[2] https://github.com/openssh/openssh-portable/blob/master/scp....
In practice, this means that the OpenSSH implementation is the de facto standard, and that interoperating a non-OpenSSH client with a non-OpenSSH server is a gamble.
It's interesting that they push for sftp. Personally, if scp is vulnerable to certain types of attacks, I'd rather see an entirely new standard and an effort to avoid having it in draft state for decades.
I'm not sure why we need to see an entirely new standard, sftp as implemented by openssh is well conceived, simple, and covers its use case very well.
The key to my point here is "as implemented by openssh".
A relevant anecdote: I had to connect from my program to a third party (version 3) SFTP service, IIRC backed by some Oracle software (but don't quote me on that). I had a version 3 client library. The OpenSSH client worked just fine with the remote, and the client library worked just fine with an OpenSSH server. When connecting to the third party, the client gave up.
After some debugging I learned that the third party server didn't include the language tag in its response statuses (as SFTP version 3 software should). OpenSSH was just fine with this and ignored the problem, and the third party software was probably only ever tested with OpenSSH based clients.
It was definitely a bug in the third party service as far as I was concerned, but I think that this is the natural result of relying on behavior "as implemented by ssh" rather than a stable, well defined (and non-expired) standard.
Yes, we all know about xkcd, no need to link guys.
927 - Standards - https://xkcd.com/927/
1127 - Workflow - https://xkcd.com/1172/
1323 - Protocol - https://xkcd.com/1323/
I have stopped using scp and sftp many years ago. Besides the fact that sftp can be too slow, both scp and sftp fail to make identical copies of the transferred files because sometimes they can lose some metadata, e.g. extended attributes or high resolution time stamps.
alias scp='rsync --archive --xattrs --acls --progress --rsh="ssh"'
ssh remote 'cd /src;tar -cf - .' | (cd /dst;tar -xf -)
eg, instead of one connection (eg rsync), lftp can transfer each file using n parallel streams.
Very useful with large files, when there's some kind of bandwidth limit per TCP connection.
sftp -o IdentityFile=keyfile or scp -i keyfile
https://docs.microsoft.com/en-us/windows-server/administrati...
https://heejune.me/2018/08/02/setup-rsync-server-over-ssh-on...
[ edit ] if that and cygwin are too heavy, you could request the samba team create a posix windows build of rsync. They had one long ago, but stopped supporting it. That would be a single binary. I suspect they will push back.
I found a Github repo with an older (2017) version of cwRsync that may be from before it went behind a paywall @ https://github.com/billyc/cwrsync-installer
You can run a local console and rsync directly from your window drives (/drives)
I've never used sftp before. Does it offer equivalents to:
scp server:'*.pdf' .
scp server:'*(oc[1])' .
scp server:'$(custom_remote_program)' .
EDIT: Reading:
> * scp(1): Relating to the above changes to scp(1); the scp protocol relies on the remote shell for wildcard expansion, so there is no infallible way for the client's wildcard matching to perfectly reflect the server's. If there is a difference between client and server wildcard expansion, the client may refuse files from the server. For this reason, we have provided a new "-T" flag to scp that disables these client-side checks at the risk of reintroducing the attack described above.
I guess, I'll actually want:
alias scp='scp -T'
ssh server 'tar c $(custom_remote_program)' | tar xC destination
May I suggest using rsync instead? The syntax is much closer to scp than sftp is, to the point of being compatible for the most trivial use cases. But rsync is actively developed and has much saner defaults, can continue broken transfers etc.
alias scp="rsync --partial --progress --rsh=ssh"
You should keep in mind that it is rsync in the background, because parameter are different.
> This release contains mitigation for a weakness in the scp(1) tool and protocol (CVE-2019-6111) [...] The scp protocol is outdated, inflexible and not readily fixed. We recommend the use of more modern protocols like sftp and rsync for file transfer instead.
I think it's the time to "alias scp=sftp". If the developers officially believe that scp should be retired, let's do the switch. Both are parts of OpenSSH and the commandline argument is almost identical.
Also, it has
> ssh(1), sshd(8): Add experimental quantum-computing resistant key exchange method, based on a combination of Streamlined NTRU Prime 4591^761 and X25519.
This is big. Together with XMSS signature, it means we already have a complete suite of post-quantum cryptography (experimentally) deployed in OpenSSH! It may be the first mass deployment of post-quantum cryptography in a major protocol.
One month ago, I commented that the introduction of XMSS post-quantum signature as "useless" (https://news.ycombinator.com/item?id=19160739), as the decryption of key exchange is much more vulnerable than spoofing the signature. But now NTRU+X25519 is deployed, great progress here!