Hacker News Reader

Comment by bipson | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com