Setting up sftp on Amazon Linux 2 with ssh keys, user segregation (sftp vs ssh), different ports, and user directory constraints

amazon ec2amazon-linuxamazon-linux-2sftpssh-keys

TDLR: I have a Catch 22 where, depending on permissions on the user's home directory, I can get the SSH authentication to work, or the user directory constraints, but not both.

BTW, I really want to roll my own SFTP server. Please don't recommend I try AWS Transfer service or something alternative. Thanks.

Here is relevant (changed from default) content in /etc/ssh/sshd_config:

Subsystem sftp internal-sftp
Port 22
Port 2299
Match Group sftpusers LocalPort 2299
  ChrootDirectory /sftp-data/%u
  ForceCommand internal-sftp
Match Group sftpusers LocalPort 22
  DenyGroups sftpusers
Match LocalPort 2299  Group *,!sftpusers
  DenyUsers *

I want port 22 functioning as ssh typically does, but only for non-sftp users. For sftp users, in group "sftpusers", I want port 2299 to function as sftp only, and not ssh. For non-sftpusers, I want access to port 2299 denied.

Ok, so, I created a user "user1" with home directory /sftp-data/user1 and shell /sbin/nologin. I created /sftp-data/user1/.ssh/authorized_keys and populated that with the public ssh key. /sftp-data is owned by root with 700 permissions. /sftp-data/user1/.ssh and below are owned by user1, and /sftp-data/user1/.ssh/authorized_keys has permission 600. The ownership/permissions of /sftp-data/user1 are under question here. More below.

I created the user group sftpusers and added user1 to that group. The built-in ec2-user you get with AWS is not a member of that group, however. Testing with ec2-user worked great: access via ssh, port 22 worked as it always does, but no access to port 2299.

So, testing with user1 is where it got interesting. User1 has no access to port 22 – that's great! With user1 owning /sftp-data/user1, the ssh public key authentication succeeds on port 2299, but the user is immediately logged out, with this message saved in /var/log/secure:

Sep  2 19:21:38 ip-192-168-0-25 sshd[10369]: Accepted publickey for user1 from <ip-address redacted> port 61110 ssh2: ECDSA SHA256:<sha redacted>
Sep  2 19:13:23 ip-192-168-0-25 sshd[9803]: pam_unix(sshd:session): session opened for user user1 by (uid=0)
Sep  2 19:13:23 ip-192-168-0-25 sshd[9803]: fatal: bad ownership or modes for chroot directory "/sftp-data/user1" [postauth]
Sep  2 19:13:23 ip-192-168-0-25 sshd[9803]: pam_unix(sshd:session): session closed for user user1

Sure, that makes sense. Chroot requires /sftp-data/user1 to be owned by root, permissions 700. So, make that so, and now the sftp (ssh key) authentication fails.

Sep  2 19:41:00 ip-192-168-0-25 sshd[11693]: error: AuthorizedKeysCommand /opt/aws/bin/eic_run_authorized_keys user1 SHA256:<sha redacted> failed, status 22

BTW, eic_run_authorized_keys is a wrapper AWS puts around standard ssh authentication to enable AWS Instance Connect.

For extra credit… if the above problem is not challenging enough, can you come up with a scheme where I can give particular sftp users access to particular project directories, and only those, without creating a group for every project? Link from each user's home directory to a project directory would be awesome.

Additional info requested by @anx:

# getent passwd user1
user1:x:1001:1001::/sftp-data/user1:/sbin/nologin
# namei -l /sftp-data/user1/.ssh/authorized_keys
f: /sftp-data/user1/.ssh/authorized_keys
dr-xr-xr-x root  root      /
drwxr-xr-x root  root      sftp-data
drwx------ root  root      user1
drwx------ user1 sftpusers .ssh
-rw------- user1 sftpusers authorized_keys

I turned on DEBUG logging for sshd. Using the ChrootDirectory directive, with /sftp-data/user1 owned by root, and SSH authentication failing, I see this in /var/log/secure:

debug1: Could not open authorized keys '/sftp-data/user1/.ssh/authorized_keys': Permission denied

ps clearly shows me that root is running the sshd process.

Best Answer

Your ChrootDirectory is /sftp-data/user1, which must be owned by root. And it is:

# namei -l /sftp-data/user1/.ssh/authorized_keys
f: /sftp-data/user1/.ssh/authorized_keys
dr-xr-xr-x root  root      /
drwxr-xr-x root  root      sftp-data
drwx------ root  root      user1
drwx------ user1 sftpusers .ssh
-rw------- user1 sftpusers authorized_keys

However, at this point the sshd has already changed the user to user1 and dropped privileges, so user1 cannot descend into lower level directories. To do that the directory needs search permission (a+x).

chmod a+x /sftp-data/user1

Now user1 can descend to subdirectories and the .ssh directory should be readable.

Related Solutions

Ftp – EC2 FileZilla login OK but no write or delete access

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

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
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).
Are you trying to use FTP to SFTP?
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

The specific commands for adding an SFTP user on Amazon's Linux:

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

To restrict your user to one directory (i.e. chroot):

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

Linux – permission denied on authorized_keys

I got it!

Following the directions on this site: http://sysadmin.circularvale.com/server-config/rsa-authentication-with-chrooted-sftp-authorized_keys-location/

As root, I created a separate folder in:

 /usr/local/share/keys/globocorp/.ssh/

This folder is owned by root, permissions set to "755"
authorized_keys file is in this folder, and owned by the user, permissions set to 600.

sshd_config contains this line:

AuthorizedKeysFile /usr/local/share/keys/%u/.ssh/authorized_keys

And this match block:

Match user globocorp
        ChrootDirectory /sftp/%u
        X11Forwarding no
        AllowTcpForwarding no
        ForceCommand internal-sftp -l VERBOSE -f LOCAL6
        PubkeyAuthentication yes
        PasswordAuthentication yes

So in conclusion:
The authorized_keys of a chrooted user CAN be in a location that the user is chrooted out of. This is because the chroot is not processed until after login. Permissions should be EXACTLY as described above- no other permissions worked. (Not 700 on the parent directory) Paths defined in sshd_config are absolute (/ = the / of the server, not the user's chroot!)

To debug this, I used this command to run sshd on a separate port(23) and not interrupt existing sessions:

/usr/sbin/sshd -d -p 23

And then attempted to connect via SFTP from a remote server. This caused the server side to output useful debug messages that explained clearly what was happening on my login attempts.

Best Answer

Related Solutions

Ftp – EC2 FileZilla login OK but no write or delete access

Linux – permission denied on authorized_keys

Related Topic