The scenario
You just provisioned a new Fedora Server instance in the cloud or set up a Raspberry Pi in the corner. You need to get a terminal session running without sitting in front of the machine. You open your local Fedora Workstation terminal and type ssh. The prompt asks for a password. You type it. The connection drops. Or maybe you get a warning about a host key mismatch. You need a reliable way to connect, manage multiple servers, and stop typing passwords every time you switch contexts.
What SSH actually does under the hood
SSH stands for Secure Shell. It wraps your terminal session in an encrypted tunnel so nothing travels across the network in plain text. Think of it like a sealed diplomatic pouch. The sender locks it, the receiver unlocks it, and anyone who intercepts it just sees a locked box. The protocol handles three things automatically. It encrypts the data stream. It authenticates the remote host. It authenticates your user account.
The first time you connect to any machine, your local SSH client has no record of that server. It downloads the server's public host key and stores it in ~/.ssh/known_hosts. On every subsequent connection, SSH compares the stored key with the one the server presents. If they match, the tunnel opens. If they differ, SSH assumes someone is trying to impersonate the server and blocks the connection. This is a security feature, not a bug.
Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/. The same principle applies to SSH. The system-wide defaults live in /etc/ssh/ssh_config. Your personal overrides live in ~/.ssh/config. The client reads the system file first, then applies your personal file on top. This layering lets you keep global security policies while maintaining personal shortcuts.
Basic connection and host key verification
Start with the simplest possible connection. Open your terminal and run the base command with your remote username and the target address.
ssh user@192.168.1.50 # Connects to the remote host on the default port 22
The first time you run this, the client will print a warning about the host key. It will ask you to type yes to accept and store the key. Type yes and press Enter. The client writes the key to ~/.ssh/known_hosts and prompts for your password. Enter the password. The remote shell appears.
If your server runs SSH on a non-standard port, you must tell the client explicitly. The default port is 22. Many administrators change it to reduce automated scanning noise. Use the -p flag to specify the alternative port.
ssh -p 2222 user@192.168.1.50 # Overrides the default port 22 with 2222
Reboot before you debug. Half the time the symptom is gone.
Managing SSH keys and configuration
Typing passwords works for quick tests. It breaks down when you manage five servers or need to run automated scripts. SSH keys solve this by replacing password authentication with cryptographic proof. You generate a key pair locally. The private key stays on your machine. The public key goes to the remote server. When you connect, the server sends a challenge. Your client signs it with the private key. The server verifies the signature and logs you in.
Generate an Ed25519 key pair. This algorithm is faster and more secure than the older RSA default.
ssh-keygen -t ed25519 -C "fedora-laptop" # Creates a modern key pair with a descriptive comment
The command asks for a file path. Press Enter to accept the default ~/.ssh/id_ed25519. It then asks for a passphrase. Set one. The passphrase encrypts the private key on disk so a stolen laptop cannot be used to impersonate you.
Copy the public key to your remote server. The ssh-copy-id utility handles the directory permissions and appends the key to the correct file automatically.
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@192.168.1.50 # Pushes the public key to the remote authorized_keys file
You will be asked for the remote password one last time. After it succeeds, connect again. The client will use the key automatically and skip the password prompt.
Managing multiple servers with different ports, usernames, and keys gets messy quickly. Stop typing long command lines. Use the ~/.ssh/config file to define shortcuts. This file lives in your home directory and is read automatically by the SSH client.
nano ~/.ssh/config # Opens the client configuration file for editing
Add a block for each server. The indentation is optional but keeps the file readable.
Host web-prod
HostName 192.168.1.50
User deploy
Port 2222
IdentityFile ~/.ssh/id_ed25519
Save the file and restrict its permissions. SSH refuses to read config files that are world-readable.
chmod 600 ~/.ssh/config # Restricts access to the owner only so SSH accepts the file
Now you can connect with a single word.
ssh web-prod # Resolves the alias and applies all settings from the config block
Run journalctl -xe first. Read the actual error before guessing.
Advanced configuration patterns
The ~/.ssh/config file supports features that save hours of manual work. Connection multiplexing lets you reuse a single TCP connection for multiple terminal sessions. This speeds up authentication and reduces latency when you open several tabs to the same server.
Add a control master block to your config file. Place it at the top so it applies to all hosts unless overridden.
Host *
ControlMaster auto
ControlPath ~/.ssh/sockets/%r@%h-%p
ControlPersist 600
The client will create a socket file in ~/.ssh/sockets/ the first time you connect. Subsequent connections to the same host will attach to that socket instead of negotiating a new TLS handshake. Create the directory before you test it.
mkdir -p ~/.ssh/sockets # Creates the directory for multiplexing socket files
chmod 700 ~/.ssh/sockets # Locks down the directory so SSH accepts it
Agent forwarding lets you use your local SSH keys on remote machines without copying the private key over the network. This is useful when you need to pull from a Git repository on a jump host. Add ForwardAgent yes to the specific host block. Never enable it globally. A compromised remote server could use the forwarded agent to authenticate to other systems on your behalf.
firewall-cmd --reload after every rule change. Otherwise the runtime config and the persistent config diverge.
Verify the connection
Confirm the tunnel is using the correct authentication method and cipher. Run the verbose flag to see the negotiation process without changing behavior.
ssh -v user@192.168.1.50 # Prints detailed debugging output to stderr while connecting
Look for the line that says Authentication succeeded. Check the cipher and MAC algorithms listed near the top. If you see password authentication succeeding when you expect keys, your ~/.ssh/config or the remote authorized_keys file has a permission issue. Verify the remote file permissions with ls -la ~/.ssh/ on the target machine. The directory must be 700 and the authorized_keys file must be 600.
Trust the package manager. Manual file edits drift, snapshots stay.
Common pitfalls and error messages
SSH errors usually fall into three categories. Host key mismatches, permission denials, and connection timeouts.
The host key mismatch error appears when the remote server was reinstalled or the IP address was reassigned to a different machine. Your local known_hosts file still holds the old key. The client refuses to connect to prevent a man-in-the-middle attack.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Remove the stale entry. You can delete the whole file if you only manage a few servers, or use the -R flag to target a specific host.
ssh-keygen -R 192.168.1.50 # Removes the old host key from known_hosts so you can re-verify
Permission denied errors usually mean the private key is not being offered or the remote server rejects it. Check the verbose output for Offering public key. If the key is offered but rejected, the remote ~/.ssh directory is too open. SSH requires strict permissions. Run chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys on the remote machine.
Connection timed out errors indicate a firewall or routing issue. Verify the remote port is open. Fedora uses firewalld by default. If you are connecting to a Fedora server, ensure the SSH service is allowed in the runtime and permanent zones.
firewall-cmd --add-service=ssh --permanent # Adds SSH to the persistent firewall rules
firewall-cmd --reload # Applies the change immediately without dropping active connections
SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux.
When to use SSH vs alternatives
Use SSH when you need a secure, encrypted terminal session with full TTY support. Use scp when you only need to transfer a single file or directory tree without opening an interactive shell. Use sftp when you need an interactive file transfer session with directory navigation and resume capabilities. Use mosh when you are on an unstable cellular connection that drops packets and changes IP addresses frequently. Use tmux or screen when you need to detach from a long-running process and reattach later without SSH staying connected.