How to Safely Create Restricted SSH/SFTP Users on Linux Servers

Security Best Practice Guide:
This article explains how to safely provide developers or contractors with restricted SSH/SFTP access to Linux servers without exposing the wider server environment or giving unnecessary privileges.

Providing temporary or permanent server access to developers is common in modern infrastructure management. However, granting unrestricted SSH access to production servers can introduce major security risks, especially on shared hosting systems or servers containing multiple client environments.

At JUCRA, we follow a least-privilege approach. Developers receive access only to the folders they require, using isolated Linux users, SSH key authentication, controlled filesystem permissions, and optional live activity monitoring.


Why Restricted SSH Access Matters

Many companies still make the mistake of giving developers:

  • Root access
  • Broad filesystem visibility
  • Shared server credentials
  • Password-based SSH logins

This creates unnecessary risk, especially on:

  • Shared hosting servers
  • Servers containing multiple customer accounts
  • Production environments
  • Email infrastructure servers

A properly restricted user account significantly reduces risk while still allowing developers to work efficiently.


Why SSH Keys Are Safer Than Passwords

JUCRA strongly recommends using SSH key authentication instead of passwords.

SSH keys are:

  • More secure than passwords
  • Resistant to brute force attacks
  • Easier to revoke individually
  • Better for audit and developer management
Important:
Developers should only send their public SSH key. They should NEVER send:

  • Private SSH keys
  • Root passwords
  • Server passwords

Understanding Public vs Private SSH Keys

Typical SSH key files:

The server administrator installs only the public key into:


Step 1 – Create the Linux User

This creates an isolated Linux user account with its own home directory.


Step 2 – Restrict Folder Access

Assign access only to the required application folder.

Example permissions:

  • Owner: full access
  • Group: full access
  • Others: no access

Instead of exposing the real server path directly, create a symlink inside the developer home directory.

This provides a cleaner and safer access structure.


Step 4 – Allow Safe Directory Traversal

To allow SFTP traversal without exposing directory listings, parent folders can use 711 permissions.

This allows:

  • Traversal into the allowed folder
  • No ability to browse other folders

Step 5 – Configure SSH Key Authentication

Create the SSH directory and install the public key.

Paste the developer public key into:

Then secure permissions:


Step 6 – Monitor Developer Activity

JUCRA commonly uses inotifywait for lightweight real-time monitoring.

Install inotify-tools

Monitor Activity

Example Output

This provides real-time visibility into:

  • Uploads
  • File edits
  • Deletes
  • Renames
  • Saves

Common Mistakes to Avoid

  • Giving developers root access unnecessarily
  • Sharing passwords instead of SSH keys
  • Using broad filesystem permissions such as 777
  • Allowing unrestricted access to /home directories
  • Using shared SSH accounts between multiple developers

JUCRA Security Recommendations

JUCRA recommends:

  • Using individual Linux users per developer
  • Using SSH public key authentication only
  • Restricting filesystem access to required folders only
  • Monitoring development activity on production servers
  • Avoiding root access unless absolutely necessary
  • Using least-privilege principles at all times