SSH keys and secure file copy

SSH is the backbone of working with remote Linux servers. You’re not using it right if you’re still typing passwords. Here’s the complete flow: generate a key, get it on the server, configure your client, and then move files securely.

Generating SSH Keys

You want ed25519 keys. They’re smaller, faster, and more secure than RSA. If your target server is ancient (pre-2014), fall back to RSA.

Ed25519 (modern servers — do this):

ssh-keygen -t ed25519 -C "you@laptop" -f ~/.ssh/id_ed25519

The -C flag is just a comment. The -f flag specifies where to save it. When prompted for a passphrase, use one — your key file itself is encrypted on disk.

RSA (legacy servers):

ssh-keygen -t rsa -b 4096 -C "you@laptop" -f ~/.ssh/id_rsa

The -b 4096 sets the key size to 4096 bits (stronger than the 2048 default, and still fast). Anything under 2048 is obsolete — don’t bother.

You now have two files: ~/.ssh/id_ed25519 (private key — never share) and ~/.ssh/id_ed25519.pub (public key — safe to distribute).

Getting Your Public Key to the Server

The easy way:

ssh-copy-id -i ~/.ssh/id_ed25519.pub username@example.com

ssh-copy-id handles all the fiddly details: it logs in (you’ll type your password one last time), appends your public key to ~/.ssh/authorized_keys on the server, and sets permissions correctly so SSH won’t complain.

If ssh-copy-id isn’t available (some Windows setups), do it manually:

cat ~/.ssh/id_ed25519.pub | ssh username@example.com "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Now test passwordless login:

ssh username@example.com

No password prompt? You’re done with auth. Close the connection and move on.

Configuring ~/.ssh/config

Stop typing ssh -p 2222 username@192.168.1.100. Create ~/.ssh/config:

Host homelab
    HostName 192.168.1.100
    User username
    Port 2222
    IdentityFile ~/.ssh/id_ed25519

Host production
    HostName prod.example.com
    User deploy
    IdentityFile ~/.ssh/id_rsa
    StrictHostKeyChecking accept-new

Now you just type ssh homelab. SSH uses the right user, port, and key automatically. You can add multiple hosts — each gets its own section.

Common options:

• HostName — the actual server address (IP or domain)
• User — username to log in as (overrides your local username)
• Port — non-standard SSH port if needed
• IdentityFile — which key to use for this host
• StrictHostKeyChecking accept-new — skip the “are you sure?” prompt on first connection (but still verify host keys thereafter)

Copying Files with SCP

SCP (secure copy) works like cp, except it can reach across the network over SSH.

Remote to local:

scp username@example.com:/var/log/app.log ~/Downloads/

Local to remote:

scp ~/myapp.jar username@example.com:/opt/apps/

Recursive (directories):

scp -r ~/myconfig/ username@example.com:/etc/myapp/

The -r flag means “recursively copy everything inside.” No -r? SCP treats it as a file and fails.

Using a non-standard SSH port:

scp -P 2222 ~/file.txt username@example.com:/tmp/

Note: it’s -P (capital), not -p. (Confusingly, ssh uses lowercase -p for ports. Different tools, different conventions.)

Host-to-host (remote to remote):

scp username@server1.com:/data/backup.tar.gz \
    username@server2.com:/backups/

Copying multiple files:

scp file1.txt file2.txt username@example.com:~/

Or use glob patterns:

scp username@example.com:~/logs/*.gz ~/backups/

Quick Cheatsheet

That’s it. Keys, config, and file transfers — the foundation of working with remote machines. Your 2 AM self will appreciate never having to type a password again.