SSH is considered secure, it is called Secure Shell after all, but there is a fundamental flaw in that most people will assume the default SSH configuration on a Linux distro will be secure by default. Not so, script kiddies and the like will attempt to blast port 22 (the default SSH port) as well as try other exploits based on a default SSH configuration.
That is why it’s crucial you take a bit of time to change the default config.
So let’s take a look at what we can do.
First up, configure a user with keys.
# Create the user
useradd -d /home/myuser -s /bin/bash -c “My User” myuser
# Set a password
# Create the .ssh directory and set permissions
chown myuser:myuser /home/myuser/.ssh
chmod 700 /home/myuser/.ssh
# Create the private / public key pair
- Download Putty (the package that includes PuttyGen)
- Open up PuttyGen
- Under the parameters heading ensure you select SSH-2 RSA, and set the key bits as desired
- Then click Generate, move your mouse around for random input
- Copy the public key from the textbox called Key
- Enter a key passphrase
- Save a copy of the private & public key, on your local machine
# Installing the key
- Paste the public key content into notepad and save this as a file called authorized_keys
- Connect to your machine using SFTP and transfer the authorized_keys file to your home directory
- Login to your machine via SSH
- Move the authorized_keys file into /home/myuser/.ssh
- Change ownership and permissions
chown myuser:myuser /home/myuser/.ssh/authorized_keys
chmod 600 /home/myuser/.ssh/authorized_keys
# Connect using keys
- When you SSH to your server now you should use your private key
- In Putty you specify this under SSH -> Auth -> Private Key File For Auth.
- Specify the location of the private key that you saved earlier
- You will probably need to make the config changes below before key authentication will be enabled.
I flatten the default config and start from scratch…
# A high port number, higher the better Port 6222 # Only listen on a specific IP ListenAddress 192.168.140.2 # Only support Protocol 2 Protocol 2 # Path to host keys generated during install HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key # Allows OpenSSH to run a small amount of code as root, the rest is run through a chroot jail UsePrivilegeSeperation yes # Checks .ssh/* in your home directory to ensure correct permissions before allowing you to login StrictModes yes # Regenerates the server key after 1 hour KeyRegenerationInterval 3600 # How many bits to use in the server key ServerKeyBits 2048 # Specifies where ssh log messages should go (i.e. /var/log/auth.log) SyslogFacility AUTH # The log level to use LogLevel INFO # The time to wait (in seconds) before dropping the connection, if the user has not logged in LoginGraceTime 30 # Disables root login PermitRootLogin no # Allows RSA key based authentication RSAAuthentication yes # Allows public key authentication PubKeyAuthentication yes # Ignores .rhosts for authentication IgnoreRhosts yes # Whether to use .rhosts auth as part of RSA auth RhostsRSAAuthentication no # Host based authentication, not secure, relies on either DNS being correct or client provided host name! HostbasedAuthentication no # Don't allow blank passwords PermitEmptyPasswords no # Basically the same as password authentication ChallengeResponseAuthentication no # Don't allow password as authentication method! Be careful! Before setting this ensure that you have key based authentication working! Uncomment when key based auth is working. #PasswordAuthentication no # Don't allow forwarding of X11 connections X11Forwarding no # Don't print the motd PrintMotd no # Don't print the last users logged in PrintLastLog no # Keeps the SSH connection open TCPKeepAlive yes # Determines when to drop connections based on total unauthenticated connections & max number of connections before dropping everything MaxStartups 10:30:60 # Banner to display on login Banner /etc/issue.net # A list of users that can login via SSH AllowUsers <list your valid ssh users> # Not really relevant as password auth is disabled, but if you do enable password auth then auth requests will go through PAM checks UsePAM yes This will by no means make your server invincible so you should also consider using a firewall, a server process (e.g. fail2ban, denyhosts) to block dictionary attacks,TCP wrappers to only allow connections from specific IP ranges and port knocking. I hope you've found this useful, if you have any questions or comments just drop them below!