Secure Shell (SSH)
From Whonix
(Redirected from Ssh)
Introduction[edit]
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 [1]
General Hardening Tips[edit]
Table: SSH Hardening Recommendations
| Recommendation | Description |
|---|---|
| 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] |
| SSH Breaks | |
| SSH Keys | To generate stronger SSH keys, run.
ssh-keygen -t ed25519
|
| SSH Ports | Configuring SSH servers to listen on non-default ports reduces noise (automated hacking attempts) and may also increase security from less skilled attackers. |
| SSH Servers |
|
| Two-factor Authentication | SSH can be combined with Two-factor Authentication (2FA), but this is undocumented at present. |
| Miscellaneous | For additional tips, refer to the Whonix forum discussion: Locking down your SSH client [archive]. |
Secure SSH Client and Server Settings[edit]
There is a client package and a server package, openssh-client and 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.
Key Generation[edit]
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
-oproduces a key that is compatible with OpenSSH instead of the older style.pem.-arefers 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.-tspecifies what type of key to generate. The choices are:rsa,ecdsaanded25519. RSA and ECDSA are older keys, and OpenSSH recommendsed25519as the best choice.
2. Store the SSH keypair.
Upon generation of your keypair, OpenSSH will ask if the keys should be stored at: /home/your-username/.ssh; reply 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,
0644is 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 .pub.
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:
ssh user@host
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[edit]
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: /etc/ssh/ssh_config and /etc/ssh/sshd_config.
Client Configuration File[edit]
Testers only!
Review needed! [archive] See also https://manpages.debian.org/ssh_config [archive]
/etc/ssh/ssh_config:
Host * ## ipv4 AddressFamily inet IdentityFile ~/.ssh/id_ed25519 Port 22 Protocol 2 ForwardX11 no PubkeyAuthentication yes StrictHostKeyChecking ask VisualHostKey yes HashKnownHosts yes User user Host host SendEnv LANG LC_* ## Strongest ciphers: Ciphers chacha20-poly1305@openssh.com ## Most secure MACs: MACs hmac-sha2-512-etm@openssh.com ## Secure Kex algos: KexAlgorithms curve25519-sha256@libssh.org Tunnel no #TunnelDevice any:any #PermitLocalCommand no #ProxyCommand ssh -q -W %h:%p gateway.example.com
Server Configuration File[edit]
Testers only!
Review needed! [archive] See also sshd configuration file man page [archive].
Warnings:
- 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.
Prerequisite knowledge:
- 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 SHA256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649. 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 remove with: 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 /etc/ssh/sshd_config.
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! Protocol 2 ## 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 Port 22 ## means only ipv4, no v6 allowed AddressFamily inet ## this is okay because of strict firewall/ AppArmor. For an onion-only server, you listen on 127.0.0.1 ListenAddress 0.0.0.0 ## comment out if ipv6 is disabled via sysctl or iptables or both ## comment in if ipv6 should be enabled #ListenAddress :: ## location of server private key HostKey /etc/ssh/ssh_host_ed25519_key ## Strongest ciphers: Ciphers chacha20-poly1305@openssh.com ## Most secure MACs: MACs hmac-sha2-512-etm@openssh.com ## Secure Kex algos: KexAlgorithms curve25519-sha256@libssh.org ## Logging - optional - okay to leave commented out #SyslogFacility AUTH # unless you need logging, leave commented out #LogLevel INFO # how long does the prompt stay if client has a passphrase to enter LoginGraceTime 2m # With keypairs, the "prohibit-password" option accomplishes the same thing so root is denied PermitRootLogin prohibit-password # Safer to deny root obviously #PermitRootLogin no ## 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) PasswordAuthentication no # Change to yes to enable challenge-response passwords (beware issues with # some PAM modules and threads) ChallengeResponseAuthentication no ## number of allowed login attempts, if there is a passphrase associated with the key MaxAuthTries 3 ## number of allowed sessions with the same client ## TODO: why would we modify that? #MaxSessions 4 ## Specifies whether public key authentication is allowed. The default is yes. ## always use public keys, not passwords #PubkeyAuthentication yes # 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. UsePAM no ## circumstance specific. ## This refers to the ssh-agent. ## Useful when running a local instance and client/server exist on same machine AllowAgentForwarding no ## Be careful with this. Avoid forwarding if you can. ## If you do not forward tcp, leave this commented out. ## Default is yes. AllowTcpForwarding no ## 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.” TCPKeepAlive yes ## Forwarding X11 is not a good idea X11Forwarding no PrintMotd no ## this prints the "Last login: Mon Dec 5 08:21:15 2019 from 192.33.4444" message #PrintLastLog yes #UseLogin no #PermitUserEnvironment no ## second amount to keep connection alive #ClientAliveInterval 0 UseDNS no ## this is a white space separated list of allowed user login names. Only user names on this list will be allowed to login AllowUsers user #Banner /etc/issue.net AcceptEnv LANG LC_* #Subsystem sftp /usr/lib/openssh/sftp-server #PermitTunnel no #ChrootDirectory none
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.
Notes[edit]
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.
The 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[edit]
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.
See Also[edit]
Footnotes[edit]
Whonix ™ is Supported by Evolution Host DDoS Protected VPS. Stay private and get your VPS with Bitcoin or Monero.
Search engines: YaCy | Qwant | ecosia | MetaGer | peekier | Whonix ™ Wiki
We are looking for help in managing our social media accounts. Are you interested?
This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! Read, understand and agree to Conditions for Contributions to Whonix ™, then Edit! Edits are held for moderation. Policy of Whonix Website and Whonix Chat and Policy On Nonfreedom Software applies.
Copyright (C) 2012 - 2020 ENCRYPTED SUPPORT LP. Whonix ™ is a trademark. Whonix ™ is a licensee [archive] of the Open Invention Network [archive]. Unless otherwise noted, the content of this page is copyrighted and licensed under the same Freedom Software license as Whonix ™ itself. (Why?)
Whonix ™ is a derivative of and not affiliated with Debian [archive]. Debian is a registered trademark [archive] owned by Software in the Public Interest, Inc [archive].
Whonix ™ is produced independently from the Tor® [archive] anonymity software and carries no guarantee from The Tor Project [archive] about quality, suitability or anything else.
By using our website, you acknowledge that you have read, understood and agreed to our Privacy Policy, Cookie Policy, Terms of Service, and E-Sign Consent. Whonix ™ is provided by ENCRYPTED SUPPORT LP. See Imprint, Contact.