מתוך הפקודה man ssh:
AUTHENTICATION
The OpenSSH SSH client supports SSH protocols 1 and 2. Protocol 2 is the default, with ssh falling back to protocol 1
if it detects protocol 2 is unsupported. These settings may be altered using the Protocol option in ssh_config(5), or
enforced using the -1 and -2 options (see above). Both protocols support similar authentication methods, but protocol
2 is preferred since it provides additional mechanisms for confidentiality (the traffic is encrypted using AES, 3DES,
Blowfish, CAST128, or Arcfour) and integrity (hmac-md5, hmac-sha1, hmac-ripemd160). Protocol 1 lacks a strong mecha-
nism for ensuring the integrity of the connection.
The methods available for authentication are: GSSAPI-based authentication, host-based authentication, public key
authentication, challenge-response authentication, and password authentication. Authentication methods are tried in
the order specified above, though protocol 2 has a configuration option to change the default order:
PreferredAuthentications.
Host-based authentication works as follows: If the machine the user logs in from is listed in /etc/hosts.equiv or
/etc/ssh/shosts.equiv on the remote machine, 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 gen-
eral, 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 either the RSA or DSA algorithms. Protocol 1 is restricted to using only RSA keys, but protocol
2 may use either. The HISTORY section of ssl(8) contains a brief discussion of the two 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 user creates his/her key pair by running ssh-keygen(1). This stores the private key in ~/.ssh/identity (protocol
1), ~/.ssh/id_dsa (protocol 2 DSA), or ~/.ssh/id_rsa (protocol 2 RSA) and stores the public key in ~/.ssh/identity.pub
(protocol 1), ~/.ssh/id_dsa.pub (protocol 2 DSA), or ~/.ssh/id_rsa.pub (protocol 2 RSA) in the user's home directory.
The user should then copy the public key to ~/.ssh/authorized_keys in his/her 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.
The most convenient way to use public key authentication may be with an authentication agent. See ssh-agent(1) for
more information.
Challenge-response authentication works as follows: The server sends an arbitrary "challenge" text, and prompts for a
response. Protocol 2 allows multiple challenges and responses; protocol 1 is restricted to just one chal-
lenge/response. Examples of challenge-response 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 lis-
tening 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, or logs into
the machine and gives the user a normal shell on the remote machine. All communication with the remote command or
shell will be automatically encrypted.
If a pseudo-terminal has been allocated (normal login session), the user may use the escape characters noted below.
If no pseudo-tty 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.
ראשי
צ'אט
16-09-2008, 19:41
מצב כלאיים
