Which would not be an issue in almost all cases, since sftp is usually part of the OpenSSH suite, and since you are in most cases using the underlying SSH anyway...
I know that you could have an SSH implementation without sftp - but I'm arguing about the regular case. AFAIK sftp is usually there.
A few weeks ago I was scratching my head why scp was working on an embedded board and sftp- not. Yocto's default build recipes did not include the required plugin/library for sftp functionality.
It's one more protocol and one more executable (sftp-server) where things can go wrong and be exploited. Because it's less popular than the pure shell, it's likely less tested. So the right security posture, if you don't need it, is to disable it.
How do you know it's less popular? It seems like every non embedded distro enables it. OpenSSH linked sftp-server into sshd because SFTP only configurations were popular.
In most cases, it’s not so much a considered security posture and more that Yocto and other embedded builds tend to use dropbear instead of openssh because it’s smaller, and dropbear doesn’t support sftp.
Note that the contents of /etc/ssh/sshd_config are USUALLY compatible across operating systems.
So you can use ansible to install a common and secure and standardized sshd config across, say, legacy linux and new freebsd servers.
With the tiny little problem that filesystem paths will be different for linux and freebsd.
On modern freebsd, from memory, this sshd config line works:
Subsystem sftp /usr/libexec/sftp-server
I forget the path on legacy linux.
Anyway the simplest and most secure way is just to disable sftp across all systems and just use ssh and scp.
The solution to this problem is likely not to be shipping multiple inevitably slightly incompatible sshd configs, but I'll probably end up shipping exactly and precisely one sshd_config with the path on all operating systems being /usr/local/libexec/sftp-server or something like that, and then ansible rules to symlink freebsd and linux to the "standard" path.
Or I'll go all in on freebsd and get rid of the last legacy linux servers.
Or I'll reduce security by using ansible with multiple sshd_config files.
Or recode everything that used scp to use rsync or other alternatives (LOL as if thats happening)
At any rate as usual with unix there's multiple ways to handle things, which is good. Its not like windows or systemd based operating systems.
I think the parent has some sort of axe to grind with Linux in general, and believes any Linux-based OS to be "legacy", with FreeBSD as the "obvious" replacement. Clearly the parent lives in a different reality than the rest of us.
You need the sftp subsystem enabled on the server, which may be disabled on the server side (not that uncommon). The current scp still works fine in that scenario.
This is actually not so. Transfers don't work if the scp program is missing on the remote.
I use tinyssh in a few contexts where I don't want file transfers of any kind.
___
TinySSH doesn’t have SCP?
No, ‘rsync -e ssh’ makes same job. If you really need scp, use scp for example from OpenSSH. TinySSH doesn’t have problem with scp protocol, only doesn’t have scp program.
Can I use sftp using TinySSH?
Yes. TinySSH doesn’t have sftp program, but can run e.g. OpenSSH /usr/libexec/openssh/sftp-server.
Sftp support can be enabled using switch ‘-x’
Can’t test it now but that doesn’t sound right. The doc as written seems to indicate that tinySSH doesn’t ship the scp client but will work fine if you use scp from somewhere else to connect to it. As far as I know, scp is a client only.
scp(1) doesn't really distinguish client and server. There's source and sink, which is determined by the transfer direction. Without scp(1) on the path on the remote end, scp is not going to work. (Some SSH implementations may implement scp internally, though, by parsing the exec requests sent by the connected client).
If you do "scp foo user@host:/bar", then scp ssh's into user@host and executes scp(1) there with a flag that tells it to go into sink mode. When you swap the arguments, it uses a flag that tells it to send the files you want in source mode.
Can I ask why? Opening up command line/ssh access and closing off SFTP seems kind of like having a haystack and saying "hmmm something's wrong" then removing one straw from the pile and saying "ah, perfection"
I disable sftp because I do not use it. I disable all sshd features that I do not use, e.g. various methods of authentication or encryption other than those that I use.
I do not use sftp because it is a bad protocol, which cannot reach high speeds. This has been explained by other poster.
I frequently transfer tens or hundreds of gigabytes of files over ssh and with sftp that would be unacceptably slow. Also, sftp does not handle correctly all file metadata, in certain cases making incomplete file copies, with only partial metadata.
I use rsync over ssh, which does not have any of the problems that plague scp and sftp.
I deactivated sshd multiple times for some clients (needlessly I should add since the VM only network access was through VNC, and sometimes nfs wo) to avoid data leaks. When some data (often code) had to be sent to the VM, I don't see one case when reactivating ssh and not sftp is better than the reverse. Activating sftp only allowed us to keep track of the file put on the server, effectively copying everything passing through the chroot directory.
The OpenSSH sshd executable, in absence of a sshd_config, disables it - and rightly so, because you have to specify a server executable to manage it, which may or may not be available. It just so happens most distributions enable it by default. However, a hardened configuration could legitimately disable, to reduce attack space - it's an extra executable where things can go wrong and be exploited. There is also no requirement for non-OpenSSH implementations to have it.
To be clear, the problem is not that sftp is unlikely to be available, but that it's possible that it will be the case; hence it does not replace scp in that scenario without complete loss of functionality. It is an objectively inferior option.
If there’s anything out there that needs to be deprecated then it’s ftp and especially ftps. Looking at you IBM AS400 (or whatever it is called these days)
