OpenSSH server

From SaruWiki
Revision as of 21:29, 26 October 2014 by Saruman! (talk | contribs) (ssh server config)
Jump to navigation Jump to search

OpenSSH Server

This package is essential when you want to be able to (safely) administer your server from another place than the console.

To install: simpy use sudo aptitude install openssh-server. This will install the OpenSSH server, plus the OpenSSH client. Since the SSL vulnerbility of may '08, also the ssh-blacklist package is downloaded.

After installing, we need to make the following changes to the default settings in file /etc/ssh/sshd-config:

  • line PermitRootLogin yes should be set to no, so that user root CANNOT log in over SSH! (big security gap!).
  • add a line AllowGroups wheel; adding this ensures that NOBODY can log in over SSH unless you specifically assigned them to the wheel group, reducing the attack surface of your SSH user. Should you need more than one group (e.g. you want to add the group "ldapwheel"), then add the groups separated by spaces: AllowGroups wheel ldapwheel.
  • Change your banner by editing the MOTD file.

Next, make sure the wheel group exist, and add all users to it that are allowed ssh-access: 

groupadd -g 117 wheel
usermod -a -G wheel jan

In the groupadd line, the groupID is explicitly set to 117, but this really is optional. In the usermod line, be sure to use the -a so that your user gets the ssh-users group added, instead of replacing all supplementary groups with this one ssh-users.

If you've added a group that exists in your LDAP server, make sure that those LDAP users are member of that group that you want to give SSH access. This is ofcourse managed from your LDAP management console (be it the commandline ldapmodify or a graphic tool like LDAP Account Manager

When all this is changed, the service should be restarted with sudo /etc/init.d/ssh restart.

One of the nice things of a correctly configured SSH server, is the ability to use scp to copy files between machines.

Changing RSA keys

Occasionally you'll find the RSA key of one of your machines has changed. This may have a number of reasons, a.o. a reinstall or migration of said machine. In any case, when you try to SSH to the machine you get a message like this: 

localhost:~# ssh insomnia@easton.saruman.biz
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
f7:1a:5a:11:ca:20:99:fa:db:1b:b8:75:8e:e5:f1:12.
Please contact your system administrator.
Add correct host key in /home/sixpacjo/.ssh/known_hosts to get rid of this message.
Offending key in /home/sixpacjo/.ssh/known_hosts:4
RSA host key for easton.saruman.biz has changed and you have requested strict checking.
Host key verification failed. 
localhost:~# _

When you get this message it is not possible to connect to the machine mentioned, until you've solved the problem of the RSA key. There are multiple ways to correct the key, but the simplest method seems to be to simply remove the offending key with ssh-keygen. Note that Debian "Lenny" stores the RSA key in two places: one for the host name, one for the IP number. To prevent annoying messages like this: 

Warning: the RSA host key for 'easton.saruman.biz' differs from the key for the IP address '192.168.67.5'
Offending key for IP in /home/sixpacjo/.ssh/known_hosts:4

you should remove the RSA key for the IP number as well. This you do with the following two commands: 

localhost:~# ssh-keygen -R easton.saruman.biz
/home/sixpacjo/.ssh/known_hosts updated.
Original contents retained as /home/sixpacjo/.ssh/known_hosts.old
localhost:~# ssh-keygen -R 192.168.67.5
/home/sixpacjo/.ssh/known_hosts updated.
Original contents retained as /home/sixpacjo/.ssh/known_hosts.old
localhost:~# _

After deleting the "offending RSA keys" like this, you can SSH to the box in question, and your SSH client will save the (new) RSA key for you in your known_hosts file.

Using certificates for SSH login

If your server is open to the Internet, passwords alone may not be safe enough. Plenty of malicious folks will try to brute-force attack your SSH server. Of course you've disabled root login (right? RIGHT?!?) but still... all that attacking clutters your logs, and maybe one day one of your SSH user passwords turns out too weak. That's why it's a good idea to add SSL keys to the mix.

Generating an SSH key

You can generate an SSH key from Linux itself (see DigitalOcean, but in this article we'll use PuTTy, because PuTTy/WinSCP is the go-to tool set for Linux administration from a Windows workstation, and PuTTy's proprietary key management provides some nifty tricks for key management. (based on DigitalOcean howto)

First we start the PuTTyGen utility, by double-clicking on its .exe file.

  • At the bottom of the interface, for Type of key to generate, select SSH-2 RSA;
  • In the Number of bits in a generated key field, specify either 2048 or 4096 (the latter is safer, but takes longer to generate);
  • Now click the Generate button. PuTTyGen needs some entropy, so move your mouse pointer around in the blank area of the Key section for a while until the progress bar is full - a private/ public key pair will then be generated;
  • In the Key comment field, enter your name (or any other comment you'd like), to help you identify this key pair. This is particularly useful in the event you end up creating more than one key pair;
  • A passphrase is optional but recommended: Type & re-type it in the Key passphrase fields. (Really, only leave out the passphrase if you would like to use this particular key pair for automated processes!)

The above actions should look a bit like this:

PuTTyGen interface

  • Now click the Save public key button & choose whatever filename you'd like, saving it in a "safe" folder. I'd recommend a filename that corresponds to the Key comment field content;
  • Then click the Save private key button & choose whatever filename you'd like (you can save it in the same location as the public key, but it should be a location that only you can access and that you will NOT lose!). Keep the file extension to .ppk

Putting the key on the server

To put the key on the server, we need to use not the public key file, as the file itself is in a format that OpenSSH doesn't recognize. So we can again open PuTTyGen, click load to load an existing private key file, and select the private key from the safe folder used below. After entering the passphrase (twice) we see the same information as before (see pic above). From the PuTTyGen interface, we select & copy to clipboard the information in the top window, something like 

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAgEAjisviHZ19eU0F5BtN+F32tcjO72Ne
82Br24XS5cQASuYt8EZXBP1bdh0JFX7KvJIBMzH6KXo0gZQv/UtX4q+9jV9xgCgWq
IAM+WKEVexAkR1RjFc8Bf8pPK62eNsis959+XD0IuuH7Ge/JKTy6ScxU+nyIfBJr/
a894TNPwdCEAbnBdU6WX/Q7g3P7xVaMu2g5okLRkO1tt7wIlt0zrOx86hMvesmIwX
CfZ8qJtp8frmpoxbbCn9akgDPRtmMUEJDDkgrW6oyyMCtCgH0iTEZf3RYq4aOdXAI
bJE9Yu402BPmyZCSDBrqwYfEWn0FgtEsjTlc7TTnUq+X35ndCpwE+g4AV3Fle7e18
eNyqvb3ng2+nSj4uNj2fFqlfNrJXfZGVELmk7xnVH1ypP6WamFHxG81wAqkGnBA2q
W1ItvJxZ3L3mfHX5LKUxMMXbw5hElXtVQI+ZiDPjFqCIqPXagYzIsh/XzKbXoxZnR
abcc14wGdPM+3TuAgyARoVuYyMb6iJz7SMrf1OAvMD6P7AcY5l7PeFG88ABJc67kS
fPAyZRrK7uHllh2P3B3lEzIWrXYvKqjMoOOQj0uAhHtmFVtDvu/bHgJ2BWrTYq9AI
g7AY59QnzK0LO8BxAoTSTKuUNpj+9WP7FUNL60nejm6A68PXQRddVrAZ2SYUuTUB+
/pU0= Joe Sixpack

Note that on pasting this information in e.g. Notepad, then it should be a single line of information.

On a sidenote, if you need the private key in an OpenSSH or ssh.com compatible form, you can use the Conversions tab on the toolbar.

Next, we open a PuTTy SSH session to the server, change directory to the user's home directory (e.g. /home/jsixpack), and in this home directory go into the .ssh directory. Inside that directory there should be a file authorized_keys. If it's not there, create it with the user as owner and read/write for the user only. In the example of user jsixpack: 

cd /home/jsixpack/.ssh
touch authorized_keys
chmod 600 authorized_keys

Then open this file with vi, and copy the public key in there. Again, it should be a single line, beginning with ssh-rsa AAAA and ending with the key comment. Save with :qw and the key is stored!

Configuring the SSH server

To ensure that the SSH server accepts SSH keys, add the following to /etc/ssh/sshd_config, or at least confirm the lines are already there: 

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile     %h/.ssh/authorized_keys

If you've changed any of these settings, restart the SSH server to ensure they're implemented. Then test if you can log in to the server with your SSH key (see next session).

Once you've ensured you can log into the server using only the key and it's associated passphrase, you may wish to disable password-based login. To configure the SSH server to not accept passwords any more, add the following (or confirm it's already set): 

ChallengeResponseAuthentication no
PasswordAuthentication no

Again, restart the server if you've changed these settings. BEWARE! If you haven't properly tested logging in with a key, and you disable password-based login, then you've shut yourself out. Only access to the console can then restore your access...

Configuring PuTTy to use the SSH key

You've added your public key to the server, now add your private key to your PuTTy session information.

Retrieved from "https://www.saruman.biz/saruwiki/index.php?title=OpenSSH_server&oldid=3068"