- Table of Contents
- Previous Chapter
- Next Chapter

# Chapter 3: Granting access

Access to clients should be granted using the `ssh` protocol.

Clients must allow the monitor to connect using `ssh`. Stealth connects to its clients using ssh certificates, after the monitor's public SSH-key has been transferred to the clients.

### 3.0.1: The monitor's user: creating an ssh-key

The monitor's user calling stealth to scan the client must first generate an `ssh-keypair`:

        ssh-keygen -t rsa

By default this generates a public/private ssh key-pair in the directory `.ssh` in the user's home directory. The program asks for a passphrase. A passphrase can be defined (in which case it must be proviced when stealth is started) or, if the security if the monitor is sufficiently guaranteed, it can remain empty. To generate an ssh-key without passphrase simply press `Enter` in response to the question

        Enter passphrase (empty for no passphrase):

(a confirmation is required: just press `Enter` again).

`Ssh-keygen` then returns a key fingerprint, e.g.,

        03:96:49:63:8a:64:33:45:79:ab:ca:de:c8:c8:4f:e9 user@monitor

which may be saved for future reference.

In the user's `.ssh` directory the files `id_rsa` and `id_rsa.pub` are now created, which completes the preparations at the monitor.

If, instead of running stealth in daemon mode it is preferred to let stealth perform single, but automated integrity scans, then new ssh(1) connections may be difficult to establish if the used ssh-key is passphrase-protected. To implement this scenario (i.e., automated integrity scans using passphrase protected ssh-keys) the program ssh-cron(1) can profitably be used.

### 3.0.2: The client's account: accepting ssh from the monitor's user

Next, at the client's account where stealth's `ssh` command connects to (see also the `USE SSH` specification in section 4.2) ssh-access must be granted to the monitor's user. To do so, the monitor user's file `~/.ssh/id_rsa.pub` is added to the client account user's file `~/.ssh/authorized_keys`:

        # transfer user@monitor's file id_rsa.pub to the client's /tmp
        # directory. Then do:

        cat /tmp/id_rsa.pub >> /home/account/.ssh/authorized_keys

This allows the user at the monitor to login at the account at the client without specifying the client account's password (of course, if the ssh-key is passphrase protected that passphrase must still be provided at the monitor when starting stealth).

### 3.0.3: Logging into the account@client account

When user@monitor now issues, for the first time, the command

        ssh account@monitor

`Ssh` responds like this:

        The authenticity of host 'monitor (xxx.yyy.aaa.bbb)' can't be
        established.
        RSA key fingerprint is c4:52:d6:a3:d4:65:0d:5e:2e:66:d8:ab:de:ad:12:be.
        Are you sure you want to continue connecting (yes/no)?

Answering `yes` results in the message:

        Warning: Permanently added 'monitor,xxx.yyy.aaa.bbb' (RSA) to the
        list of known hosts.

The next time a login is attempted, the authenticity question is not asked anyore. However, the proper value of the host's RSA key fingerprint (i.e., the key fingerprint of the client computer) should always be verified to prevent man in the middle attacks. The proper value may be obtained at the client by issuing there the command

        ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub

This should show the same value of the fingerprint as shown when the first `ssh` connection was established. E.g.,

        1024 c4:52:d6:a3:d4:65:0d:5e:2e:66:d8:ab:de:ad:12:be ssh_host_rsa_key.pub

### 3.0.4: Using the proper shell

On order to minimize the amount of clutter and possibly complications when only a simple command-shell is required for executing commands, it is suggested to use a bash(1) shell when logging into `account@client`'s account.

When another shell is already used for `account@client`, then an extra account (optionally using the same `UID` as the original account, but using sh(1) as the shell), could be defined in the client's `/etc/passwd` file. In the passwd(5) file this could, e.g., be realized for root as rootsh as follows:

        rootsh:x:0:0:root:/root:/bin/bash

If shadow passwording is used, a matching entry in the `/etc/shadow` file is required as well.

- Table of Contents
- Previous Chapter
- Next Chapter