How to Set Up Secure File Sharing in Linux: A Comprehensive Guide

Introduction

Secure file transfer is a mandatory requirement when working with confidential data, server infrastructure, or in compliance with information security policies. Linux provides powerful built-in tools that use SSH cryptography to protect transmitted information from interception and tampering. In this guide, you will master three primary methods: SCP (simple copy), SFTP (interactive protocol), and pre-encryption of files. All methods work on standard distributions without installing additional software.

System Requirements

Before you begin, ensure that:

1. On the remote server an SSH server (sshd) is installed and running. Check:

   sudo systemctl status ssh   # Ubuntu/Debian
   sudo systemctl status sshd  # CentOS/RHEL/Fedora
   

2. On the local machine you have an SSH client (usually pre-installed).
3. You have credentials (login and password or key-based access) for the remote server.
4. Port 22 (or a custom SSH port) is open in the server's firewall.
5. For GPG encryption, install gnupg:

   sudo apt install gnupg   # Debian/Ubuntu
   sudo dnf install gnupg   # Fedora/CentOS
   

Step 1: Installing and Configuring the SSH Server

If SSH is not yet running on the target server, perform the installation:

For Debian/Ubuntu:

sudo apt update
sudo apt install openssh-server
sudo systemctl enable --now ssh
sudo ufw allow 22/tcp   # If using UFW

For RHEL/CentOS/Fedora:

sudo dnf install openssh-server
sudo systemctl enable --now sshd
sudo firewall-cmd --add-service=ssh --permanent
sudo firewall-cmd --reload

Verification: Connect from the local machine:

ssh user@server_address

If the connection is successful, the server is ready.

Step 2: Configuring SSH Key-Based Authentication

Password authentication is vulnerable to brute-force attacks. Keys provide secure automatic login.

2.1 Generating a Key Pair

On the local machine, run:

ssh-keygen -t ed25519 -C "your_email@example.com"

Or for compatibility with older systems:

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Press Enter to save the key in ~/.ssh/id_ed25519 (or id_rsa). It is recommended to set a passphrase for additional key protection.

2.2 Copying the Public Key to the Server

The simplest method:

ssh-copy-id user@server_address

If the command is not available, copy manually:

cat ~/.ssh/id_ed25519.pub | ssh user@server_address "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

2.3 Verifying and Securing Permissions

On the server, run:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Login should now work without a password (key-based only). Verify:

ssh user@server_address

Step 3: File Transfer via SCP (Secure Copy)

SCP is ideal for one-time copy operations. Its syntax is similar to cp, but with a remote host specification.

3.1 Copying from Local Machine to Server

scp /local/path/file.txt user@server_address:/remote/path/

Example with compression (the -C flag speeds up text file transfer):

scp -C archive.tar.gz user@192.168.1.10:/backup/

3.2 Copying from Server to Local Machine

scp user@server_address:/remote/file.log /local/path/

3.3 Recursive Directory Copy

scp -r /local/folder user@server_address:/remote/folder

3.4 Copying via a Non-Standard SSH Port

scp -P 2222 file.txt user@server:/path/

⚠️ Important: The -P (uppercase P) flag sets the port for SCP. The SSH client uses -p (lowercase).

Step 4: File Management via SFTP

SFTP provides more control: viewing, deleting, renaming files in interactive mode.

4.1 Connecting

sftp user@server_address

Or with a specified port:

sftp -P 2222 user@server_address

4.2 Basic SFTP Commands

Example session:

sftp user@example.com
sftp> lcd ~/Downloads
sftp> put report.pdf /var/www/backups/
sftp> get /etc/config.yaml ~/config_backup/
sftp> bye

Step 5: Additional File Encryption (GPG/OpenSSL)

If files contain highly sensitive data (keys, personal data), encrypt them before transfer, even if using SSH.

5.1 Encryption with GPG (Recommended)

Encryption for a specific recipient (requires their public key):

gpg --encrypt --recipient recipient@email.com file.txt

Result: file.txt.gpg. The recipient decrypts with their private key:

gpg --decrypt file.txt.gpg > file.txt

Password-based encryption (symmetric):

gpg -c file.txt

You will be prompted for a password. Decryption:

gpg -d file.txt.gpg > file.txt

5.2 Encryption via OpenSSL (Alternative)

Symmetric AES-256 encryption:

openssl enc -aes-256-cbc -salt -in file.txt -out file.txt.enc

Enter the password. Decryption:

openssl enc -d -aes-256-cbc -in file.txt.enc -out file.txt

💡 Tip: For automation, use environment variables or scripts that prompt for the password via read -s. Never store passwords in plain text in scripts!

Verifying the Result

After transfer, ensure files are not corrupted and encrypted (if additional encryption was used).

1. Integrity check via hashes: On the local machine:

   sha256sum file.txt
   

   
   On the server (after transfer):

   sha256sum file.txt
   

   
   Compare the output. The hashes must match.
2. Encryption check: Try to open the transferred file (e.g., .gpg or .enc). The system should request a password or key. If the file opens without a password, encryption was not applied.
3. Permission check: Ensure the file has the correct owner and permissions on the server:

   ls -l /remote/path/file.txt
   

Common Issues and Solutions

Issue 1: Permission denied (publickey,password)

Cause: The server does not accept your key or requires a password. Solution:

• Check that the public key is added to ~/.ssh/authorized_keys on the server.
• Ensure correct permissions: chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys.
• Verify that /etc/ssh/sshd_config allows key authentication: PubkeyAuthentication yes.
• Restart SSH: sudo systemctl restart ssh.

Issue 2: Connection refused or Timeout

Cause: SSH server not running, port blocked by firewall, or server unreachable. Solution:

• Check service status (see Step 1).
• Check the firewall: sudo ufw status (Ubuntu) or sudo firewall-cmd --list-all.
• Ensure the server responds to pings: ping server_address.
• If using a non-standard port, specify it with -P (SCP) or -p (SFTP).

Issue 3: Transfer Interrupts on Large Files

Cause: Unstable connection, SSH timeouts. Solution:

• Enable compression in SCP/SFTP: add the -C flag.
• Increase timeouts in ~/.ssh/config on the client:

  Host *
      ServerAliveInterval 60
      ServerAliveCountMax 3
  

• Split the file into parts: split -b 1G large_file.iso part_.
• Use rsync with the --partial option to resume.

Issue 4: Low Transfer Speed

Cause: Network limitations, high disk load, no compression. Solution:

• Use compression (-C in SCP; configure -C in SFTP).
• Check network load: iftop or nethogs.
• For local networks, verify interface speeds: ethtool eth0.
• If transferring many small files, pack them into an archive: tar czf archive.tar.gz folder/.

Issue 5: GPG/OpenSSL Encryption Errors

Cause: Missing recipient's key, incorrect password, corrupted file. Solution:

• For GPG: check for the recipient's public key: gpg --list-keys.
• If the key is missing, request it from the recipient or import from a key server: gpg --keyserver hkps://keys.openpgp.org --search-keys email.
• For OpenSSL: ensure you use the same algorithm (-aes-256-cbc) and password.
• Check the encrypted file's integrity: file file.txt.gpg should show "GPG encrypted data".

Issue 6: SFTP Does Not Allow Deleting/Renaming Files

Cause: Insufficient permissions on the server. Solution:

• Ensure the user has write permissions in the directory: ls -ld /path/.
• Change owner/permissions: sudo chown user:group file and chmod 644 file.
• If chroot is used in SSH, check settings in sshd_config.

This set of solutions covers 90% of typical scenarios. In other cases, check the SSH logs on the server:

sudo tail -f /var/log/auth.log   # Debian/Ubuntu
sudo tail -f /var/log/secure     # CentOS/RHEL