The fact scp "worked" illustrates that such "How to secure your server" guides are... at best... poorly thought out. If "remote file access" is not in fact a "necessary service" then you can't very well allow scp to work, and thus you can't allow basic ssh service.
Actually a more sane setup, which I've used, is only SFTP is enabled, no shells. You can fetch files, you can send files, but you can't... for example... run a race exploitation shell script to seize root permissions.
This also has the advantage that if we can only send and receive files, the "server" we're connecting to needn't really exist, like an HTTP virtual host it's just a bunch of "files" and could actually be backed by a database with some blob tables.
There's a lot of scp usage in a typical corporate environment that should actually be files living in a shared filestore anyway, I've seen way too many files which ought to actually be:
* A wiki entry
* Checked into a git repository
* Shared in some cloud service e.g. OneCloud
... but instead they live on Steve's F:\Documents and if Steve is off sick well, here's the copy I made last week, I hope it isn't missing any important updates and somebody make sure Steve gets this when we change it...
The file living in /usr/project/ on testserver03 instead of F:\Documents on Steve's laptop is not a real improvement.
Actually a more sane setup, which I've used, is only SFTP is enabled, no shells. You can fetch files, you can send files, but you can't... for example... run a race exploitation shell script to seize root permissions.
This also has the advantage that if we can only send and receive files, the "server" we're connecting to needn't really exist, like an HTTP virtual host it's just a bunch of "files" and could actually be backed by a database with some blob tables.
There's a lot of scp usage in a typical corporate environment that should actually be files living in a shared filestore anyway, I've seen way too many files which ought to actually be:
* A wiki entry
* Checked into a git repository
* Shared in some cloud service e.g. OneCloud
... but instead they live on Steve's F:\Documents and if Steve is off sick well, here's the copy I made last week, I hope it isn't missing any important updates and somebody make sure Steve gets this when we change it...
The file living in /usr/project/ on testserver03 instead of F:\Documents on Steve's laptop is not a real improvement.