SSH encrypts all traffic using public-key cryptography — your password never crosses the network in plain text.
SCP uses the same secure tunnel as SSH to copy files between machines.
Key-based authentication eliminates passwords and protects against brute-force attacks.
ED25519 keys are ~2x faster than RSA 4096 for authentication and more secure.
Biggest mistake: incorrect ~/.ssh permissions silently break key-based login — if you're remote, you're locked out until you fix via console.
Plain-English First
Imagine your server is a locked house on the other side of the world. SSH is the secure phone line you use to talk to the person inside and tell them what to do — nobody else can listen in. SCP is the same secure phone line, but instead of giving instructions, you're using it to send or receive packages (files). Both use the same lock-and-key system, so everything stays private and tamper-proof.
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.
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:
Your client and the server agree on an encryption algorithm.
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).
A unique session key is created just for this connection.
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.shBASH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
# ─────────────────────────────────────────────────────────────
# BASICSSHCONNECTION
# Syntax: ssh [username]@[server-address]
# ─────────────────────────────────────────────────────────────
# Connect to a remote server as user 'deploy' at IP203.0.113.42
# SSH will prompt for the user's password if no key is configured
ssh deploy@203.0.113.42
# ─────────────────────────────────────────────────────────────
# CONNECTON A NON-STANDARDPORT
# Some servers move SSH off port 22forsecurity (obscurity).
# Use the -p flag to specify a different port.
# ─────────────────────────────────────────────────────────────
ssh -p 2222 deploy@203.0.113.42
# ─────────────────────────────────────────────────────────────
# RUN A SINGLECOMMANDONTHEREMOTESERVERWITHOUTSTAYINGLOGGEDIN
# 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 /'
# ─────────────────────────────────────────────────────────────
# VERBOSEMODE — use -v to see exactly what SSH is doing
# Invaluablefor debugging connection failures
# ─────────────────────────────────────────────────────────────
ssh -v deploy@203.0.113.42
Output
# After running: ssh deploy@203.0.113.42
The authenticity of host '203.0.113.42 (203.0.113.42)' can't be established.
ED25519 key fingerprint is SHA256:abc123XYZexampleFingerprint.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '203.0.113.42' (ED25519) to the list of known hosts.
deploy@203.0.113.42's password:
Welcome to Ubuntu 22.04.3 LTS (GNU/Linux 5.15.0-91-generic x86_64)
deploy@web-server-01:~$
# After running: ssh deploy@203.0.113.42 'df -h /'
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 50G 18G 30G 38% /
Watch Out: That 'Authenticity Can't Be Established' Message
The first time you connect to a server, SSH warns you it doesn't recognise it yet and shows you a fingerprint. Type 'yes' and SSH saves that fingerprint in ~/.ssh/known_hosts. Next time you connect, it checks the fingerprint matches. If it doesn't match on a future connection, SSH screams at you — this is intentional and means something changed on the server side (or someone is intercepting your connection). Never blindly ignore that warning.
Production Insight
If you ever see 'Host key verification failed' and you haven't rebuilt the server, someone could be intercepting your connection. Never bypass this warning by deleting the host key without verifying.
The first connection prompt is your only chance to validate server identity — use ssh-keygen -l -f to compare fingerprints out of band.
Rule: Always verify server fingerprints and never blindly accept changed host keys.
Key Takeaway
SSH uses asymmetric cryptography to establish a secure channel.
The host key verification protects against man-in-the-middle attacks.
Always verify server fingerprints on the first connection.
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.
Here's how key-based auth works
You generate a key pair: a private key (stays on your laptop, never shared) and a public key (copied to the server).
When you connect, SSH uses cryptographic math to prove you possess the private key without ever transmitting it.
The server confirms the proof matches the public key it has stored for you.
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.
ssh_key_setup.shBASH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
# ─────────────────────────────────────────────────────────────
# STEP1: GENERATEANSSHKEYPAIRONYOURLOCALMACHINE
# -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]
# Enterpassphrase (empty for no passphrase): [type a strong passphrase or press Enter]
# ─────────────────────────────────────────────────────────────
# STEP2: COPYYOURPUBLICKEYTOTHEREMOTESERVER
# 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
# ─────────────────────────────────────────────────────────────
# STEP3: TESTTHEKEY-BASEDCONNECTION
# 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'
# ─────────────────────────────────────────────────────────────
# VIEWYOURPUBLICKEY (safe to copy-paste anywhere)
# ─────────────────────────────────────────────────────────────
cat ~/.ssh/id_ed25519.pub
Output
# After running ssh-keygen:
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/alice/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/alice/.ssh/id_ed25519
Your public key has been saved in /home/alice/.ssh/id_ed25519.pub
Instead of typing ssh deploy@203.0.113.42 -p 2222 -i ~/.ssh/id_ed25519 every time, create a shortcut in ~/.ssh/config. Add: Host myserver\n HostName 203.0.113.42\n User deploy\n Port 2222\n IdentityFile ~/.ssh/id_ed25519. Now you just type ssh myserver. This also works with SCP: scp myserver:/var/log/app.log ./.
Production Insight
If you accidentally run chmod -R 777 ~ on your local machine, SSH will refuse to use your private key. You'll be locked out of every server until you fix permissions.
On the server, if authorized_keys has group-writable permissions, SSH silently ignores it — even with the correct key.
Rule: Set ~/.ssh to 700 and authorized_keys to 600, and never change them.
Key Takeaway
Key-based auth is more secure and convenient than passwords.
ED25519 is the recommended key type; use ssh-copy-id to install public keys.
File permission mistakes are the #1 cause of key auth failures.
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_file_transfer.shBASH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
# ─────────────────────────────────────────────────────────────
# SCPSYNTAXPATTERN:
# 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/
# ── PRESERVEPERMISSIONSANDTIMESTAMPS ──────────────────────
# -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 CUSTOMSSHKEY ──────────────────────────────────
# 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-STANDARDPORT ─────────────────────────────────────────
# NOTE: SCP uses capital -P forport (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/
# ── COPYBETWEENTWOREMOTESERVERS (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/
# ── SHOWPROGRESSFORLARGEFILES ────────────────────────────
# -v (verbose) shows progress detail
# For a cleaner progress bar, use: rsync --progress (see ProTip below)
scp -v ./large-video-export.mp4 deploy@203.0.113.42:/media/uploads/
Output
# After running the upload command:
myapp-v2.1.0.tar.gz 100% 4823KB 3.2MB/s 00:01
# After running the download command:
app-2024-01-15.log 100% 1247KB 2.1MB/s 00:00
# After running the recursive directory copy:
nginx-default.conf 100% 2KB 1.8MB/s 00:00
nginx-ssl.conf 100% 4KB 2.0MB/s 00:00
nginx-proxy.conf 100% 1KB 1.5MB/s 00:00
# After running the non-standard port command:
deploy.sh 100% 512 0.5MB/s 00:00
# Typical error if you forget the capital -P with SCP:
ssh: connect to host 203.0.113.42 port 22: Connection refused
lost connection
Interview Gold: Why Does SCP Use -P (Capital) and SSH Use -p (Lowercase)?
This is a historical inconsistency that's tripped up every developer at least once. SSH uses lowercase -p for port, while SCP uses uppercase -P. The reason is that SCP already uses lowercase -p for 'preserve file attributes' (timestamps and permissions). Since both flags were needed and the tools were designed separately, the port flag ended up capitalised in SCP. Knowing this and explaining it clearly in an interview signals real hands-on experience.
Production Insight
SCP uses capital -P for port. Using lowercase -p on SCP will try port 22 and fail silently if the server uses a non-standard port — you'll get no error when copying to a wrong directory.
Also, SCP doesn't show progress by default; use -v or switch to rsync with --progress for large transfers.
Rule: Double-check the port flag (capital P) and test with a dummy file first.
Key Takeaway
SCP copies files over SSH: scp [source] [destination] with user@host: prefix.
Use -r for directories, -p to preserve attributes, -P (capital) for custom port.
For large transfers, prefer rsync over SCP for resume and progress.
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.
ssh_config_exampleBASH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
# ─────────────────────────────────────────────────────────────
# EXAMPLE ~/.ssh/config FILE
# Each section starts with 'Host', followed by the alias you type.
# ─────────────────────────────────────────────────────────────
Host prod-web
HostName203.0.113.42User deploy
Port2222IdentityFile ~/.ssh/id_ed25519_prod
Host staging-*
HostName staging.example.com
User admin
IdentityFile ~/.ssh/id_ed25519_staging
# Defaultfor all hosts (applied if no specific match)
Host *
ServerAliveInterval60TCPKeepAlive yes
StrictHostKeyChecking ask
# After saving, you can run:
# ssh prod-web
# scp prod-web:/var/log/app.log ./
# ssh staging-web1 (matches staging-* pattern)
Production Insight
A misconfigured config file with a missing Host line or wrong IdentityFile can cause SSH to use the wrong key (or none). Run ssh -G hostname to see the effective configuration before connecting.
Also, SSH config is read in order; first matching Host is used — order matters. If you have overlapping patterns, the first match wins.
Config file must have 600 permissions; SSH ignores world-readable configs.
Key Takeaway
~/.ssh/config saves typing: define Host aliases with User, Port, IdentityFile.
Use ssh -G hostname to debug resolved options.
Config file must have 600 permissions; order of host blocks matters.
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:
Disable root login: Prevent attackers from directly SSHing as root. Edit /etc/ssh/sshd_config: PermitRootLogin no. Use a regular user with sudo instead.
Disable password authentication: Rely only on key-based auth. Set PasswordAuthentication no in sshd_config.
Change the default SSH port (optional): Moving from port 22 to something like 2222 reduces automated attack traffic dramatically.
Use ED25519 keys: They are faster and more secure than RSA. Replace old RSA keys.
Disabling password authentication and root login are the first two steps in any server hardening checklist. If you lock yourself out, ensure you have a console or management network access.
Changing the SSH port reduces automated attack noise by ~99% from my production logs, but it's not a security measure in itself — combine with key-only and fail2ban.
Rule: Hardening SSH is the cheapest and most effective server security investment.
Key Takeaway
Hardening: disable root login, disable password auth, use ed25519 keys, change default port, and implement fail2ban.
Always maintain a backup access method (console or management network).
SSH hardening is the first line of defense against server compromise.
● Production incidentPOST-MORTEMseverity: high
Deploy Team Locked Out After Server Patching
Symptom
All SSH key-based connections failed with 'Permission denied (publickey)'. Password auth was also disabled for security policy.
Assumption
The patching script preserved existing file permissions.
Root cause
The security baseline script ran chmod -R 777 ~/.ssh as a temporary debugging step that was accidentally left in the production playbook.
Fix
Boot server into rescue mode via cloud console, mount the root volume, correct permissions with chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys, and reboot. Add Puppet guard to prevent permission changes on ~/.ssh.
Key lesson
Treat ~/.ssh as immutable infrastructure — never allow automated permission changes without explicit review.
Always maintain a console or management network access to handle permission lockouts.
Use configuration management testing to catch destructive operations before they hit production.
Production debug guideWhat to check when 'ssh' won't connect4 entries
Symptom · 01
Permission denied (publickey)
→
Fix
Check server-side ~/.ssh/authorized_keys permissions (must be 600) and ~/.ssh/ directory (must be 700). Verify the correct key is offered: ssh -v lists offered keys.
Symptom · 02
Connection timeout
→
Fix
Verify SSH port (default 22) is open in security group/firewall. Test with nc -zv <host> 22.
Symptom · 03
Host key verification failed
→
Fix
Remove old host key with ssh-keygen -R <host>, then reconnect after verifying server identity.
Symptom · 04
Permission denied (password)
→
Fix
Ensure password authentication is enabled in /etc/ssh/sshd_config (PasswordAuthentication yes). Check if you have the correct username.
★ SSH Quick Debug Cheat SheetCommands to diagnose and fix the most common SSH issues in under 60 seconds.
SSH asks for password even after key setup−
Immediate action
Run ssh -v to see which keys are being offered and why they're rejected.
Run permissions fix on the server side (remotely with a separate admin key or VM console).
Connection refused+
Immediate action
Check if SSH service is running and accessible.
Commands
nc -zv host 22
systemctl status sshd
Fix now
If not running: sudo systemctl start sshd; if port filtered: adjust security group/firewall.
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED+
Immediate action
Verify server identity, then remove old key.
Commands
ssh-keygen -R hostname_or_ip
ssh user@host (to accept new key)
Fix now
After verification, accept new key. If still issues, check for MITM attack.
SSH vs SCP Comparison
Feature / Aspect
SSH (Secure Shell)
SCP (Secure Copy Protocol)
Primary purpose
Interactive remote terminal access
Non-interactive file transfer between machines
Protocol layer
Encrypted tunnel (SSH protocol)
Runs on top of the SSH protocol
Authentication method
Password or SSH key pair
Same as SSH — shares its auth mechanism
Port used
22 (default)
22 (default — same as SSH)
Transfers files?
No — use SCP or rsync for files
Yes — that is its entire purpose
Runs remote commands?
Yes — interactive shell or single commands
No — file transfer only
Recursive directory copy
N/A (not its job)
Yes — use the -r flag
Resume interrupted transfer
N/A
No — use rsync for resumable transfers
Port flag
Lowercase -p (e.g. -p 2222)
Uppercase -P (e.g. -P 2222)
Best used when
You need a shell session on a remote server
You need to quickly copy a file to/from a server
Modern alternative
Still the gold standard
rsync or sftp for large/resumable transfers
Key takeaways
1
SSH encrypts your entire connection using public-key cryptography
your password or private key is never transmitted across the network in readable form.
2
SSH key pairs work like a padlock you give out freely (public key on the server) and a unique key only you hold (private key on your machine)
the math proves you own the key without revealing it.
3
SCP uses capital -P for port and lowercase -p for preserving file attributes
the exact opposite of SSH, which uses lowercase -p for port. This trips up everyone the first time.
4
Incorrect file permissions on ~/.ssh/ (should be 700) or ~/.ssh/authorized_keys (should be 600) silently break key-based auth
SSH ignores key files that are too permissive as a security measure.
5
Use ~/.ssh/config for host shortcuts and always verify SSH fingerprints on first connection.
Common mistakes to avoid
3 patterns
×
Wrong file permissions on ~/.ssh or authorized_keys
Symptom
SSH falls back to asking for a password even after key setup, or gives 'Permission denied (publickey)'.
Fix
Run chmod 700 ~/.ssh and chmod 600 ~/.ssh/authorized_keys on the server. Also on your local machine: chmod 600 ~/.ssh/id_ed25519. SSH silently ignores key files with overly permissive permissions.
×
Using lowercase -p instead of uppercase -P with SCP
Symptom
SCP ignores the port number and tries port 22, giving 'Connection refused' on servers using a custom SSH port.
Fix
Always use capital -P for port in SCP commands (e.g., scp -P 2222 ...). Remember: SCP uses lowercase -p for 'preserve', so Port had to become uppercase.
×
Forgetting the colon (:) in SCP remote paths
Symptom
Instead of copying from a remote server, SCP creates a local file or directory named literally 'user@host/path/to/file' in your current directory.
Fix
Always include the colon immediately after the hostname: scp deploy@server:/path/file ./. Without colon, SCP treats it as a local path.
INTERVIEW PREP · PRACTICE MODE
Interview Questions on This Topic
Q01SENIOR
What is the difference between SSH password authentication and SSH key-b...
Q02SENIOR
If you run `ssh-copy-id` to set up key authentication but SSH still asks...
Q03SENIOR
A junior developer accidentally runs `chmod 777 ~/.ssh` on their server ...
Q01 of 03SENIOR
What is the difference between SSH password authentication and SSH key-based authentication, and why would you prefer one over the other in a production environment?
ANSWER
Password authentication transmits a hashed password over the encrypted tunnel but is vulnerable to brute-force attacks if weak passwords are used. Key-based authentication uses a cryptographic pair; the private key never leaves the client, eliminating password transmission and brute-force risk. In production, key-only authentication is preferred because it is stronger and can be automated without storing passwords. Additionally, SSH keys can be revoked by removing the public key from authorized_keys.
Q02 of 03SENIOR
If you run `ssh-copy-id` to set up key authentication but SSH still asks for a password, what would you check first and why?
ANSWER
First check file permissions on the server's ~/.ssh directory and authorized_keys file. SSH silently ignores keys if ~/.ssh is not 700 or authorized_keys is not 600 (or if the directory is group-writable). Also check that the correct public key was appended, and that the key algorithm is supported (e.g., ED25519 requires OpenSSH ≥ 6.5). Use ssh -v to see the authentication log.
Q03 of 03SENIOR
A junior developer accidentally runs `chmod 777 ~/.ssh` on their server and now their SSH keys don't work. Can you explain why that broke things, and what they should do to fix it?
ANSWER
SSH daemon rejects keys when ~/.ssh is world-writable because it assumes the keys could have been tampered with. The fix is to set ~/.ssh back to 700 (chmod 700 ~/.ssh) and authorized_keys to 600. If they already lost access, they must use a console breakout (e.g., cloud provider's serial console) to fix permissions.
01
What is the difference between SSH password authentication and SSH key-based authentication, and why would you prefer one over the other in a production environment?
SENIOR
02
If you run `ssh-copy-id` to set up key authentication but SSH still asks for a password, what would you check first and why?
SENIOR
03
A junior developer accidentally runs `chmod 777 ~/.ssh` on their server and now their SSH keys don't work. Can you explain why that broke things, and what they should do to fix it?
SENIOR
FAQ · 4 QUESTIONS
Frequently Asked Questions
01
What is the difference between SSH and SCP?
SSH (Secure Shell) gives you an interactive terminal session on a remote machine — you log in and run commands as if you were sitting at that server. SCP (Secure Copy Protocol) uses the SSH connection purely to transfer files between machines. You'd use SSH to manage a server and SCP to copy a config file or log from it.
Was this helpful?
02
Is it safe to share my SSH public key?
Yes, completely. Your public key (the .pub file) is designed to be shared. It's the 'padlock' — anyone can have a copy. What you must never share is your private key (the file without .pub extension). If your private key is compromised, an attacker can impersonate you on every server that has your public key in its authorized_keys file. Treat the private key exactly like a password.
Was this helpful?
03
What is the ~/.ssh/known_hosts file for?
It's SSH's memory of servers you've connected to before. The first time you connect to a server, SSH saves a fingerprint of that server's identity. Every subsequent connection, SSH checks the fingerprint still matches. If it doesn't match (which could mean the server was rebuilt, or someone is intercepting your connection), SSH refuses to connect and warns you loudly. This protects you from man-in-the-middle attacks.
Was this helpful?
04
Should I use SCP or rsync for file transfers?
For one-off small transfers, SCP is fine. For large files or repeated transfers, rsync offers resume capability, progress reporting, and delta transfers. Many modern systems deprecate SCP in favor of rsync over SSH. But SCP remains simpler for quick tasks and is still widely used.