U
U
Unicom2016-02-21 21:27:26
SSH
Unicom, 2016-02-21 21:27:26

What are the best practices for setting up SSH for a webserver?

Good day!
I wondered how best to configure SSH access on the server.
I have Debian 8 / EasyEngine (the entire Web stack [nginx, php, mariadb, redis] runs on behalf of the .user www-data) I
have root on the debian server, but I don't want to use it every time for obvious reasons. Public key access is now configured.
The main question is what to do with the www-data user? Since this is a web server, it is clear that sometimes you need to go via SFTP and upload / change data. It is also not convenient to do this from root, because rights are re-set and scripts do not work, pictures are not loaded. Before that, I had a server with a configured chroot (each site had its own user from which it was required to log in - no problems with security and changing file permissions). Now it’s not clear what to do - logging in via SFTP under the www-data user is somehow dumb, especially since he has all authorization turned off by default, I tried it - it didn’t work, you need to change the configs (but if someone prescribed all these prohibitions to the user, probably not just like that?). Permissions for folders on the site are mainly 755, for files 644 and I don’t want to change this. I want it transparently, uploaded it - it works, without twitching the console and correcting the rights every time.
So what to do? Allow access for the user www-data or create another user and somehow give him the same rights as www-data?
What other best practices for configuring SSH/SFTP are better to use in my case?
I'm going to set up a user for sudo / go to sftp / ssh, do only key authorization, move the ssh port, close all ports except 80, ssh, and the port for the EasyEngine utilities (by the way, how best to close the ports, maybe there are features, well, there give nothing back or give something special to break the pattern to bots?). Share the secrets of customization.

Answer the question

In order to leave comments, you need to log in

7 answer(s)
A
Anton B, 2016-02-22
@Unicom

Add a user to the www-data group and configure in ssh for the umask group
vi /etc/ssh/sshd_config // add to the end of the file
Subsystem sftp internal-sftp
Match Group www-data
ChrootDirectory %h
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp -l INFO -f USER -u 002

V
Valentine, 2016-02-21
@vvpoloskin

If you don’t bother too much, then you can upload data from your user, having previously added it to the www-data group, and allow group members to write to the necessary folders.

D
Dimonchik, 2016-02-21
@dimonchik2013

levels:
-1) disabling root,
0) changing the default port to far away (type 33833)
1) key authorization
2) two-factor authentication
3) knock knock closing the port
each includes the previous ones

S
shuraosipov, 2016-02-25
@shuraosipov

For SSH
1. disable ssh login for root
2. change the port on which sshd is running c 22 to any other.
3. explicitly specify in the config file that ssh version 2 will be used.
4. restrict access via SSH only to specific users (the AllowUsers directive).
5. use KeyBased Authentication with a strong key.
6. Allow ssh/sftp access in iptables only from certain ip addresses.
7. Use chroot jails for users who will log in via ssh/sftp.
Regarding permissions and web server:
1. Create an account (sftp_uploader) that will be used to upload and update files on the web server.
2. Create a separate group (site_operations), give the group rights to the folder with pictures /var/www/pictures
3. Add the user site_operations and www-data to the group.
4. Set permissions chmod -R 2770 /var/www/pictures. 2 stands for SGID. All files that will be changed/added to the /var/www/pictures folder will have the site_operations group ID. Since the users www-data and sftp_uploader are in this group, both accounts will have access to the files, and there is no need to reset the access rights.
5. You can use an ACL instead of a group to grant access rights.
6. For www-data user, change default shell to /sbin/nologin
System-wide:
1. Drop ICMP packets (don't respond to ping)
2. Update kernel, yum.
3. Keep as little software as possible on the machine.

K
kompi, 2016-02-21
@kompi

Required permissions - force the group to home www-data and set rw for the group (for new files/folders) via umask or ACL.

R
res2001, 2016-02-22
@res2001

Write an elementary script that would change the rights to files / folders and run after each change.

V
Vlad Zhivotnev, 2016-02-22
@inkvizitor68sl

https://debian.pro/1915
https://debian.pro/2017

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question