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.
ssh-keygen -t rsaBy default this generates a public/private ssh key-pair in the directory
.sshin 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
Enterin response to the question
Enter passphrase (empty for no passphrase):(a confirmation is required: just press
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@monitorwhich may be saved for future reference.
In the user's
.ssh directory the files
are now created, which completes the preparations at the monitor.
If, instead of running stealth in deamon 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.
sshcommand connects to (see also the
USE SSHspecification 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.pubis added to the client account user's file
# 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).
Sshresponds 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
yesresults 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.pubThis should show the same value of the fingerprint as shown when the first
sshconnection 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
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
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/bashIf shadow passwording is used, a matching entry in the
/etc/shadowfile is required as well.