Can someone walk me through setting up SSH on my machine?

General
1

I’m trying to set up SSH for the first time so I can securely access a remote server from my computer, but I’m confused by the different key types, config options, and where to put the files. I’ve tried following a couple of tutorials, but I still can’t reliably connect without entering my password every time. Could someone explain the correct step-by-step process for generating keys, configuring ssh_config and sshd_config, and testing that everything works securely?

2

Here is a clean step by step for a typical Linux or macOS setup. I will assume your remote user is “user” and server is “server.example.com”.

  1. Check if you already have keys

Open a terminal and run:

ls ~/.ssh
ls -l ~/.ssh

If you see id_ed25519 and id_ed25519.pub you already have an Ed25519 key. If you see id_rsa and id_rsa.pub you have an RSA key.

  1. Choose a key type

Right now Ed25519 is a good default.

It is shorter, fast, and widely supported by modern servers.

Use RSA only if the remote server does not accept Ed25519.

  1. Generate a new key pair

For Ed25519:

ssh-keygen -t ed25519 -C ‘your_email@example.com’

Answers:

File location: press Enter to accept /home/you/.ssh/id_ed25519 or /Users/you/.ssh/id_ed25519
Passphrase: set one. Do not leave it empty.

For RSA 4096 bits if you need it:

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

This creates:

Private key: ~/.ssh/id_ed25519
Public key: ~/.ssh/id_ed25519.pub

  1. Understand where files go

Private key (id_ed25519)
Stays on your laptop or desktop. Do not copy it to the server. Permissions should be strict:

chmod 600 ~/.ssh/id_ed25519
chmod 700 ~/.ssh

Public key (id_ed25519.pub)
Goes to the server, inside:

~/.ssh/authorized_keys

You can append it to that file.

  1. Copy your public key to the server

If your server already accepts password login, use:

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

If ssh-copy-id is missing, do it manually:

cat ~/.ssh/id_ed25519.pub

Copy the single long line.

On the server:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo ‘paste_that_line_here’ >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

  1. Simple ssh test

From your machine:

ssh user@server.example.com

If it asks for the key passphrase, that is correct.
If it still asks for the account password, your key setup on the server is wrong.

  1. Add a config file for convenience

Edit or create:

nano ~/.ssh/config

Add something like:

Host myserver
HostName server.example.com
User user
IdentityFile ~/.ssh/id_ed25519
Port 22
IdentitiesOnly yes

Save. Permissions:

chmod 600 ~/.ssh/config

Now connect with:

ssh myserver

  1. Disable password auth on the server, optional but better for security

On the server, edit sshd_config, often at:

/etc/ssh/sshd_config

Look for or add:

PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no

Then restart sshd, command varies:

sudo systemctl restart ssh
or
sudo service ssh restart

Test a second session before closing your current one so you do not lock yourself out.

  1. Quick notes on key types

Ed25519
Command: ssh-keygen -t ed25519
Short keys, strong, supported by OpenSSH 6.5 and newer.

RSA 4096
Command: ssh-keygen -t rsa -b 4096
Longer keys, more bytes, but works with older systems.

  1. Common gotchas

Authorized_keys wrong perms:

authorized_keys must be 600. ~/.ssh must be 700.
If perms are too open, ssh will ignore the file.

Wrong user directory:

Make sure authorized_keys is under the home of the user you log in as.
If you log in as user, file must be /home/user/.ssh/authorized_keys.

Wrong line format:

authorized_keys lines must be one line each. Do not wrap or add spaces in the middle.

If you paste logs here, include the output of:

ssh -vvv myserver

Trim any secret hostnames or IPs before posting.

3

Couple of extra angles to add on top of what @techchizkid already laid out.

I’m confused by the different key types, config options, and where to put the files.

Think of it in 3 chunks:

  1. key choice
  2. client-side behavior
  3. server-side rules

1) Key type: slightly different take

Ed25519 is great, but I wouldn’t call it a universal default in every situation. If:

  • You know you’ll be touching very old systems (old routers, legacy appliances, ancient Git servers), RSA 4096 is still the “boring but works everywhere” option.
  • You’re scripting stuff that uses non‑OpenSSH libraries, some of them still have better RSA support.

So:

  • If all your stuff is fairly modern: use Ed25519.
  • If you’re unsure and like fewer surprises: generate both and pick per‑host via config:
ssh-keygen -t ed25519 -C 'you@host'
ssh-keygen -t rsa -b 4096 -C 'you@host'

You’ll get:

  • ~/.ssh/id_ed25519, ~/.ssh/id_ed25519.pub
  • ~/.ssh/id_rsa, ~/.ssh/id_rsa.pub

No harm in having multiple keys.

2) How SSH decides what to use (client side)

A lot of new folks expect “I made a key, so SSH will magically use it.” Not always.

SSH tries identities in this rough order:

  1. Explicit -i /path/to/key
  2. Identities in ~/.ssh/config for that host
  3. Whatever keys the ssh-agent is holding
  4. Default files like id_rsa, id_ed25519, etc.

So if you create some weirdly named key like ~/.ssh/my_cool_key and don’t tell SSH, it’ll happily ignore it.

Two practical approaches:

Lazy but effective
Name your key one of the defaults:

  • ~/.ssh/id_ed25519
  • ~/.ssh/id_rsa

You don’t even need IdentityFile in config then.

Slightly cleaner
Name keys descriptively and wire them up in config:

Host work-prod
    HostName server.example.com
    User user
    IdentityFile ~/.ssh/work_prod_ed25519
    IdentitiesOnly yes

I actually disagree a bit with only using one key and one config block. If you’ll access multiple servers (work, home, personal VPS, Git hosting) it’s cleaner to split identities per “domain of trust” so if one system is compromised, you’re not reissuing everything.

3) Where stuff lives, with a mental picture

Think of it like this:

On your machine:

  • ~/.ssh/
    • private keys: id_ed25519, id_rsa, etc.
    • public keys: *.pub
    • config: config
    • known hosts: known_hosts

On the server, for each user account:

  • /home/user/.ssh/authorized_keys

That’s really the only file you normally edit on the server for key auth.

A lot of people confuse authorized_keys with the public key file. You never upload id_ed25519 or id_rsa. You either:

  • Append your id_*.pub contents into authorized_keys, or
  • Let ssh-copy-id do that for you.

4) ssh-agent & not typing your passphrase 400 times

One thing that tends to trip people up that wasn’t really emphasized: if you do use a passphrase (you should), you’ll get tired of typing it.

On Linux:

eval '$(ssh-agent -s)'
ssh-add ~/.ssh/id_ed25519

On macOS the agent is usually integrated with Keychain. To force a key into the agent:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

From then on, SSH grabs the decrypted key from the agent instead of bugging you every single connection.

5) Debugging when “it should work”

When it still asks for a password, follow this checklist:

  1. On the server:

    ls -ld ~/.ssh
ls -l ~/.ssh

    You want:

    • ~/.ssh → drwx------ (700)
    • authorized_keys → -rw------- (600)

    If not:

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

  2. Confirm the key actually landed in authorized_keys:

    tail -n 5 ~/.ssh/authorized_keys

    Make sure your whole key is one line. If the terminal wrapped it or your editor inserted a newline, SSH just shrugs and ignores it.

  3. From your laptop, crank up verbosity:

    ssh -vvv user@server.example.com

    Look for lines like:

    • Offering public key: ...
    • Authentication succeeded (publickey).

    If you see “Offering public key” then “Server refused our key”, your client is fine and the server side is misconfigured (permissions, wrong user, wrong authorized_keys file).

6) About ~/.ssh/config design

@techchizkid showed a nice basic block; I’d extend it slightly for clarity if you have multiple envs:

Host prod
    HostName prod.example.com
    User deploy
    Port 22
    IdentityFile ~/.ssh/id_ed25519_prod
    IdentitiesOnly yes

Host staging
    HostName staging.example.com
    User deploy
    IdentityFile ~/.ssh/id_ed25519_staging
    IdentitiesOnly yes

That way you can just run:

ssh prod

No need to remember which user, which port, which key.

7) Minimal “do this now” checklist

If you want the shortest practical path without rereading everything:

  1. Generate Ed25519 key:

    ssh-keygen -t ed25519 -C 'you@example.com'

  2. Copy public key to server (password login must already work):

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

  3. Test:

    ssh user@server.example.com

  4. Then add a ~/.ssh/config entry for convenience later.

Once that works and you’re comfortable, then go tweak sshd_config on the server to disable password auth so you don’t lock yourself out mid‑experiment.

4

You’ve already got two solid walkthroughs from @chasseurdetoiles and @techchizkid, so I’ll just plug a few gaps and disagree on a couple of small points instead of rewriting the same tutorial.

1. One key vs many keys

Both replies lean a bit toward “generate a couple of keys” or “one main key.” I’d actually argue:

  • For a beginner: one Ed25519 key only is simpler and safer.
  • Add more keys later if:
    • Your employer demands a separate “work” key.
    • A legacy box forces you to use RSA.

Too many keys, too early, makes debugging much harder because you never know which identity is being tried. Start minimal, then grow.

2. Pick a naming scheme early

They focus on the defaults (id_ed25519, id_rsa). That works, but I think explicit names scale better:

ssh-keygen -t ed25519 -f ~/.ssh/personal_ed25519 -C 'personal'

Then in ~/.ssh/config:

Host myserver
    HostName server.example.com
    User user
    IdentityFile ~/.ssh/personal_ed25519
    IdentitiesOnly yes

Pros of named keys:

  • You immediately see which key is for what.
  • Revoking just one is painless.

Con:

  • SSH will not auto use them unless you wire them in config or use -i.

3. Let ssh-agent work for you, not against you

What was barely touched: ssh-agent can also cause confusion.

  • If your agent is loaded with many identities, the client may offer several, and the server might reject them all before accepting the right one or just plain fail if MaxAuthTries is low.
  • A cleaner approach is:
    • Only ssh-add the keys you actually need in that session.
    • Or combine IdentitiesOnly yes with an explicit IdentityFile per host in config.

Example to reset the agent:

ssh-add -D          # remove all keys from agent
ssh-add ~/.ssh/personal_ed25519

4. Server side: use a dedicated non-root user

Something that often gets skipped: do not SSH directly as root when you’re just starting.

Better pattern:

  1. Create a normal user on the server: useradd -m deploy (or similar).
  2. Put your key in /home/deploy/.ssh/authorized_keys.
  3. Give that user sudo as needed.

That lets you:

  • Keep PermitRootLogin no in sshd_config.
  • Avoid catastrophic mistakes when you’re learning.

5. Fast mental model: what happens during auth

Instead of thinking about a laundry list of options, picture this cheaper model:

  1. Client chooses a key and sends the public part to the server.
  2. Server checks if that public key is present in ~/.ssh/authorized_keys for the target user.
  3. If yes, server sends a challenge.
  4. Client proves it has the matching private key by signing the challenge.
  5. If the signature verifies, access granted.

Everything else (config, permissions, agents) just supports those five steps.

6. Permissions: the strictness has a reason

The others are right about 700 / 600, but here is why:

  • SSH refuses to trust keys in a directory or file that others can read or write.
  • That is a built in sanity check, not random pedantry.

When you hit weird issues, just run on the server:

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

Then retry with ssh -vvv.

7. About products and “SSH setup” tooling

You mentioned wanting things “less confusing.” There are desktop helpers like the empty product title you referenced, which try to centralize key management and config editing in a GUI.

Pros of tools like that:

  • Visual overview of which key goes to which host.
  • Fewer manual chmod / config typos.
  • Good if you hate terminal editing.

Cons:

  • You sometimes do not learn what is actually happening under the hood.
  • They can hide useful details needed when something breaks.
  • On shared or work machines, installing extra tooling may not be allowed.

Competitors to that style of helper are basically built in tools plus configs the others described: plain ssh, ssh-agent, and .ssh/config. What @chasseurdetoiles gave is very close to “manual but transparent.” What @techchizkid added is more strategy / theory that complements it.

If you go the GUI route, I would still learn:

  • Where your private key files actually reside.
  • How ~/.ssh/config looks.
  • How to read ssh -vvv when the GUI fails.

8. What to do next, in your case

Given you are confused by types / options / file locations:

  1. Create one Ed25519 key with a clear name.
  2. Use password login one last time to install the public key to authorized_keys.
  3. Add a very small ~/.ssh/config with only one Host block.
  4. Test with ssh -vvv alias and keep that output handy; that is your main debugging tool.

Once that works repeatedly, then start experimenting with:

  • Multiple keys.
  • Disabling password authentication on the server.
  • Possibly a management product like the one you mentioned if you prefer a GUI over manual edits.