home       inleiding       sysadmin       services       links       bash       werk       nothing      

centos 72 -- apache2 with virtual hosts -- sftp key-ed access

part5: key based ssh logins

  1. about
    This might be the easiest part of the exercise. But mentally this is always difficult. The concept of using keys compared to using passwords seems difficult to understand. Especially customers don't seem to understand the need.
    • password authentication
      A password is a word to pass a door:
      You come to a guarded door.
      Behind the door someone asks, "who is there?"
      and your answer "my name is john"
      "what is your password?" the guard asks
      you say "wxyz9876"
      Now the guard looks up your name in the list of people who can enter, and checks your password. In case it is listed encrypted, he will use the encryption-algorithm on whatever you said, and compare it with the encrypted field on his list. You may pass if his newly calculated result, and the field on the list are the same.
      The biggest problem is the guard: HE HEARS YOUR PASSWORD UNENCRYPTED
      So if you give your password to a compromised guard, even if there is a tunnel so nobody else can hear your password, he still can. There is always a process on the server you log on to, that will see your password in clear text. This password resides in memory for at least a short time (but it could be a long time), and a system memory dump might reveal it.
      The second problem is the list of encrypted passwords. It could perhaps be decrypted. Or someone makes a database of all possible encrypted passwords, and compared it to those on the list.
    • key authentication
      Comes keyed access. We always use keys on doors, these days. We can look at our physical key as if it where a private key. We can protect it with a password in our wallet. But only we will hear or see that password. The key is useless without this private password. The password can only be heard if our wallet is compromised. (this can happen when your own computer is infected with spy-ware or a key logger)
      The LOCK on the door of the server is your PUBLIC key. People can try and put needles in YOUR lock on the distant door, but the chances of them succeeding depends on extremely extreme luck. Typically 2048bit keys are used these days. With 2 to the power of 2048 key possibilities, a number with more than 600 digits, a brute force attack seems not possible.
      You create your own key (private key) and keep it secure (password and read only to you alone).
      You also create the lock (public key) and you can put it in place on the server by the old password principle. Once in place, one makes the access with passwords impossible, either by giving you a password with 32 characters that is never communicated to you, or by destroying the list of encrypted results (not allowing password authentication anymore)
  2. key generation
    Your private keys belong to your client machine. The one you work on. To generate them we will use the ubuntu-student-client machine. Generating keys itself is very simple. In our case, we'll have to generate at least two key-pairs for our 2 web-customers. What the administrator does with his/her own account depends on the company policy you work with. However, you will always need one account with simple password access and administrator rights. Keys expire.
    In my case I have the users rock and roll. I proceed as follows:

    • log in to ubuntu-student-client as rock
      I will log in to ubuntu-student-client as my first virtual user: rock
      $ ssh -p 65250 rock@rohtang.gnubizz.net
      rock@rohtang.gnubizz.net's password: 
      Welcome to Ubuntu 14.04.4 LTS (GNU/Linux 3.13.0-85-generic x86_64)
        * Documentation:  https://help.ubuntu.com/
      System information as of Sun May  8 12:15:50 CEST 2016
      System load:  0.0               Processes:           145
      Usage of /:   5.3% of 49.09GB   Users logged in:     5
      Memory usage: 31%               IP address for eth0:
      Swap usage:   0%

      Since I got a non-bash prompt, i'll type bash to get it:

      $ bash
    • Now it's time to generate the key-pair with ssh-keygen:
      Make sure you use a password on your key-file that is different from your ssh-password to really test the authentication ...
      rock@ub14-04-student-client:~$ ssh-keygen
      Generating public/private rsa key pair.
      Enter file in which to save the key (/home/rock/.ssh/id_rsa): 
      Created directory '/home/rock/.ssh'.
      Enter passphrase (empty for no passphrase): 
      Enter same passphrase again: 
      Your identification has been saved in /home/rock/.ssh/id_rsa.
      Your public key has been saved in /home/rock/.ssh/id_rsa.pub.
      The key fingerprint is:
      71:67:6e:4e:c7:42:d8:14:e4:e9:73:48:f0:23:ce:04 rock@ub14-04-student-client
      The key's randomart image is:
      +--[ RSA 2048]----+
      |        E ..+.   |
      |         . B .   |
      |        . = @    |
      |         * O +   |
      |        S o O +  |
      |           + =   |
      |            .    |
      |                 |
      |                 |


  3. public key install on webserver
    I follow with the installation of the public key on the server.I have to REMEMBER that
    - why don't I use my FQDN ...
    rock@student-client:~$ ssh-copy-id -i .ssh/id_rsa.pub rock.netmusic.be

    The authenticity of host 'rock.netmusic.be (2a01:4f8:202:6116:1000::1118)' can't be established.
    ECDSA key fingerprint is 39:2e:83:14:c2:ec:11:c4:db:56:88:1f:69:ec:10:99.
    Are you sure you want to continue connecting (yes/no)?    yes
    /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
    /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
    rock@rock.netmusic.be's password:   x-x-x-x
    Number of key(s) added: 1
    Now try logging into the machine, with:   "ssh 'rock.netmusic.be'"
    and check to make sure that only the key(s) you wanted were added.

    I'll do exactly as asked by the last two lines, and I will check my public key on their server: 

    rock@ub14-04-student-client:~$ ssh rock.netmusic.be
    rock@rock.netmusic.be's password: 
    Last login: Sat May  7 08:32:53 2016
    [rock@centos72-s18 ~]$ cat .ssh/authorized_keys 
    ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDSpnPlAj/eMEpJll5643UmbwT3C/hwhcamOqlt5lIyuLrU8iq2FnzuOyXmPxnrB+kSvg218zuxdgpYk8Ruq+dXK3FOz3a7EcVOaDd+eXelZMd9pyCK2p+iIee2VgQMuzGLQQxKtE0o/201SLtj0r4jcmmAEGAvj9xPlT5ZRKe1guEzB6mWj52yvcVKQIr4c/nMh+iOho4gpXzaI1Ebq06aMZbZrgnDq130Wrg0BCLpLdGRgPdKWuDzzMc4qUoINZIlcA4BDJwRy4Tr3Hg25PJNjXjN/BcObImnCLb5YUpD72v0fBXWqKQiaBGa4jSKvQK1kucWH6AKkunNeI2UoHUd rock@ub14-04-student-client
    rock@ub14-04-student-client:~$ exit
    $ exit
    Connection to rohtang.gnubizz.net closed.

    Next after logging-out I will compare with my own public key:

    rock@ub14-04-student-client:~$ cat .ssh/id_rsa.pub 
    ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDSpnPlAj/eMEpJll5643UmbwT3C/hwhcamOqlt5lIyuLrU8iq2FnzuOyXmPxnrB+kSvg218zuxdgpYk8Ruq+dXK3FOz3a7EcVOaDd+eXelZMd9pyCK2p+iIee2VgQMuzGLQQxKtE0o/201SLtj0r4jcmmAEGAvj9xPlT5ZRKe1guEzB6mWj52yvcVKQIr4c/nMh+iOho4gpXzaI1Ebq06aMZbZrgnDq130Wrg0BCLpLdGRgPdKWuDzzMc4qUoINZIlcA4BDJwRy4Tr3Hg25PJNjXjN/BcObImnCLb5YUpD72v0fBXWqKQiaBGa4jSKvQK1kucWH6AKkunNeI2UoHUd rock@ub14-04-student-client

    I see enough similarities to decide that they are indeed the same ..

  4. testing
    Testing is difficult. How will we see the difference between password authenticated and public-key authenticated? Well, a first is to use different passwords for both. Secondly, key-authentication usually only asks the password once for a large amount of time, like as long as you are logged in, your key-files will be unlocked.
    So we test with rock:
    rock@ub14-04-student-client:~$ ssh rock.netmusic.be
    rock@rock.netmusic.be's password:
    ... but the machine rock.netmusic.be keeps asking for a password.
    except when we disable SElinux:
    [root@centos72-s18 log]# setenforce 0
    rock@ub14-04-student-client:~$ ssh rock.netmusic.be
    Last login: Sun May 8 14:54:59 2016 from 2a01:4f8:202:6116:1000::1250
    [rock@centos72-s18 ~]$
    So we have a problem with SElinux.
    Moreover, when we use key authentication on the same machine as teacher, we don't have the given problem. So it must have something to do with using a different directory ( /users-www in stead of /home )
    $ sudo semanage fcontext --add --type ssh_home_t "/users-www/.*/\.ssh(/.*)?"
    $ sudo restorecon -Rv /users-www
    restorecon reset /users-www/rock/.ssh context unconfined_u:object_r:default_t:s0->unconfined_u:object_r:ssh_home_t:s0
    restorecon reset /users-www/rock/.ssh/authorized_keys context unconfined_u:object_r:default_t:s0->unconfined_u:object_r:ssh_home_t:s0

    Now we have to repeat most of the work for our second user roll