Authentication with SSH works with public keys sent from the remote system. If an SSH client needs to connect to an SSH server, the server sends the public key to the client, which then looks for that key in its files. The following situations can occur here:
- The SSH client finds the key in its list of known server keys, and the key is allocated to the corresponding host name or IP address. The SSH connection can be established without further activity from the user.
- The SSH client does not find the key in its list of known server keys, and also no other key of the same type (RSA or DSA/DSS) for the corresponding host name or IP address. The SSH client assumes that this is the first connection to the server. It shows its public key and the associated fingerprint. The user can verify the key using a copy from another source, and can then decide whether the server should be stored in the list of known SSH servers. If the user declines this verification, the SSH connection is broken immediately.
- The SSH client finds a key for the corresponding host name or IP address, but this is different from the key currently in use. Both keys are displayed, but the SSH connection will be terminated because the SSH client suspects a man-in-the-middle attack. If the public key on the remote system was recently changed, then the administrator has to delete the outdated entry from the list of known servers (see Manually deleting known SSH server keys.
After successfully verifying the server key, the administrator can enter the password for accessing the remote system. The password cannot be entered directly at the command line.
SSH connections are usually closed at the server, e.g. by entering exit in the shell. Sometimes it may be necessary to close the SSH connection with the client, e.g. if the application on the server has problems. The SSH client in LCOS uses the same character string as OpenSSH to close the connection, i.e. ‘tilde - dot’.
