Secure Shell (SSH) is a core tool in a sysadmin's arsenal and provides a secure and encrypted connection and method of communication between a client user and a server. It is mainly used to remotely control a machine. In the Linux landscape, the package OpenSSH is one of the most popular and complete choices to enable communication via SSH. Newcomers to SSH should first consult the Debian SSH wiki [archive] to learn the basics.
Figure: Example SSH Login 
General Hardening Tips
Table: SSH Hardening Recommendations
|Keystroke and Mouse Fingerprinting
||Beware of keyboard keystroke and computer mouse-based deanonymization as explained in the Surfing Posting Blogging chapter.
|Mobile Shell Roaming and Echo
||mosh [archive] might be a useful addition. However, it requires UDP and it is therefore difficult to utilize over Tor, see: Tunnel UDP over Tor. Is it safe to mosh? [archive]
- Any references to SSH breaks in the Snowden archives applied to some outdated ciphers.
- This has since been addressed by hardened OpenSSH settings (but are not included in Whonix ™) and upstream disabling vulnerable algorithms.  
||To generate stronger SSH keys, run.
||Configuring SSH servers to listen on non-default ports reduces noise (automated hacking attempts) and may also increase security from less skilled attackers.
||SSH can be combined with Two-factor Authentication (2FA), but this is undocumented at present.
||For additional tips, refer to the Whonix forum discussion: Locking down your SSH client [archive].
Secure SSH Client and Server Settings
There is a client package and a server package,
openssh-server. As the time of writing, Debian buster is using OpenSSH version 7.9. That version will be the focus of these instructions. Covered topics include:
- Key generation for authentication/sign-in purposes.
- Suggested secure settings for both the client and server configurations.
- A sample set of iptables rules to allow communication between client and server.
Before you can connect to a server (or host) through SSH, a keypair is required. This consists of a public key, which you share with the server, and a private key which is used to verify that you are actually signing in. A passphrase (strongly recommended) can be added to your key which will be asked each time you sign into a server.
Once the server has your public key, it is placed into an
authorized_keys file. The private key is not shared with anyone and should be kept in a safe place -- it typically resides at
/home/username/.ssh/private-key on the client's machine with root permissions (0600). The private key is how the server authenticates your username.
1. Generate the SSH keypair.
Use a tool called "ssh-keygen". On the command line, type.
ssh-keygen -o -a 75 -t ed25519
-o produces a key that is compatible with OpenSSH instead of the older style
-a refers to the number of rounds of KDF (key derivation function). This strengthens the key against a brute force attack to break the passphrase if the (private) key were to be stolen. A value of 75 to 100 is more than adequate. Remember that the more rounds that are specified, the longer it takes to authenticate (sign in). This depends on your CPU, your workload at the time of sign in, the amount of cores, and available memory among other factors.
-t specifies what type of key to generate. The choices are:
ed25519. RSA and ECDSA are older keys, and OpenSSH recommends
ed25519 as the best choice.
2. Store the SSH keypair.
Upon generation of your keypair, OpenSSH will ask if the keys should be stored at:
yes. Permissions will be automatically set in Debian, but there have been reports of wrong permissions on certain other distributions. For reference, the correct permissions are as follows:
- for the public key,
0644 is needed; and
- for the private key
0600 (root) is vital.
Having too lax permissions will prevent logins and cause unwanted errors.
3. Copy the key to the server you want to sign into.
This only needs to be done once per server. The
ssh-copy-id command works for this task, run.
ssh-copy-id -i ~/.ssh/public-key.pub user@host
user is your username and
host is the name/address of the server. Only copy the public key. It ends with
The ssh-copy-id utility will check for the correct permissions before it allows the key to be transferred.
4. Login to the server.
Once copied to the server, you can now login anytime with:
If you chose a passphrase for your key, you will be asked to enter it now.
The keypair generation procedure is now complete. You have successfully generated a keypair and sent your public key to your chosen server.
Client and Server Configuration File Settings
The next step is to set up secure settings for the client and server configuration files. Examples will be given for both client and server. The relevant files are:
Client Configuration File
Review needed! [archive] See also https://manpages.debian.org/ssh_config [archive]
SendEnv LANG LC_*
## Strongest ciphers:
## Most secure MACs:
## Secure Kex algos:
#ProxyCommand ssh -q -W %h:%p gateway.example.com
Server Configuration File
Review needed! [archive] See also sshd configuration file man page [archive].
- Changing the sshd configuration can prevent future successful SSH connections to your servers.
- It is probably best to only set this up for new servers or if you do not mind re-installing the server should you lock yourself out.
- If a server console interface (ability to run repair commands from server host web administrator interface) is available, it is certainly far less risky to make huge changes to the ssh configuration.
- Do not proceed without a backup of the server and knowledge of how to restore the server should anything go wrong.
- How to open a terminal (emulator) such as xfce4-terminal.
- How to open two terminal emulators or multiple terminal emulator tabs at the same time.
1. Open at least two SSH connections in two different terminal (tabs).
One is used as a backup should the SSH connection be accidentally closed in the middle of the setup.
2. View the fingerprint of the server's ed25519 public key.
Fine hosting providers will also show the server fingerprint in the server web interface.
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
3. Restart the sshd server.
sudo systemctl restart sshd
Existing SSH connections should not be interrupted by Debian default.
4. Open a new terminal (tab) and see if you can still SSH to the server.
If yes, proceed.
5. Note: When using the configuration file below, the following warning might appear. IP address and SHA256 hash will be different.
@ 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
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/user/.ssh/known_hosts:35
ssh-keygen -f "/home/user/.ssh/known_hosts" -R "xxx.xxx.xxx.xxx"
ED25519 host key for xxx.xxx.xxx.xxx has changed and you have requested strict checking.
Host key verification failed.
It will look similar to the following.
256 SHA256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649 root@node (ED25519)
6. Make a backup of the old SSH configuration file.
cp /etc/ssh/sshd_config /etc/ssh/sshd_config_backup
7. View the backup file
/etc/ssh/ssh_config_backup with a text editor to check if the backup was successful.
8. Clear contents of
echo "" | sudo tee /etc/ssh/sshd_config
9. Open file
/etc/ssh/sshd_config with root rights.
Paste the following contents.
## Protocol 1 is dangerously outdated!
## 22 is standard, you can make it anything.
## On commandline, when connecting as client,
## use the “-p” option if not port 22;
## example port 3243; ssh user@host -p 3243
## means only ipv4, no v6 allowed
## this is okay because of strict firewall/ AppArmor. For an onion-only server, you listen on 127.0.0.1
## comment out if ipv6 is disabled via sysctl or iptables or both
## comment in if ipv6 should be enabled
## location of server private key
## Strongest ciphers:
## Most secure MACs:
## Secure Kex algos:
## Logging - optional - okay to leave commented out
# unless you need logging, leave commented out
# how long does the prompt stay if client has a passphrase to enter
# With keypairs, the "prohibit-password" option accomplishes the same thing so root is denied
# Safer to deny root obviously
## Specifies whether password authentication is allowed. The default is yes.
## use public keys ed25519 so no password authentication.
## A passphrase is optional for the key, but that is not part of this option.
## This option refers to old style password-only authentication (not secure)
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
## number of allowed login attempts, if there is a passphrase associated with the key
## number of allowed sessions with the same client
## TODO: why would we modify that?
## Specifies whether public key authentication is allowed. The default is yes.
## always use public keys, not passwords
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
# The default is no.
## circumstance specific.
## This refers to the ssh-agent.
## Useful when running a local instance and client/server exist on same machine
## Be careful with this. Avoid forwarding if you can.
## If you do not forward tcp, leave this commented out.
## Default is yes.
## dependent on connection and network.
## Sometimes useful, sometimes not.
## And okay default is to say “no” and if it turns out you need it, then do “yes.”
## Forwarding X11 is not a good idea
## this prints the "Last login: Mon Dec 5 08:21:15 2019 from 192.33.4444" message
## second amount to keep connection alive
## this is a white space separated list of allowed user login names. Only user names on this list will be allowed to login
AcceptEnv LANG LC_*
#Subsystem sftp /usr/lib/openssh/sftp-server
Save the file.
10. Restart the ssh server. All existing SSH connections will remain open.
sudo systemctl restart sshd
Keep the ssh connection open.
11. Open another terminal (tab) and try to SSH to the server.
- If it works, the process is complete.
- If it does not work, use your still open terminal to check for configuration errors before trying again.
Those are the completed SSH configuration files. Please note that the entries preceded by a
# are not necessary for functional use; they are included only as examples of what is possible in SSH. If you do not have a specific use for any of the commented out options in either configuration file, do not use them at all.
The Ciphers, MACs and Kex algorithms are all the strongest possible at the time of writing with OpenSSH version 7.9 on Debian buster. The entries in the configuration files above are the most important and will establish a functional and well-guarded setup. Use ed25519 keys only -- rsa and ecdsa are outdated. Use the
ssh-keygen command to generate the keys.
VisualHostKey yes entry in the
/etc/ssh/ssh_config file is so when you login, openssh shows you an ascii-generated picture of what the key looks like. In addition to all the other verifications, this is one last line of defense to alert you to a changed or wrong key.
Generally the newer OpenSSH versions will choose the strongest cipher on their own when negotiating a connection, but the configuration files establish in what order they are parsed. Both sides need to have the same or compatible openssh versions and cipher, mac, and kex algorithm options.
Firewall Settings and Rules
Warning: This is for testers-only!
It is necessary to make specific firewall rules for your intended SSH activity. For example, if you wanted to connect to a server at
123.45.678 and both your configuration and the server's configuration specify port
4675 to communicate over:
sudo iptables -A OUTPUT -p tcp -o [interface-name] -s [your client ssh ip] -d [ssh server ip] --dport 4675 --j ACCEPT
Then to let them respond:
sudo iptables -A INPUT -p tcp -i [interface-name] -s [ssh server ip] -d [your client ip] --dport 4675 --j ACCEPT
This assumes a default-deny policy for INPUT and OUTPUT. If you have a default-allow for OUTPUT, then the following rule must be added as the last one in the OUTPUT chain:
sudo iptables -A OUTPUT --j DROP
This ensures the outgoing rules you have are the only ones that allow traffic. Iptables parses in order, so when it does not see a rule matching a packet not on your list, it checks each one in the chain until it finds a match with the last rule and drops the packet. Also, SSH only uses the TCP protocol, so no UDP rules are explicitly needed.
This should complete the SSH setup. Some people also recommend re-generating the moduli file that comes in
/etc/ssh. If you use the settings above, look at the kex algorithms. Since no diffie hellman group exchange kex algorithms are used to exchange keys, it is unnecessary to regenerate the moduli. The chosen kex algo is curve25519.
Search engines: YaCy | Qwant | ecosia | MetaGer | peekier | Whonix ™ Wiki
Priority Support | Investors | Professional Support
Whonix ™ | © ENCRYPTED SUPPORT LP | Freedom Software / Open Source (Why?)
The personal opinions of moderators or contributors to the Whonix ™ project do not represent the project as a whole.