share ssh public key on sftp configuration

Question

I've configured a SFTP server on CentOS following this doc. My intention is to forbid the console login for the new users (user1, user2), which belong to the sftpusers group, but still can log in to their respective sftp folders.

Also, I want to use the same keys used by the CentOS user (which can log in to console and sftp without problem). To do that, I copied the .ssh folder from CentOS user to the user1 and user2 home folders, changing ownership to the users and 700 for the .ssh folder and 600 for authorized_keys file.

Still, I keep receiving the message Server refused our key. The key used by the CentOS user is like a master key in all servers, that is why I want to reuse that key for the new users.

How can I achieve this configuration?

UPDATE

After generating keys for each user both users can access to server remotely with their privates keys but when I activate the following config in /etc/ssh/sshd_config the permissions are denied using the sftp command.

SSHD configuration

Match Group sftpusers #Or you could replace Group with User and specify a different configuration for each user
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
ChrootDirectory /path/to/shared_folder/%u # %h the path to upload the files
ForceCommand internal-sftp

Message from shell

packet_write_wait: Connection to IPSERVER port 22: Broken pipe
Couldn't read packet: Connection reset by peer

Answer 1

The update introduces an issue different than the original question. It looks like the original issue is not a problem anymore. I'm addressing the update.

The manual reads:

ChrootDirectory
Specifies the pathname of a directory to chroot(2) to after authentication. At session startup sshd(8) checks that all components of the pathname are root-owned directories which are not writable by any other user or group.

My tests indicate if this condition is not satisfied then one will get Broken pipe when trying to log in with sftp.

In your case the pathname is /path/to/shared_folder/%u. Note %u (after expansion) is also a component; therefore it should be "root-owned and not writable by any other user or group". You should fix the ownership and permissions. Then, obviously, the user will not be able to write to the directory. Whatever pathname you use with ChrootDirectory, the user will not be able to write to it (unless the user is root). In other words the user will not be able to write to / in the chrooted environment. To allow writing, you need a subdirectory. There are few ways to deal with this.

• Using home directories in a common chroot directory.

  The manual also states:

  After the chroot, sshd(8) changes the working directory to the user's home directory.

  I assume home directories are like /home/user1, /home/user2 etc. by default. This suggests the following scenario:

  1. Setup the server to chroot to /path/to/shared_folder (no %u):

     ChrootDirectory /path/to/shared_folder
     

  2. Replicate the relevant directory structure there (/path/to/shared_folder/home/user1 etc.).

  3. Satisfy the condition for path, to and shared_folder.
  4. Make ownership and permissions of home like they are for the regular /home.
  5. Make ownership and permissions of directories inside home like they are for directories in /home.

  With this setup sftp will automatically place user1 in /path/to/shared_folder/home/user1 after authenticating, but they will see it as /home/user1 due to chroot.

• Using custom directories in a common chroot directory.

  With ForceCommand internal-sftp you can specify the starting directory (internal-sftp supports the same set of options as sftp-server). Like this:

  ChrootDirectory /path/to/shared_folder
  ForceCommand internal-sftp -d /home/%u
  

  to make sure sftp users will use /path/to/shared_folder/home/… regardless of their formal home directories in the OS. Or like this:

  ChrootDirectory /path/to/shared_folder
  ForceCommand internal-sftp -d /%u
  

  to simplify paths and get rid of this home in the middle. This way user1 will see they are in /user1 after logging in with sftp. In this case shared_folder should directly contain user folders (not home).

• Using at least one subdirectory in a chroot directory specific to the user.

  The solutions above allow users to browse each other's directories. A user will be able to chmod their files (sftp supports chmod) to grant or deny access.

  You used %u with ChrootDirectory, so you most likely want to create separate chroot directories. In such case do what you did:

  ChrootDirectory /path/to/shared_folder/%u
  

  and set ownership and permissions of every component (including what %u expands to) to satisfy the condition. Unless it's about read-only access, you need at least one subdirectory that will be writable by the user. Few possibilities:

  • replicating path to the user's home directory, as defined in the OS;
  • forcing /home/%u with ForceCommand internal-sftp -d /home/%u;
  • forcing /%u with ForceCommand internal-sftp -d /%u;
  • using a fixed subdirectory name, e.g. ForceCommand internal-sftp -d /files.

  In each case you need to prepare the directory structure inside /path/to/shared_folder. E.g. if you want to force /home/user1 for user1, the relevant path will be:

  /path/to/shared_folder/user1/home/user1
  

  where path, to, shared_folder and (the first) user1 satisfy the condition, home simulates /home and (the second) user1 is writable by the user.

More flexible approaches are possible. E.g. you can have a common chroot directory for user1 and user2, but different one for user3.

Chroot directory common or not, personally I would make the subdirectories in the least surprising fashion, so any user find themselves in a directory they kinda expect. After typing pwd in sftp they should see like /home/user1. I find other possibilities (/user1, /files) somewhat surprising.