OpenSSH server: Difference between revisions
(13 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
==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! ([http://www.debian-administration.org/articles/573 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 [[Filling_an_OpenLDAP_database#Adding_a_user_with_LAM | 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 == | == Changing RSA keys == | ||
Line 30: | Line 50: | ||
localhost:~# _ | 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. | 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 SSH keys 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 SSH keys to the mix. | |||
What we're going to do is create an SSH key pair: a public key that we can store on the server, and a private key that we'll use on our end when we connect with the server. | |||
===Generating an SSH key=== | |||
You can generate an SSH key from Linux itself (see [https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys--2 DigitalOcean], but in this article we'll use [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html PuTTy], because PuTTy/WinSCP is the go-to tool set for Linux administration from a Windows workstation, and PuTTy's [http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/key-formats-natively.html proprietary key management] provides some nifty tricks for key management. | |||
(based on [https://www.digitalocean.com/community/tutorials/how-to-create-ssh-keys-with-putty-to-connect-to-a-vps 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: | |||
[[File:Puttygen.png|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 public 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 - which is the public key, 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 side note, 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 [[Vim|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 '':wq'' 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 section). | |||
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. To this end, put your private key in a secure spot accessible from your system. For example, on a secure (encrypted) USB stick. In this example I use a subdirectory of the Documents directory, named Keychain. | |||
Now configure your PuTTy connection like you always would, but also go to the settings category Connection, subsection SSH, subsection Auth. There you'll find a Private key file section, from which you can browse to your .ppk private key file. It should look like this: | |||
[[File:Puttyprivatekey.png|467px]] | |||
Then go back to the Session category to get to the PuTTy "main" screen, and hit Save. That's it. You can now log on to your server using PuTTy, and when connecting Putty will ask for the passphrase, but not for any password local to the server. |
Latest revision as of 16:17, 21 February 2016
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 SSH keys 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 SSH keys to the mix.
What we're going to do is create an SSH key pair: a public key that we can store on the server, and a private key that we'll use on our end when we connect with the server.
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:
- 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 public 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 - which is the public key, 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 side note, 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 :wq 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 section).
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. To this end, put your private key in a secure spot accessible from your system. For example, on a secure (encrypted) USB stick. In this example I use a subdirectory of the Documents directory, named Keychain. Now configure your PuTTy connection like you always would, but also go to the settings category Connection, subsection SSH, subsection Auth. There you'll find a Private key file section, from which you can browse to your .ppk private key file. It should look like this:
Then go back to the Session category to get to the PuTTy "main" screen, and hit Save. That's it. You can now log on to your server using PuTTy, and when connecting Putty will ask for the passphrase, but not for any password local to the server.