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.
Table of Contents
- Why Restricted SSH Access Matters
- Why SSH Keys Are Safer Than Passwords
- Understanding Public vs Private SSH Keys
- Step 1 – Create the Linux User
- Step 2 – Restrict Folder Access
- Step 3 – Create a Safe Symlink
- Step 4 – Allow Safe Directory Traversal
- Step 5 – Configure SSH Key Authentication
- Step 6 – Monitor Developer Activity
- Common Mistakes to Avoid
- JUCRA Security Recommendations
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
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:
1 2 | id_ed25519.pub = Public key (safe to share) id_ed25519 = Private key (NEVER shared) |
The server administrator installs only the public key into:
1 | ~/.ssh/authorized_keys |
Step 1 – Create the Linux User
1 2 | useradd -m developer_user passwd developer_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.
1 2 | chgrp developer_user /home/example/public_html/project-folder chmod 2770 /home/example/public_html/project-folder |
Example permissions:
1 | drwxrws--- |
- Owner: full access
- Group: full access
- Others: no access
Step 3 – Create a Safe Symlink
Instead of exposing the real server path directly, create a symlink inside the developer home directory.
1 | ln -s /home/example/public_html/project-folder /home/developer_user/project-folder |
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.
1 2 | chmod 711 /home/example chmod 711 /home/example/public_html |
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.
1 2 3 | mkdir -p /home/developer_user/.ssh chmod 700 /home/developer_user/.ssh nano /home/developer_user/.ssh/authorized_keys |
Paste the developer public key into:
1 | authorized_keys |
Then secure permissions:
1 2 | chmod 600 /home/developer_user/.ssh/authorized_keys chown -R developer_user:developer_user /home/developer_user/.ssh |
Step 6 – Monitor Developer Activity
JUCRA commonly uses inotifywait for lightweight real-time monitoring.
Install inotify-tools
1 | dnf install -y inotify-tools |
Monitor Activity
1 2 3 4 5 | inotifywait -m -r \ -e create,modify,delete,move,close_write \ --format '%T | %e | %w%f' \ --timefmt '%Y-%m-%d %H:%M:%S' \ /home/example/public_html/project-folder |
Example Output
1 2 3 | 2026-05-26 15:18:04 | CREATE | /path/test.php 2026-05-26 15:18:04 | MODIFY | /path/test.php 2026-05-26 15:18:05 | CLOSE_WRITE,CLOSE | /path/test.php |
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
- developer access
- filezilla sftp
- inotifywait
- least privilege security
- linux administration
- linux permissions
- linux security
- linux server security
- linux user permissions
- restricted sftp user
- restricted ssh user
- secure developer access
- secure file access
- server hardening
- sftp
- sftp monitoring
- shared hosting security
- ssh
- ssh key authentication
- ssh public key