SSH and Remote Access

Reviewed & published by Brayan K

By the end of this lesson you'll be able to open an encrypted shell on a remote server, set up passwordless key-based login, recognise host-key prompts, and move files back and forth with scp and sftp — the everyday toolkit for working on machines you can't physically touch.

Part of the free Command Line course at LearnCodingFast — hands-on lessons with worked examples and the output they print, plus practice exercises and a quick quiz.

What You'll Learn

• Open a remote shell with ssh user@host (and -p for a non-default port; 22 is the default)
• Generate an ed25519 key pair and understand public vs private keys
• Install your public key with ssh-copy-id into the server's authorized_keys
• Save per-host shortcuts in ~/.ssh/config so you can just type ssh myserver
• Understand host keys, fingerprints, and ~/.ssh/known_hosts
• Transfer files with scp and sftp, and use ssh-agent for passwordless keys

1. Opening a Remote Shell

SSH (Secure Shell) gives you an encrypted command line on another machine. The basic form is ssh user@host — your username on the server, then the address. SSH uses port 22 by default; if a server listens elsewhere, add -p, as in ssh -p 2222 user@host. You can also tack a command on the end to run it remotely and return immediately.

# SSH (Secure Shell) opens an ENCRYPTED shell on another machine.
# The basic shape is:  ssh USER@HOST
ssh ada@server.example.com

# If the server listens on a non-default port, pass it with -p.
# (The default SSH port is 22, so you usually omit -p.)
ssh -p 2222 ada@server.example.com

# Run a single command remotely and come straight back:
ssh ada@server.example.com "uptime"

2. Host Keys & known_hosts

The first time you connect to a server, SSH has no record of it, so it prints the server's fingerprint and asks you to confirm. Say yes only if it matches what you expect. SSH then stores that host key in ~/.ssh/known_hosts. On every later connection it compares the server's key against this file — and warns you loudly if it changed, which is how SSH catches impersonation or a man-in-the-middle attack.

# THE FIRST TIME you connect to a server, SSH does not yet know it.
# It shows the server's fingerprint and asks you to confirm:
ssh ada@server.example.com

# You will see something like:
#   The authenticity of host 'server.example.com' can't be established.
#   ED25519 key fingerprint is SHA256:K9o...3Qm.
#   Are you sure you want to continue connecting (yes/no)?
#
# Type 'yes' only if the fingerprint matches what you expect.
# SSH then SAVES that host key in ~/.ssh/known_hosts.
#
# On every later connection SSH compares the server's key against
# known_hosts. If it changed, SSH warns you loudly — this is how it
# detects impersonation / a man-in-the-middle attack.

3. Generating a Key Pair

Key-based auth starts with ssh-keygen -t ed25519 -C "you@example.com", which creates a key pair: a private key (~/.ssh/id_ed25519) you keep secret, and a public key (~/.ssh/id_ed25519.pub) that's safe to share. You put the public key on servers; the private key never leaves your machine — don't email it, commit it, or paste it anywhere.

# Generate a modern key PAIR. -t picks the key type (ed25519 is the
# recommended default); -C just adds a label/comment.
ssh-keygen -t ed25519 -C "you@example.com"

# When asked for a file, the defaults create TWO files:
#   ~/.ssh/id_ed25519       <- the PRIVATE key  (keep secret, never share)
#   ~/.ssh/id_ed25519.pub   <- the PUBLIC key   (safe to share)
#
# You may also set a passphrase that encrypts the private key on disk.
#
# Golden rule:
#   - The PUBLIC key (.pub) goes onto servers.
#   - The PRIVATE key NEVER leaves your machine. Do not email it,
#     do not commit it to git, do not paste it anywhere.

4. Installing Your Public Key

To enable passwordless login, your public key needs to live on the server. ssh-copy-id user@host does this for you: it appends your .pub key to the server's ~/.ssh/authorized_keys — the file listing every public key allowed to log in as you. It asks for your password just once to do the install; after that, ssh user@host logs you in automatically with your key.

# ssh-copy-id installs your PUBLIC key onto the server so you can log
# in WITHOUT a password from then on. (It asks for your password ONCE
# to do the install.)
ssh-copy-id ada@server.example.com

# Under the hood it appends your ~/.ssh/id_ed25519.pub to the server's
#   ~/.ssh/authorized_keys
# That file is simply the list of public keys allowed to log in as you.
#
# After this, logging in uses your key automatically:
ssh ada@server.example.com

5. Host Shortcuts with ~/.ssh/config

Typing ssh -p 2222 -i ~/.ssh/id_ed25519 ada@server.example.com every time is tedious. The ~/.ssh/config file lets you save those settings under a short nickname using a Host block with HostName, User, Port, and IdentityFile. Then you just run ssh myserver. Bonus: scp and sftp read this file too.

# ~/.ssh/config lets you save per-host settings so you can type a short
# nickname instead of the full user@host -p ... every time.
#
# Put this in the file  ~/.ssh/config :

Host myserver
    HostName server.example.com
    User ada
    Port 2222
    IdentityFile ~/.ssh/id_ed25519

# Now both of these are equivalent:
#   ssh -p 2222 -i ~/.ssh/id_ed25519 ada@server.example.com
#   ssh myserver
#
# scp and sftp read this file too, so 'scp file.txt myserver:/tmp/' works.

6. Transferring Files: scp & sftp

SSH also moves files. scp (secure copy) sends them over the same encrypted channel: scp localfile user@host:/path/ copies to the remote host, scp user@host:/path/file . copies one back, and -r copies a whole directory. For an interactive session where you browse and grab files, use sftp user@host.

# scp = "secure copy" — copy files over the same encrypted SSH channel.

# 1) Copy a LOCAL file TO the remote host (note the colon + remote path):
scp report.pdf ada@server.example.com:/home/ada/uploads/

# 2) Copy a file FROM the remote host to your current directory (the dot):
scp ada@server.example.com:/var/log/app.log .

# 3) Copy a whole directory recursively with -r:
scp -r ./project ada@server.example.com:/home/ada/

# For an interactive transfer session (ls, cd, get, put), use sftp:
sftp ada@server.example.com

🎯 Your Turn: connect on a custom port

Fill in the blank marked ___ using the # 👉 hint, then picture the prompt you'd land on.

# 🎯 YOUR TURN — connect to a server on a non-default port.

# The server is at host  build.example.com , user  deploy , port  2222 .

# 1) Choose the flag that sets the port.
ssh ___ 2222 deploy@build.example.com   # 👉 replace ___ with  -p

# ✅ After connecting you would see a prompt like:
#    deploy@build:~

🎯 Your Turn: set up passwordless login

Two blanks: pick the key type, and the tool that installs your public key on the server. Then check the output.

# 🎯 YOUR TURN — set up passwordless login, then verify the file.

# 1) Generate an ed25519 key pair labelled with your email.
ssh-keygen -t ___ -C "you@example.com"   # 👉 replace ___ with  ed25519

# 2) Install your PUBLIC key on the server with the right tool.
___ deploy@build.example.com             # 👉 replace ___ with  ssh-copy-id

# Reminder: the public key lands in the server's
#   ~/.ssh/authorized_keys
# and your PRIVATE key never leaves your machine.

Pro Tips

• 💡 Prefer ed25519 keys: ssh-keygen -t ed25519 gives short, fast, modern keys. They're the recommended default over older RSA keys.
• 💡 Let ssh-agent remember your passphrase: ssh-agent holds your decrypted private key in memory so you don't retype the passphrase on every connection.
• 💡 Lean on ~/.ssh/config: one Host block per server turns long commands into ssh prod. scp and sftp honour it too.
• 💡 Forward the agent only when you trust the host: ssh -A lets a remote machine use your keys — handy for hopping to a second server, but a malicious host could abuse it, so use it sparingly.

Common Errors (and the fix)

• "Permission denied (publickey)" — the server didn't accept your key. Make sure your public key is in the server's ~/.ssh/authorized_keys (run ssh-copy-id user@host), and that you're offering the matching private key.
• "Connection refused" — nothing is listening on the port you tried. The SSH service may be down, or it's on a non-default port — add -p PORT.
• "REMOTE HOST IDENTIFICATION HAS CHANGED!" — the server's host key no longer matches ~/.ssh/known_hosts. This can be a legit server rebuild — or an attack. Verify the new fingerprint out-of-band before removing the old line.
• "UNPROTECTED PRIVATE KEY FILE!" — your private key is too readable. Tighten it with chmod 600 ~/.ssh/id_ed25519 (and chmod 700 ~/.ssh).
• scp "No such file or directory" — you forgot the colon, so SSH treated host/path as a local file. Remote targets need host:/path.

📋 Quick Reference

Mini-Challenge: one-word login + deploy copy

No blanks this time — just a brief and an outline. Wire up a ~/.ssh/config shortcut, confirm your key is on the server, then push a release file using your new nickname. Check your result against the goal in the comments.

# 🎯 MINI-CHALLENGE: set up a one-word login + a deploy copy
#
# You connect to  app.example.com  as user  deploy  on port  2222 ,
# authenticating with  ~/.ssh/id_ed25519 .
#
# 1. Create a ~/.ssh/config Host block named  prod  so that typing
#    'ssh prod' connects with the right HostName, User, Port and
#    IdentityFile.
# 2. Make sure your PUBLIC key is on the server (ssh-copy-id) so the
#    login needs no password.
# 3. Copy your local file  build.tar.gz  to  /home/deploy/releases/
#    on the server — using your new 'prod' shortcut, not the full
#    user@host string.
#
# Hints:  Host prod / HostName / User / Port / IdentityFile
#         scp build.tar.gz prod:/home/deploy/releases/
#
# ✅ Goal:  'ssh prod' logs you straight in, and the scp above succeeds.

# your config + commands here

🎉 Lesson Complete!

• ✅ ssh user@host opens an encrypted shell; -p picks a non-default port (default is 22)
• ✅ ssh-keygen -t ed25519 makes a key pair: a secret private key and a shareable public key
• ✅ ssh-copy-id puts your public key in the server's ~/.ssh/authorized_keys for passwordless login
• ✅ Host keys live in ~/.ssh/known_hosts and guard against impersonation; ~/.ssh/config saves shortcuts
• ✅ scp and sftp move files; ssh-agent remembers your passphrase and ssh -A forwards it to trusted hosts

Practice quiz

Continue this course

• Previous: Package Managers
• Next: Scheduling Tasks with cron — Automate jobs on a schedule with crontab and the five-field syntax
• Quick reference: Command Line cheat sheet

Frequently asked questions

What is the difference between the public key and the private key?

ssh-keygen creates a matching pair. The PRIVATE key (for example ~/.ssh/id_ed25519) must stay secret and never leave your machine. The PUBLIC key (the .pub file) is safe to share — you put it on servers. The server can verify you hold the private key without ever seeing it.

Why use SSH keys instead of a password?

Keys are far stronger than a typed password: there is nothing to phish or guess, and you get passwordless login. The server stores only your public key, so a server breach does not leak a password. For these reasons many servers disable password authentication and require keys.

What does ssh-copy-id actually change on the server?

It appends your public key to the server's ~/.ssh/authorized_keys file. That file is simply the list of public keys allowed to log in as your user. Once your key is in it, ssh logs you in using the key automatically — no password prompt.

Why does SSH ask me to confirm a fingerprint on the first connection?

On first contact SSH has no record of the server, so it shows the server's host-key fingerprint and asks you to confirm it is the machine you expect. Your answer is saved in ~/.ssh/known_hosts. On later connections SSH compares the key against that file and warns loudly if it changed, which helps catch impersonation or a man-in-the-middle attack.

How do I copy files over SSH, and what is ssh-agent for?

Use scp for one-off copies: 'scp file user@host:/path/' sends a file, 'scp user@host:/path/file .' fetches one, and -r copies directories; sftp gives an interactive session. ssh-agent holds your decrypted private key in memory so you do not retype its passphrase, and 'ssh -A' forwards the agent to a remote host — only do that with hosts you fully trust.