Chapter 3: Granting access

Access to clients (remote hosts) must be granted using the ssh protocol.

Clients must allow the controller to connect using ssh. Stealth connects to its clients using ssh certificates, after the controler's public key has been transferred to its clients.

3.0.1: The controller's user: creating an ssh-key

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

    ssh-keygen -t rsh

This generates a public/private ssh key pair in .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 controller 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@controller

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 controller.

3.0.2: The client's account: accepting ssh from the controller'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 controller's user. To do so, the controller user's file ~/.ssh/id_rsa.pub is added to the client account user's file ~/.ssh/authorized_keys:

    # transfer user@controller'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 controller 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 controller once stealth is started).

3.0.3: Logging into the account@client account

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

    ssh account@controller

Ssh responds like this:

    The authenticity of host 'controller (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 'controller,xxx.yyy.aaa.bbb' (RSA) to the
    list of known hosts.

The next time a login is attempted, the authenticity question isn't 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 computer by issuing (at the client) 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 possible 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.