# SSH Keys and Known Hosts for Makers

Learn how SSH identity, authorized keys, host keys, and file modes fit together before deleting warnings.

## Outcome
Debug SSH access without exposing private keys or blindly removing known_hosts entries.

## Safe first step
ssh -vvv user@host shows which authentication step fails.

## Ladder steps
### 1. Separate identity from host trust
Your key proves who you are; the host key proves which server answered.

Check: Identify whether the error is publickey or host key related.

### 2. Check local key files
Private keys need restrictive permissions.

Check: ls -l ~/.ssh shows file modes.

### 3. Check remote authorized_keys
The server must have the right public key for the right user.

Check: authorized_keys contains public keys, not private keys.

### 4. Verify host changes out of band
A changed host key can be normal or a security warning.

Check: Confirm fingerprint before editing known_hosts.

## Examples
### Inspect SSH auth flow
```sh
ssh -vvv user@example.com
```
Expected signal: Debug lines naming keys attempted and server response

Caution: Do not paste full debug output publicly without reviewing it.

### Find a host in known_hosts
```sh
ssh-keygen -F example.com
```
Expected signal: Known host lines for that host

### Check local SSH file modes
```sh
ls -l ~/.ssh
```
Expected signal: Private keys should not be world-readable

## Common traps
- Posting private keys.
- Deleting known_hosts blindly.
- Debugging the wrong remote user.

## Practice task
Describe how you would tell apart a publickey failure from a changed host key warning.

## Next steps
- Use LinuxOneLiners SSH publickey path.
- Learn permissions.
- Learn server log search.

## Related
- [SSH publickey repair path](https://linuxoneliners.com/problems/ssh-permission-denied-publickey/)