F3726, F3211, F3174, R5135, R3816-HP Firewalls and UTM Devices System Management and Maintenance Configuration Guide-6PW100

160
Sta
g
es Descri
p
tion
Key exchange
The two parties use the Diffie-Hellman (DH) exchange algorithm to dynamically
generate the session key for protecting data transfer and the session ID for identifying
the SSH connection. In this stage, the client authenticates the server as well.
Authentication
The SSH server authenticates the client in response to the client's authentication
request.
Session request
After passing authentication, the client sends a session request to the server to request
the establishment of a session (Stelnet, SFTP, or SCP).
Interaction
After the server grants the request, the client and the server start to communicate with
each other in the session.
In the interaction stage, you can execute commands from the client by pasting the
commands in text format (the text must be within 2000 bytes). The commands must be
available in the same view. Otherwise, the server might not be able to execute the
commands correctly.
If you want to execute commands of more than 2000 bytes, you can save the
commands in a configuration file, upload it to the server through SFTP, and use it to
restart the server.
271BSSH authentication
When the device acts as an SSH server, it supports the following authentication methods:
• Password authentication—The SSH server uses AAA for authentication of the client. During
password authentication, the SSH client encrypts its username and password, encapsulates them
into an authentication request, and sends the request to the server. After receiving the request, the
SSH server decrypts the request to get the username and password in plain text, checks the validity
of the username and password locally or by a remote AAA server, and then informs the client of the
authentication result.
• Publickey authentication—The server authenticates the client by the digital signature. During
publickey authentication, the client sends the server a publickey authentication request that contains
its username, public key, and publickey algorithm information (or the digital certificate that carries
the public key information). The server examines whether the public key is valid. If the public key is
invalid, the authentication fails. Otherwise, the server authenticates the client by the digital
signature. Finally, it informs the client of the authentication result. The device supports using the
publickey algorithms RSA and DSA for digital signature.
A client can send public key information to the device that acts as the server for validity check in
either of the following methods:
{ The client directly sends the user's public key information to the server, and the server checks
the validity of the user's public key.
{ The client sends the user's public key information to the server through a digital certificate, and
the server checks the validity of the digital certificate. When acting as a client, the device does
not support this method.
• Password-publickey authentication—The server requires clients that run SSH2 to pass both
password authentication and publickey authentication. However, if a client runs SSH1, it only needs
to pass either authentication.
• Any authentication—The server requires the client to pass either of password authentication and
publickey authentication.