ssh protocol.
The client must allow the controller to connect using ssh. Since normally
no username and password can be given, the client must allow the controller to
connect without specifying a password.
This is realized using public key technology, assuming open-SSH is
available on both computers, with the client running an sshd daemon.
The user on the controller who will call stealth to scan the client,
now generates an ssh-keypair:
ssh-keygen -t rsh
This will generate a public/private ssh key pair in .ssh in the user's
home directory. The program asks for a passphrase which should, for the
purpose of stealth be empty: just pressing Enter as a response to
the question
Enter passphrase (empty for no passphrase):
will do the trick (a confirmation is requested: press Enter again).
The program 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 and used for future reference.
In the directory user's .ssh directory the files id_rsa and
id_rsa.pub are now created.
This completes the actions on the controller.
Next, the account on the client where the ssh command connects to
(using a specification in the policy file like
USE SSH /usr/bin/ssh -q account@client
must now grant access to the controller's user. In order to do so, the file
id_rsa.pub of the user at the controller is added to the file
authorized_keys in the .ssh directory of the account on the client:
# 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
Now user@controller may login at acount@client without specifying a password.
When user@controller now issues the command
ssh account@controller
Ssh responds as follows:
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 the command
ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
This should result in the same value as the fingerprint shown when the
first ssh connection was made. E.g.,
1024 c4:52:d6:a3:d4:65:0d:5e:2e:66:d8:ab:de:ad:12:be ssh_host_rsa_key.pub
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 or sh shell when logging into the
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 used.
In the passwd(5) file this could be realized for root as
rootsh as follows:
rootsh:x:0:0:root:/root:/bin/sh
If shadow passwording is used, an appropriate entry in the /etc/shadow
file is required as well.