Below is a concise cheat sheet covering basic SSH usage across Windows, Debian, RPM-based systems, and macOS.
ssh username@hostname
ssh -p port_number username@hostname
ssh username@hostname "command_to_run"
scp local_file username@hostname:/remote/path
ssh-copy-id username@hostnamessh-copy-id is a utility that automates the process of installing your SSH public key on a remote server for passwordless login. Here’s what it does:
~/.ssh/id_rsa.pub or ~/.ssh/id_ed25519.pub).~/.ssh/authorized_keys file, creating the file and the .ssh directory if they don't already exist..ssh directory and authorized_keys file are set correctly, which is necessary for SSH to work securely.In essence, ssh-copy-id simplifies the process of configuring key-based authentication, saving you from manually copying and editing files on the remote server.
Using Built-in OpenSSH (Windows 10/11)
• Open Command Prompt or PowerShell.
• Connect using SSH:
ssh username@hostname
• Generate an SSH key pair:
ssh-keygen
• Place public key on remote server for key-based authentication.
Windows does not include a built-in equivalent to the Linux ssh-copy-id command. However, you can achieve the same result by manually appending your public key to the remote server’s ~/.ssh/authorized_keys file. One common workaround in PowerShell is:
type $env:USERPROFILE\.ssh\id_rsa.pub | ssh username@hostname "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
Explanation:
type $env:USERPROFILE\.ssh\id_rsa.pub: Outputs your public key.|) into ssh: Connects to the remote host.~/.ssh directory if it doesn’t exist and appends the public key to authorized_keys.Make sure you have OpenSSH installed and configured on Windows, and that your public key is generated (using ssh-keygen). This command mimics what ssh-copy-id does on Linux systems.
Alternative: PuTTY
• Download PuTTY from: PuTTY Download Page
• Configure sessions, save keys, and use PuTTYgen for key generation.
Because SSH is very well known and mature, managing it is very similar across unix-like systems.
We consider Unix-like systems to include basically everything that isn't Windows. Broadly could include:
We are going to include what is similar here, and the differences we will allocate their own sections below.
Here are some steps and commands to check and update common SSH key configurations on Linux:
Inspect sshd_config:
This file (typically located at /etc/ssh/sshd_config) controls how the SSH daemon handles authentication, including public key authentication.
sudo grep -E '^(PubkeyAuthentication|AuthorizedKeysFile|PasswordAuthentication)' /etc/ssh/sshd_config
PubkeyAuthentication yes (must be enabled)AuthorizedKeysFile .ssh/authorized_keys (defines the location of the public keys)PasswordAuthentication no if you want to enforce key-based login only.Update sshd_config:
Use your favorite text editor (e.g., vim, nano) to modify settings:
sudo nano /etc/ssh/sshd_config
After editing, restart the SSH service:
sudo systemctl restart sshd
~/.ssh/config file:cat ~/.ssh/config
nano ~/.ssh/config
Host myserver
HostName example.com
User your_username
IdentityFile ~/.ssh/id_rsa
Proper permissions are crucial for SSH to work correctly:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
authorized_keys:chmod 644 ~/.ssh/id_rsa.pub
chmod 600 ~/.ssh/authorized_keys
ssh -v username@hostname
By following these steps, you can verify and update your SSH key configurations on Linux machines. This ensures that both the server and client settings support secure key-based authentication.
Below are the steps to enable SSH key-based (passwordless) logins on linux:
On your client machine (the one you'll use to connect), open a terminal and run:
ssh-keygen -t rsa -b 4096
~/.ssh/id_rsa).ssh-copy-id (if available)If you have ssh-copy-id installed, run:
ssh-copy-id username@serverReplace username and server with your actual remote user and server address.
If ssh-copy-id isn’t available, use this command:
cat ~/.ssh/id_rsa.pub | ssh username@server "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
This command:
~/.ssh directory if it doesn’t exist.authorized_keys file.SSH requires specific permissions for security. On the CentOS server, ensure:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
On the CentOS server, open the SSH daemon configuration file:
sudo nano /etc/ssh/sshd_config
Ensure the following settings are enabled (uncomment or add if necessary):
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
If you want to enforce key-based authentication and disable password logins, you can also set:
PasswordAuthentication no
After making changes, restart the SSH service:
sudo systemctl restart sshd
From your client machine, test the connection with verbose output to ensure the key is being used:
ssh -v username@server
Look for lines indicating that your public key is being offered and accepted.
By following these steps, you enable secure, passwordless logins to your linux server using SSH keys.
• Install OpenSSH Client (if not installed):
sudo apt update && sudo apt install openssh-client
• Install OpenSSH Server (if needed):
sudo apt install openssh-server
• Check SSH service status:
sudo systemctl status ssh
• Install OpenSSH Client (usually pre-installed):
sudo dnf install openssh-clients # For Fedora
sudo yum install openssh-clients # For CentOS/RHEL
• Install OpenSSH Server (if needed):
sudo dnf install openssh-server # For Fedora
sudo yum install openssh-server # For CentOS/RHEL
• Start and enable the SSH service:
sudo systemctl start sshd
sudo systemctl enable sshd
• SSH Client is pre-installed.
• Open Terminal and connect:
ssh username@hostname
• Generate an SSH key pair:
ssh-keygen
• Add your SSH key to the ssh-agent:
eval "$(ssh-agent -s)"
ssh-add -K ~/.ssh/id_rsa
• For file transfers, use scp similar to Linux commands.
This cheat sheet covers the essentials to get you started with SSH on different platforms. Happy connecting!
If an SSH server is running in FIPS mode, it limits the allowed cryptographic algorithms. In our case, the ED25519 key we're offering is rejected because FIPS mode on our server isn’t permitting that key type.
We see messages like:
userauth_pubkey: key type ssh-ed25519 not in PubkeyAcceptedKeyTo resolve this, we have a couple of options:
Since RSA keys are FIPS-approved, we can generate and use an RSA key pair on your client machine:
ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_fips
Use ssh-copy-id or manually append the public key:
ssh-copy-id -i ~/.ssh/id_rsa_fips.pub user@fips-enabled-server
Either specify the key on the command line:
ssh -i ~/.ssh/id_rsa_fips user@fips-enabled-serverOr add an entry in our ~/.ssh/config:
nano ~/.ssh/config
Host user@fips-enabled-server
HostName user@fips-enabled-server
User user
IdentityFile ~/.ssh/id_rsa_fips
If for some reason we must use ED25519 keys, we would need to disable FIPS mode or adjust its configuration—but this is generally not advised on systems where FIPS compliance is required.
Disabling FIPS mode could have broader security implications.
If we decide to do so, we would consult our organization’s security policy and update our system settings accordingly.
Next Steps
1. Test with RSA:
After setting up our RSA key, try connecting again:
ssh -v -i ~/.ssh/id_rsa_fips user@fips-enabled-serverVerify in the verbose output that the RSA key is offered and accepted.
2. Review Logs:
Check /var/log/secure or use journalctl -u sshd on the server for any further errors.
cat /var/log/secure
journalctl -u sshd
Using an RSA key should resolve the issue by providing a FIPS-approved method for key-based authentication.
Sometimes if you add a new system or update a new computer to use an existing internal hostname, an error like this can appear:
```
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:qwertyuiopasdfghjklzxcvbnm.
Please contact your system administrator.
Add correct host key in /Users/user/.ssh/known_hosts to get rid of this message.
Offending ED25519 key in /Users/user/.ssh/known_hosts:111
Host key for hostname has changed and you have requested strict checking.
Host key verification failed.```
This error occurs because the SSH client detects that the remote host’s key has changed from what it previously recorded, which could be due to a legitimate server update or a potential security risk. Here’s how to resolve it safely:
1. Verify the Change:
Confirm with your system administrator or hosting provider that the server’s key was intentionally changed. If you trust the source, you can proceed; otherwise, be cautious as it might be a security issue.
2. Remove the Old Key:
You can remove the offending key from your known_hosts file. For example, if the key is on line 111 as indicated, you can either edit the file manually or use the command below:
ssh-keygen -R hostname
OR
ssh-keygen -f '/root/.ssh/known_hosts' -R 'hostname'Which, if it works, will output something similar to
# Host hostname found: line 21
# Host hostname found: line 29
# Host hostname found: line 30
/root/.ssh/known_hosts updated.
Original contents retained as /root/.ssh/known_hosts.old
This command will remove the key for the host hostname from your known hosts.
3. Reconnect to the Host:
When you reconnect, SSH will ask to verify and add the new host key. Make sure the fingerprint matches the one provided by your administrator before accepting it:
ssh hostname
By following these steps, you’ll update your known hosts with the new key and resolve the error.