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.