SSH Permission Denied — chmod 777 Locked Our Deploy Team

Every time a developer deploys code to a production server, backs up a database, or fixes a bug on a remote machine at 2am, there's one tool quietly making it possible: SSH. It's the backbone of modern DevOps, cloud computing, and Linux server management. If you're getting into any of those fields — or just want to stop being afraid of the terminal — SSH is the single most important skill to learn first.

Before SSH existed, people used tools like Telnet to connect to remote machines. The problem? Everything — including your password — was sent across the network as plain text. Anyone sniffing the network traffic could read it. SSH (Secure Shell) solved this by encrypting the entire connection. It's the difference between shouting your bank PIN across a crowded room and whispering it through a private encrypted tunnel that only you and the server can decode. SCP (Secure Copy Protocol) builds on that same tunnel to let you copy files between machines, so you're never transferring sensitive data in the open.

By the end of this article you'll know exactly how SSH works and why it's secure, how to connect to a remote Linux server from your terminal, how to set up SSH key-based authentication so you never type a password again, and how to use SCP to send and receive files like a pro. You'll also avoid the most common beginner mistakes that cause frustrating 'Permission denied' errors.

What SCP and SSH Actually Do — And Why chmod 777 Broke Our Deploy

SSH (Secure Shell) is a cryptographic network protocol for operating network services securely over an unsecured network. SCP (Secure Copy) is a file transfer protocol built on SSH that copies files between hosts using the same authentication and encryption. The core mechanic: SCP opens an SSH session, spawns a remote scp process, and pipes file data through an encrypted tunnel. No separate daemon — it piggybacks on sshd.

SCP works by invoking a remote scp command via SSH, which reads or writes files with the permissions of the authenticated user. The protocol itself has no built-in permission control — it relies entirely on the remote filesystem's Unix permissions. When you run scp file user@host:/path/, the remote scp process writes the file with the umask of the SSH session. If the target directory has 777 permissions, any user on the remote box can overwrite the file — a common source of supply-chain attacks in CI/CD pipelines.

Use SCP when you need a simple, one-off file copy to a server you control, and you trust the network path. Do not use SCP for automated deploys to shared or multi-tenant environments — use rsync over SSH with strict permission checks, or a dedicated deployment tool like Ansible or Fabric. In production, SCP's lack of atomic writes and permission validation makes it a liability for deploy pipelines. Our team learned this the hard way when a 777 directory allowed a compromised container to overwrite our deploy script.

How SSH Works: The Locked Door and the Secret Handshake

SSH uses a concept called public-key cryptography. Think of it like a padlock you can hand out freely to anyone. You keep the key to that padlock completely private. Someone can lock a box using your padlock (encrypt data with your public key), but only you can open it (decrypt it with your private key). This is the core idea behind SSH keys.

When you connect to a server over SSH, here's what actually happens in the background:

1. Your client and the server agree on an encryption algorithm.
2. The server proves its identity to you using its own key (this prevents 'man-in-the-middle' attacks where someone pretends to be your server).
3. A unique session key is created just for this connection.
4. All traffic from that point on is encrypted with that session key.

You authenticate using either a password (convenient but weaker) or an SSH key pair (a private key on your machine + a public key on the server). Key-based auth is what every professional uses because it's both more secure and more convenient — no typing passwords, and automated scripts can connect without human input.

The default port for SSH is 22. When you hear someone say 'open port 22 in the firewall', this is what they mean.

# ─────────────────────────────────────────────────────────────
# BASIC SSH CONNECTION
# Syntax: ssh [username]@[server-address]
# ─────────────────────────────────────────────────────────────

# Connect to a remote server as user 'deploy' at IP 203.0.113.42
# SSH will prompt for the user's password if no key is configured
ssh deploy@203.0.113.42

# ─────────────────────────────────────────────────────────────
# CONNECT ON A NON-STANDARD PORT
# Some servers move SSH off port 22 for security (obscurity).
# Use the -p flag to specify a different port.
# ─────────────────────────────────────────────────────────────
ssh -p 2222 deploy@203.0.113.42

# ─────────────────────────────────────────────────────────────
# RUN A SINGLE COMMAND ON THE REMOTE SERVER WITHOUT STAYING LOGGED IN
# Useful in scripts — connect, run the command, disconnect immediately.
# Here we're checking available disk space on the remote machine.
# ─────────────────────────────────────────────────────────────
ssh deploy@203.0.113.42 'df -h /'

# ─────────────────────────────────────────────────────────────
# VERBOSE MODE — use -v to see exactly what SSH is doing
# Invaluable for debugging connection failures
# ─────────────────────────────────────────────────────────────
ssh -v deploy@203.0.113.42

SSH Key Authentication: Ditch the Password Forever

Password authentication works, but it has real problems. Passwords can be brute-forced, forgotten, or accidentally logged. SSH keys are essentially a 4096-bit random string — impossible to guess. And once they're set up, connecting feels like magic: you just type ssh deploy@yourserver.com and you're in.

Your private key lives in ~/.ssh/id_ed25519 (or id_rsa for older RSA keys). Your public key is ~/.ssh/id_ed25519.pub. The .pub file is the one you share freely. The private key file is the one you protect like a password — in fact, you can add an extra passphrase to it for a second layer of security.

ED25519 is the modern algorithm to use. It's faster and more secure than the older RSA algorithm. If you see old tutorials using ssh-keygen -t rsa, you can safely prefer ED25519 instead.

# ─────────────────────────────────────────────────────────────
# STEP 1: GENERATE AN SSH KEY PAIR ON YOUR LOCAL MACHINE
# -t ed25519       : use the modern ED25519 algorithm
# -C               : attach a comment so you know which key is which
# This creates two files:
#   ~/.ssh/id_ed25519      (PRIVATE key — never share this)
#   ~/.ssh/id_ed25519.pub  (PUBLIC key — copy this to servers)
# ─────────────────────────────────────────────────────────────
ssh-keygen -t ed25519 -C "alice@mycompany.com"

# You'll be prompted:
# Enter file in which to save the key (/home/alice/.ssh/id_ed25519): [press Enter]
# Enter passphrase (empty for no passphrase): [type a strong passphrase or press Enter]

# ─────────────────────────────────────────────────────────────
# STEP 2: COPY YOUR PUBLIC KEY TO THE REMOTE SERVER
# ssh-copy-id handles this safely — it appends your public key
# to ~/.ssh/authorized_keys on the server.
# The server will look at authorized_keys to decide who can log in.
# ─────────────────────────────────────────────────────────────
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@203.0.113.42

# ─────────────────────────────────────────────────────────────
# STEP 3: TEST THE KEY-BASED CONNECTION
# If setup is correct, you'll connect without being asked for a password.
# ─────────────────────────────────────────────────────────────
ssh deploy@203.0.113.42

# ─────────────────────────────────────────────────────────────
# BONUS: IF ssh-copy-id ISN'T AVAILABLE (e.g. on Windows or minimal systems)
# Manually append your public key to the server's authorized_keys file.
# This does the same thing as ssh-copy-id in one piped command.
# ─────────────────────────────────────────────────────────────
cat ~/.ssh/id_ed25519.pub | ssh deploy@203.0.113.42 \
  'mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys'

# ─────────────────────────────────────────────────────────────
# VIEW YOUR PUBLIC KEY (safe to copy-paste anywhere)
# ─────────────────────────────────────────────────────────────
cat ~/.ssh/id_ed25519.pub

SCP: Copying Files Over SSH Like a Pro

SCP (Secure Copy Protocol) uses the SSH connection you already understand to copy files between machines. The syntax looks a bit odd at first, but once you see the pattern, it clicks immediately.

The golden rule of SCP syntax: scp [source] [destination]. For remote paths, you prefix them with username@host:. That colon is the signal that says 'this path is on a remote machine'.

So scp alice@server:/var/log/app.log ./ means: copy the file /var/log/app.log from the remote server (as user alice) to my current local directory. And scp ./backup.tar.gz alice@server:/tmp/ means: copy my local backup.tar.gz file up to the /tmp/ directory on the remote server.

SCP preserves file permissions and timestamps by default when you use the -p flag. For entire directories, add -r (recursive) — just like cp -r for local copies.

One thing to know: SCP is being quietly deprecated on some modern systems in favour of rsync or sftp for large transfers, because those have better progress reporting and can resume interrupted transfers. But SCP is still everywhere, still reliable for one-off file transfers, and still the tool you'll use and see most often as a beginner.

# ─────────────────────────────────────────────────────────────
# SCP SYNTAX PATTERN:
# scp [options] [source] [destination]
# Remote path format: username@hostname:/path/to/file
# ─────────────────────────────────────────────────────────────

# ── UPLOAD: Copy a local file TO a remote server ─────────────
# Copy a compiled app package from your local machine
# up to the /var/www/releases/ directory on the production server
scp ./myapp-v2.1.0.tar.gz deploy@203.0.113.42:/var/www/releases/

# ── DOWNLOAD: Copy a file FROM a remote server to your machine ──
# Pull today's application log file from the server
# into your current local directory (./ means here)
scp deploy@203.0.113.42:/var/log/myapp/app-2024-01-15.log ./

# ── RECURSIVE: Copy an entire directory ──────────────────────
# -r means recursive (copy the folder and everything inside it)
# Upload a whole config directory to the server
scp -r ./nginx-configs/ deploy@203.0.113.42:/etc/nginx/sites-available/

# ── PRESERVE PERMISSIONS AND TIMESTAMPS ──────────────────────
# -p preserves the original file's modification time and permissions
# Useful when timestamps matter (e.g. log rotation scripts)
scp -p ./database-backup.sql deploy@203.0.113.42:/backups/

# ── SPECIFY A CUSTOM SSH KEY ──────────────────────────────────
# If you have multiple keys, tell SCP which identity file to use
# -i points to your private key
scp -i ~/.ssh/id_ed25519 ./config.yaml deploy@203.0.113.42:/app/config/

# ── NON-STANDARD PORT ─────────────────────────────────────────
# NOTE: SCP uses capital -P for port (unlike SSH which uses lowercase -p)
# This is one of the most common beginner typos!
scp -P 2222 ./deploy.sh deploy@203.0.113.42:/opt/scripts/

# ── COPY BETWEEN TWO REMOTE SERVERS (from your local machine) ─
# Your machine acts as the coordinator.
# Copy a file from server-A directly to server-B.
scp deploy@server-a.example.com:/var/exports/data.csv \
    deploy@server-b.example.com:/var/imports/

# ── SHOW PROGRESS FOR LARGE FILES ────────────────────────────
# -v (verbose) shows progress detail
# For a cleaner progress bar, use: rsync --progress (see Pro Tip below)
scp -v ./large-video-export.mp4 deploy@203.0.113.42:/media/uploads/

SSH Config File: Save Time with Host Aliases

If you routinely SSH into multiple servers with different usernames, ports, and keys, typing the full command each time becomes tedious. The SSH config file (~/.ssh/config) lets you define named hosts with all those details pre-configured.

Each host block starts with Host somealias, then indented options like: - HostName: the actual server hostname or IP - User: the remote username - Port: non-standard port - IdentityFile: which private key to use - LocalForward: port forwarding (advanced)

Once defined, you connect with just ssh somealias. SCP also respects these aliases: scp somealias:/remote/path ./ works too.

Configuration is read in order; the first matching Host pattern is used. Wildcards like Host *.example.com allow grouping servers.

# ─────────────────────────────────────────────────────────────
# EXAMPLE ~/.ssh/config FILE
# Each section starts with 'Host', followed by the alias you type.
# ─────────────────────────────────────────────────────────────

Host prod-web
    HostName 203.0.113.42
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_prod

Host staging-*
    HostName staging.example.com
    User admin
    IdentityFile ~/.ssh/id_ed25519_staging

# Default for all hosts (applied if no specific match)
Host *
    ServerAliveInterval 60
    TCPKeepAlive yes
    StrictHostKeyChecking ask

# After saving, you can run:
#   ssh prod-web
#   scp prod-web:/var/log/app.log ./
#   ssh staging-web1 (matches staging-* pattern)

SSH Security Best Practices: Protecting Your Server and Keys

Once you have SSH access to a server, locking it down is critical. The most important steps:

1. Disable root login: Prevent attackers from directly SSHing as root. Edit /etc/ssh/sshd_config: PermitRootLogin no. Use a regular user with sudo instead.
2. Disable password authentication: Rely only on key-based auth. Set PasswordAuthentication no in sshd_config.
3. Change the default SSH port (optional): Moving from port 22 to something like 2222 reduces automated attack traffic dramatically.
4. Use ED25519 keys: They are faster and more secure than RSA. Replace old RSA keys.
5. Install fail2ban: Blocks IPs after repeated failed login attempts, reducing brute-force risk.
6. Regularly audit authorized_keys: Remove unused public keys.
7. Use SSH certificates for teams (advanced): Instead of distributing public keys, use a certificate authority to sign temporary host keys.

Always test changes by keeping a second SSH session open so you don't lock yourself out.

package io.thecodeforge.ssh;

import com.jcraft.jsch.*;
import java.io.InputStream;

public class SshClient {
    private final Session session;

    public SshClient(String host, int port, String user, String privateKeyPath) throws JSchException {
        JSch jsch = new JSch();
        jsch.addIdentity(privateKeyPath);
        session = jsch.getSession(user, host, port);
        session.setConfig("StrictHostKeyChecking", "ask");
        session.connect();
    }

    public String executeCommand(String command) throws JSchException, IOException {
        Channel channel = session.openChannel("exec");
        ((ChannelExec) channel).setCommand(command);
        InputStream in = channel.getInputStream();
        channel.connect();
        byte[] tmp = new byte[1024];
        StringBuilder output = new StringBuilder();
        while (true) {
            int i = in.read(tmp, 0, 1024);
            if (i < 0) break;
            output.append(new String(tmp, 0, i));
        }
        channel.disconnect();
        return output.toString();
    }

    public void disconnect() {
        session.disconnect();
    }
}

SCP Through a Bastion: The Jump Host Dance

You don't SSH directly into production. No one who's survived a breach does. You land on a bastion host — a hardened jump box — and from there you pivot to the real server. SCP doesn't natively support this, so most people copy the file to the bastion first, then scp again. That's slow, writes intermediate garbage, and leaves secrets sitting on the jump box's disk.

Use scp -o ProxyJump instead. It tunnels the file transfer through the bastion in one encrypted hop. No intermediate files. No stale data on the jump host. Your security team won't have to send you a Slack about 'unauthorized file staging' on the bastion.

The syntax is simple: scp -o ProxyJump=bastion-user@bastion-host local-file target-user@target-host:/path/. SSH does the handshake through the bastion automatically. This works because SCP is just SSH under the hood — the same -o flags for ProxyJump that work with ssh work with scp.

If you're running a modern version of OpenSSH, you can also use the -J shorthand: scp -J bastion-user@bastion-host .... Same result, less typing. Your .ssh/config can even define the jump host per server, but that's a power move for later.

// io.thecodeforge — devops tutorial

# Transfer config.yaml from local to production via bastion
# Without leaving a temp copy on the jump host
local:
  file: /etc/nginx/conf.d/api-prod.yaml
bastion:
  user: jumpadmin
  host: bastion.acmecorp.net
target:
  user: deployer
  host: 10.0.1.50
  path: /etc/nginx/conf.d/

# Actual command:
scp -o ProxyJump=jumpadmin@bastion.acmecorp.net \
    /etc/nginx/conf.d/api-prod.yaml \
    deployer@10.0.1.50:/etc/nginx/conf.d/

Copying Directories Without Losing Your Mind

SCP can copy whole directories, but the default behavior will wreck your day. scp -r pulls everything — including broken symlinks, hidden dotfiles you didn't mean to ship, and .git directories that balloon the transfer size. I've seen a junior copy a 2GB node_modules directory across a datacenter because -r doesn't discriminate.

Use -rp for recursive with permission preservation. Then pair it with --exclude if you're using rsync. Wait — SCP doesn't have --exclude. That's why we sometimes drop down to rsync -avz -e ssh for directory transfers. But if you must use SCP, at least structure your source path with a trailing slash: scp -rp ./build/ server:/var/www/. The trailing slash copies the contents, not the folder itself, which is usually what you want.

For selective transfers, pipe through tar and SSH: tar czf - ./build | ssh server 'tar xzf - -C /var/www/'. This compresses on the fly and doesn't write to disk. It's not SCP, but it's the same SSH channel and it's faster for large trees.

Also: never scp -r /etc/ssh from an old server to a new one. You'll copy your host keys and break client trust. Copy configs, not identity.

// io.thecodeforge — devops tutorial

# Transfer a production build directory, preserving permissions
# Notice trailing slash on source — copies contents, not folder
source_dir: /home/ci/build-245/
target: deployer@app-server-01.prod.acme.net
path: /var/www/app/

# Good — trailing slash, permissions preserved
scp -rp /home/ci/build-245/ deployer@app-server-01.prod.acme.net:/var/www/app/

# Bad — no trailing slash, copies the folder ITSELF:
# Result: /var/www/app/build-245/
scp -rp /home/ci/build-245 deployer@app-server-01.prod.acme.net:/var/www/app/

# Faster for large trees — tar over SSH (not SCP, but same tunnel)
tar czf - /home/ci/build-245/ | ssh deployer@app-server-01.prod.acme.net 'tar xzf - -C /var/www/app/'