Enabling SFTP in Digitalocean allows us to use an encrypted SSH connection to transfer files between machines in a secure manner.

As part of our Digitalocean Managed Service, Bobcares responds to all questions, no matter how trivial.

Let’s take a closer look at how to enable SFTP in DigitalOcean in more detail.

Enabling SFTP in Digitalocean

SSH File Transfer Protocol, or SFTP for short, is a safe way to move files between computers over an encrypted SSH connection. Despite having a similar name to FTP (File Transfer Protocol), this is a different protocol. However, SFTP is widely supported by current FTP clients.

On all servers with SSH access enabled, SFTP is available by default without any additional configuration. One drawback of SFTP is that, in a typical configuration, the SSH server grants file transfer access and terminal shell access to all users with an account on the system, although it is secure and generally easy to use. Applying granular control over user permissions is frequently safer. For instance, we might only want to allow certain users to transfer files over SSH, but not allow them to access the server’s terminal.

How To Enable SFTP On Ubuntu Without Shell Access

Step 1: New User Creation

1. Firstly, create a new user who will only have access to the server for file transfers.

   sudo adduser bobcares_sftp
2. Then we’ll need to create a password for the account before being given some user-related information. If we want to omit the user information, we can press ENTER to do so.
3. A new user who will have access to the restricted directory has now been created.
4. Finally, we’ll create the file transfer directory and configure the required permissions.

Step 2: Making a File Transfer Directory

We must first ensure that the directory satisfies the very specific permissions requirements of the SSH server in order to restrict SFTP access to a single directory.

Specifically, the root must own and be able to write to the directory as well as every directory that comes before it in the filesystem tree. Since the user owns the home directories, not the root, it is not possible to grant restricted access to a user’s home directory.

There are numerous solutions to the ownership problem. Here, we’ll create and use the target upload directory, /var/sftp/uploads. The user bobcares_sftp will owns the subdirectory /var/sftp/uploads. This allows the user to upload files there even though root owns /var/sftp and inaccessible to other users.

1. Firstly, we create the directories:

   sudo mkdir -p /var/sftp/uploads
2. Then, make root the owner of /var/sftp:

   sudo chown root:root /var/sftp
3. Then, give root write permissions to the same directory while granting read-only access to other users:

   sudo chmod 755 /var/sftp
4. Finally, assign the newly created user ownership of the uploads directory. Be sure to modify the following command if we gave the user we created a different name because it once again uses the example user and group bobcares_sftp:

   sudo chown bobcares_sftp:bobcares_sftp /var/sftp/uploads

After setting up the directory structure, we can configure the SSH server.

Step 3: Limiting Access to One Directory

In this step, we’ll change the SSH server configuration so that bobcares_sftp can only access files but not the terminal.

1. Firstly, launch nano or any preferred text editor and open the SSH server configuration file:

   sudo nano /etc/ssh/sshd_config
2. Add the configuration snippet that follows at the file’s very bottom:

   Match User bobcares_sftp
   ForceCommand internal-sftp
   PasswordAuthentication yes
   ChrootDirectory /var/sftp
   PermitTunnel no
   AllowAgentForwarding no
   AllowTcpForwarding no
   X11Forwarding no
3. Then, save and exit the file after adding these lines. When using nano, we can accomplish this by pressing CTRL + X, Y, and ENTER.
4. Finally, restart the service to take effect of the configuration changes:

   sudo systemctl restart sshd

As of right now, bobcares_sftp can only access the SSH server for file transfers. Testing the configuration to ensure that it functions as intended is the final step.

Step 4: Checking the Configuration

Let’s make sure the bobcares_sftp user we just created can only transfer files. As was already mentioned, we use SFTP to move files between computers. By checking a transfer between our local machine and the server, we can confirm that this is functional.

1. Firstly, try logging in to the server as the user we made in Step 1. This won’t be possible because of the settings we added to the SSH configuration file:

   ssh bobcares_sftp@server_ip
2. Before returning to the initial prompt, we will receive the following message:

   
Output
This service allows sftp connections only.
Connection to server_ip closed.


   This implies that bobcares_sftp can no longer connect via SSH to the server shell.
3. Then check to see if the user can transfer files using SFTP:

   sftp bobcares_sftp@server_ip
4. This command will produce a successful login message with an interactive prompt rather than an error message:
Output
Connected to server_ip
sftp>

5. Then, by typing ls in the prompt, we can list the directory’s contents.
6. This will display the uploads directory from the previous step. Also bring us back to the sftp> prompt.
7. We can try setting the directory to the previous one to see if the user is indeed limited to this directory and is unable to access any directories before it: sftp> cd
8. In order to show the user was unable to change to the parent directory, this command will list the directory contents as they were previously without giving an error.

Now this establishes its functionality, the restricted configuration. The newly created bobcares_sftp user can connect to the server only for file transfers using the SFTP protocol. However, it doesn’t permits  access to the full shell.

[Looking for a solution to another query? We are just a click away.]

Conclusion

In conclusion, we’ve limited a user’s access to a single directory on a server without full shell access to SFTP-only access. For the sake of simplicity, our Support team only uses one directory and one user. However, we can adapt this example to include multiple users and multiple directories.