Hacker News Reader

Comment by toyg | Hacker News Reader

SFTP has to be set up on the remote server though. Scp does not.

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.

"Almost all cases" is way too strong. Having the sftp subsystem enabled is the default that's quite frequently changed.

I wonder why that's the case. shell access is way more permissive compared to the sftp subsystem.

Why would and admin enable full shell access but not sftp? What does sftp allow that shell access doesn't?

Pure shell access clearly is a superset of all functionality - for example, given shell access, a poor man's scp would be

    ssh user@remote "cat /path/to/target/file" < local file

and if you need to do more files at once, add `tar` to the mix.

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.

sftp-server is linked into sshd since 2008.[1]

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.

[1] https://www.openssh.com/txt/release-4.9

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.

And yet again security people universally makes uninformed decisions that hurt everything. Including security.

Uwot m8?

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.

Which Linux distributions are you referring to with the "legacy" moniker ?

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.

"Subsystem sftp internal-sftp" works since OpenSSH 4.9.

Does it?

I've never done so, and it's worked fine on every server I've ever built. It's at least enabled by default, I guess.

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.

If the scp binary is available on the server side.

The point is moot though because disabling the sftp subsystem yet granting people shell access is backwards.

While I agree, the point isn't really moot since the server admin can come up with a host of rationalizations for it either way :P

Also no, you don't need an scp on the remote side.

I guess the rationalizations will change once scp (the protocol) is well and truly dead won't they?

So tell me, how is the scp protocol implemented?

You do need scp on the remote side. Try it yourself.

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’

    ... tinysshd -x sftp=/usr/libexec/openssh/sftp-server  /etc/tinyssh/sshkeydir

https://tinyssh.org/faq.html

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 is launched both on the client and on the server when you use the "scp" command, so the executable file must exist on both.

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.

I don't recall setting SFTP on my home server when I enabled SSH, but FileZilla and CyberDuck/MountainDuck seems to connect to it via SFTP just fine.

That is because SFTP is enabled by default, but many system administrators, for example myself, disable it.

I don't understand why, do you have a use case?

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.

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.

You can disable the access in sshd_config file but, it's enabled out of the box in everything I've used so far.

Do you have any examples?

Many SSH servers do not run OpenSSH. For example, it may run Dropbear, which does not support SFTP.

Dropbear only supports SFTP if you provide the sftp-server binary, same as how it only supports SCP if you provide the scp binary.

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.

It's also possible that the scp binary won't be available on the server in just the same way.

sftp is normally enabled in the default sshd_config file.

SFTP not FTPS (just in case).

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)

But then how will ACH transfers get processed?!

(Yes, seriously.) A creaky old system if I've ever seen one. Of course, I'd enjoy hearing anyone else who has experience with worse.

While the ach system is a complete piece of shit and it's amazing capitalism even exists. The last time I dealt with it was via aws s3 buckets.

This is my main concern as well.

Reply on news.ycombinator.com