EC2 FileZilla login OK but no write or delete access

Question

I am a total Apache noob, and after much hair-pulling and gnashing of teeth finally got SFTP access to new EC2 instance in passive mode. Can login only as "ec2-user", or "root" with no password, but not with myusername and/or password... I've created an .htaccess file in /home/admin, /home/ec2-user, and /home/myusername directories... I've tweaked /etc/httpd/conf/httpd.conf, /etc/vsftpd/vsftpd.conf as well as changed AWS security group settings and ports/protocols in accord with those tweaks, and created .ssh/authorized_keys file for each of the above user directories. I cannot drag/drop from local machine to EC2 instance via FTP client (Filezilla), so apparently, while I can login as ec2-user, I do not have write permissions. Suspect I need to chown...something?

I'm using the vsftpd set-up recommended here

Any ideas on what I need to change in order to 1) login via Filezilla as "myusername" rather than "ec2-user" or "root"?

PS: I've got most of the pertinent AWS command line tools installed and functional...

Solution

You have mentioned (and possibly confused) a few different things - so your objective isn't quite clear, unfortunately.

1. SFTP - there is no such thing as 'passive SFTP' - the SFTP protocol is completely different from FTP and is handled by /usr/libexec/openssh/sftp-server (set in /etc/ssh/sshd_config) not vsFTPd
2. Apache .htaccess files have nothing to do with FTP - they define rules for how your web server will deliver content (i.e. to a visitor of your website).
3. Are you trying to use FTP to SFTP?
4. Are you trying to serve websites from /home/admin, /home/ec2-user, etc? On Amazon's Linux the default web root for Apache is /var/www/html. Typically, you will add your content there, or you have to change the DocumentRoot in httpd.conf.

vsFTPd can be setup to use local users. To do so:

• set local_enable=YES and chroot_local_user=YES (vsftpd.conf)
• create your system user (useradd) (with /sbin/nologin as the shell) - the user will be restricted to their home directory (the chroot directive above)
• set the password (passwd)
• Restart vsftpd for the config changes to take effect
• Login via FTP (not SFTP)

For SFTP (not using vsftpd!):

• Append /usr/libexec/openssh/sftp-server to /etc/shells
• Create a new user with the shell /usr/libexec/openssh/sftp-server
• Set the password for your new user
• Login via SFTP. You won't be restricted to your home directory here, but will not be able to write to locations where your user doesn't have permissions

Now for the permissions issue you are facing:

• Firstly, do NOT go and change the permissions or ownership on files just because you can't write to a directory. Most directories are owned by root, and only writeable by the owner.
• For a web server, keep your permissions restrictive - 644 (rw-r--r--) or less - (group and other should not need write permissions; and no one should need execute permissions in most cases)
• Set your file ownership to the same as the user your web server is running as if you use dynamic files (e.g. PHP).

Your options therefore are:

• Serve files from your user's home directory (instead of /var/www/html) - keep your user chrooted, and set the DocumentRoot in httpd.conf to point to the correct path. This is a good (secure) approach, but the typical change that is made is to set the user's home directory to a path under /var/www/html (e.g. for multiple people with their own sites, /var/www/html/USERNAME - with the DocumentRoot set accordingly)
• Give your Apache user FTP/SFTP access - it sounds reasonable, but especially using FTP is insecure.
• Use SCP and switch your user to root (sudo) - it has its uses, but not for saving files to a web server directory - all files created are owned by root

My recommendation would be SFTP with a certificate, and your home directories under /var/www/html

---

Disclaimer: it is much more secure to use certificates than passwords - and you should keep PasswordAuthentication disabled.

#Add the shell
echo /usr/libexec/openssh/sftp-server >> /etc/shells

#Create a user with the shell, I have not setup a home folder
useradd -M -s /usr/libexec/openssh/sftp-server USERNAME

#Set the password
passwd USERNAME

Edit /etc/ssh/sshd_config:
Change: PasswordAuthentication no to PasswordAuthentication yes (line 69), save and quit

#Restart SSH
service sshd restart

---

Since the sftp-server will not be in your chroot path, we need to change it: Change (in sshd_config):

Subsystem      sftp    /usr/libexec/openssh/sftp-server

To:

Subsystem     sftp   internal-sftp

Add the following to the end of your sshd_config (replace the path with, for instance, /var/www):

Match User USERNAME
    ChrootDirectory /path/to/restrict/to
    AllowTCPForwarding no
    X11Forwarding no
    ForceCommand internal-sftp
Match

Restart SSH:

service sshd restart

Comments

[Sean]

Thanks for the help! Thanks re. clarity about .htaccess, and diff between SFTP & vsFTPd. Re. "passive SFTP", I mean: in Filezilla's "general settings", it's set to SFTP, and "transfer settings" are presently set to passive. That allows ec2-user to login via SFTP. (Not sure what's the diff between passive and active transfer?) Got a .ppk keyfile stored on my local machine...imported into Filezilla under Edit>>Settings>>SFTP. Site's files are in /var/www/html. vsFTPd is installed, so tried your instructions for both vsFTPd and SFTP. Still can't login with myusername via Filezilla. :(

[Sean]

@cyberex86: Per your last paragraph--not sure how to either A) set DocumentRoot to point to /home/myusername, or B) set it to point /var/www/html/myusername. I'm okay if myusername has access directly to /var/www/html folder...but I do not want myusername to have sudo powers. I suppose might be wise for myusername to not have access via PuTTy (shell access?)...but right now, just want to make it dead simple for a user with a password to move their files via FTP (or SFTP). Could this be a firewall issue? Do I need to flush IPtables and turn off firewall(s)? (Amazon has its own firewalls.)

[cyberx86]

FileZilla is an FTP client - the 'passive' setting is for FTP, and is not used for SFTP. SFTP is over the SSH protocol - and in this cases uses your PuTTy keyfile (I might suggest WinSCP if you are using SFTP and Windows). Active FTP (again, unrelated to SFTP) has the server initiate a connection to a 'random' high numbered port on the client, while Passive FTP has the client initiate a connection to a high numbered port on the server. It seems that you are using SFTP - so ignore everything about vsFTPd and FTP for now.

[cyberx86]

The DocumentRoot is a directive in httpd.conf (or the included files) that tells Apache from where to serve files. It seems like the option you wish to pursue is: create a user with /var/www/html as the home folder - and chown -R username:group /var/www/html - you may even want to run apache as this user (again, set in httpd.conf). Sudo privileges are set with visudo in the sudoers file. Set the shell to /sbin/nologin (or to the sftp-server) to prevent SSH logins. Port 22 is needed for SFTP (the same as SSH), port 20, 21, and a high port range are needed for Passive FTP.

[cyberx86]

I have updated my answer with the specific steps for Amazon's Linux - just tested it out and I had no issue creating a user for SFTP. Since you can connect via SFTP with ec2-user, you do not have a firewall issue (although, I presume your firewall is not setup for passive FTP yet) - the default IPtables rules do not interfere with the connection - but Amazon's security group rules do - you will need to open the right ports there for FTP (but the SSH port is already open).

[Sean]

Thank you for your comprehensive answer. A couple noob'ish questions... 1) Is it a conflict if shell is appended with both /sbin/nologin AND sftp-server? 2) Concerned about the "EC2 uses keys for remote access" lingo in line 68 in the sshd config file. It's okay to change PasswordAuthentication yes on line 69 ...with that AWS comment? Or: will I lose access via PuTTy for ec2-user and root. ec2-user's login relies on the AWS key pair and logs-in without a password. Don't want to lose ec2-user access via PuTTy.

[cyberx86]

1) I believe you can only have one default shell - /bin/nologin is just a 'fake' shell - in this case, you setup the default shell to be sftp; the user can still login via SSH, but shouldn't be able to run any commands. Alternatively, you can install the restricted SSH shell (yum --enablerepo=epel install rssh) 2) EC2 uses keys - not passwords - so for increased security, password based access is disabled by default. If you enable it (setting the value to 'yes' - you can still use keys (but expect an increase in break-in attempts) - the value allows passwords without disabling anything.

[Sean]

Awesome! Thank you! Changed to PasswordAuthentication yes in sshd_config, and ec2-user can still login via PuTTy, and myusername can now login via Filezilla, but has no real privileges in Bash. But: myusername can still traverse entire directory tree in Filezilla, and still cannot write/transfer files or anything via FTP. THAT requires chmod of something by sudo, no? Regarding break-in attempts, what's the best practice to avoid that in this case...with SFTP set up as it is now?

[cyberx86]

1) To fix directory traversal, you need to chroot your user - I've added the instructions to do so to my answer. 2) The user must have write permissions to 'write' to a directory. If you change the ownership of your directory (chown) to your user, then the user will be able to write to the directory (and yes, chown needs to be run as root - i.e. with sudo). 3) Re: break-ins - setup some IPtables rules or Fail2ban to block repeated attempts; give your user the minimum privileges possible; chroot your user.

[cyberx86]

Also, since your original question has been answered - please close out this question, and ask any additional questions in a new question.

[Sean]

@cyberx88: You rock! Thank you so very much! I'd vote up the answer, but don't have enough rep yet. :( (PS: You've got a cool blog.)