клиент удаленного входа OpenSSH (OpenSSH remote login client)
Аутентификация (Authentication)
The OpenSSH SSH client supports SSH protocol 2.
The methods available for authentication are: GSSAPI-based
authentication, host-based authentication, public key
authentication, keyboard-interactive authentication, and password
authentication. Authentication methods are tried in the order
specified above, though PreferredAuthentications can be used to
change the default order.
Host-based authentication works as follows: If the machine the user
logs in from is listed in /etc/hosts.equiv or /etc/shosts.equiv on
the remote machine, the user is non-root and the user names are the
same on both sides, or if the files ~/.rhosts or ~/.shosts exist in
the user's home directory on the remote machine and contain a line
containing the name of the client machine and the name of the user
on that machine, the user is considered for login. Additionally,
the server must be able to verify the client's host key (see the
description of /etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts,
below) for login to be permitted. This authentication method
closes security holes due to IP spoofing, DNS spoofing, and routing
spoofing. [Note to the administrator: /etc/hosts.equiv, ~/.rhosts,
and the rlogin/rsh protocol in general, are inherently insecure and
should be disabled if security is desired.]
Public key authentication works as follows: The scheme is based on
public-key cryptography, using cryptosystems where encryption and
decryption are done using separate keys, and it is unfeasible to
derive the decryption key from the encryption key. The idea is
that each user creates a public/private key pair for authentication
purposes. The server knows the public key, and only the user knows
the private key. ssh implements public key authentication protocol
automatically, using one of the DSA, ECDSA, Ed25519 or RSA
algorithms. The HISTORY section of ssl(8) contains a brief
discussion of the DSA and RSA algorithms.
The file ~/.ssh/authorized_keys lists the public keys that are
permitted for logging in. When the user logs in, the ssh program
tells the server which key pair it would like to use for
authentication. The client proves that it has access to the
private key and the server checks that the corresponding public key
is authorized to accept the account.
The server may inform the client of errors that prevented public
key authentication from succeeding after authentication completes
using a different method. These may be viewed by increasing the
LogLevel to DEBUG or higher (e.g. by using the -v flag).
The user creates their key pair by running ssh-keygen(1). This
stores the private key in ~/.ssh/id_dsa (DSA), ~/.ssh/id_ecdsa
(ECDSA), ~/.ssh/id_ecdsa_sk (authenticator-hosted ECDSA),
~/.ssh/id_ed25519 (Ed25519), ~/.ssh/id_ed25519_sk (authenticator-
hosted Ed25519), or ~/.ssh/id_rsa (RSA) and stores the public key
in ~/.ssh/id_dsa.pub (DSA), ~/.ssh/id_ecdsa.pub (ECDSA),
~/.ssh/id_ecdsa_sk.pub (authenticator-hosted ECDSA),
~/.ssh/id_ed25519.pub (Ed25519), ~/.ssh/id_ed25519_sk.pub
(authenticator-hosted Ed25519), or ~/.ssh/id_rsa.pub (RSA) in the
user's home directory. The user should then copy the public key to
~/.ssh/authorized_keys in their home directory on the remote
machine. The authorized_keys file corresponds to the conventional
~/.rhosts file, and has one key per line, though the lines can be
very long. After this, the user can log in without giving the
password.
A variation on public key authentication is available in the form
of certificate authentication: instead of a set of public/private
keys, signed certificates are used. This has the advantage that a
single trusted certification authority can be used in place of many
public/private keys. See the CERTIFICATES section of ssh-keygen(1)
for more information.
The most convenient way to use public key or certificate
authentication may be with an authentication agent. See
ssh-agent(1) and (optionally) the AddKeysToAgent directive in
ssh_config(5) for more information.
Keyboard-interactive authentication works as follows: The server
sends an arbitrary "challenge" text and prompts for a response,
possibly multiple times. Examples of keyboard-interactive
authentication include BSD Authentication (see login.conf(5)) and
PAM (some non-OpenBSD systems).
Finally, if other authentication methods fail, ssh prompts the user
for a password. The password is sent to the remote host for
checking; however, since all communications are encrypted, the
password cannot be seen by someone listening on the network.
ssh automatically maintains and checks a database containing
identification for all hosts it has ever been used with. Host keys
are stored in ~/.ssh/known_hosts in the user's home directory.
Additionally, the file /etc/ssh/ssh_known_hosts is automatically
checked for known hosts. Any new hosts are automatically added to
the user's file. If a host's identification ever changes, ssh
warns about this and disables password authentication to prevent
server spoofing or man-in-the-middle attacks, which could otherwise
be used to circumvent the encryption. The StrictHostKeyChecking
option can be used to control logins to machines whose host key is
not known or has changed.
When the user's identity has been accepted by the server, the
server either executes the given command in a non-interactive
session or, if no command has been specified, logs into the machine
and gives the user a normal shell as an interactive session. All
communication with the remote command or shell will be
automatically encrypted.
If an interactive session is requested ssh by default will only
request a pseudo-terminal (pty) for interactive sessions when the
client has one. The flags -T and -t can be used to override this
behaviour.
If a pseudo-terminal has been allocated the user may use the escape
characters noted below.
If no pseudo-terminal has been allocated, the session is
transparent and can be used to reliably transfer binary data. On
most systems, setting the escape character to 'none' will also make
the session transparent even if a tty is used.
The session terminates when the command or shell on the remote
machine exits and all X11 and TCP connections have been closed.
