The translation is temporarily closed for contributions due to maintenance, please come back later.
The translation was automatically locked due to following alerts: Could not merge the repository.
Zen

Source string Source string

496/10000 · 496

This translation is currently locked.

English Actions
The client interacts with the remote host over the encrypted connection.
====== Transport Layer indexterm:[SSH protocol,layers,transport layer] The primary role of the transport layer is to facilitate safe and secure communication between the two hosts at the time of authentication and during subsequent communication. The transport layer accomplishes this by handling the encryption and decryption of data, and by providing integrity protection of data packets as they are sent and received. The transport layer also provides compression, speeding the transfer of information.
Once an SSH client contacts a server, key information is exchanged so that the two systems can correctly construct the transport layer. The following steps occur during this exchange:
Keys are exchanged
The public key encryption algorithm is determined
The symmetric encryption algorithm is determined
The message authentication algorithm is determined
The hash algorithm is determined
During the key exchange, the server identifies itself to the client with a unique _host key_. If the client has never communicated with this particular server before, the server's host key is unknown to the client and it does not connect. OpenSSH notifies the user that the authenticity of the host cannot be established and prompts the user to accept or reject it. The user is expected to independently verify the new host key before accepting it. In subsequent connections, the server's host key is checked against the saved version on the client, providing confidence that the client is indeed communicating with the intended server. If, in the future, the host key no longer matches, the user must remove the client's saved version before a connection can occur.
Always verify the integrity of a new SSH server
It is possible for an attacker to masquerade as an SSH server during the initial contact since the local system does not know the difference between the intended server and a false one set up by an attacker. To help prevent this, verify the integrity of a new SSH server by contacting the server administrator before connecting for the first time or in the event of a host key mismatch.
SSH is designed to work with almost any kind of public key algorithm or encoding format. After an initial key exchange creates a hash value used for exchanges and a shared secret value, the two systems immediately begin calculating new keys and algorithms to protect authentication and future data sent over the connection.
After a certain amount of data has been transmitted using a given key and algorithm (the exact amount depends on the SSH implementation), another key exchange occurs, generating another set of hash values and a new shared secret value. Even if an attacker is able to determine the hash and shared secret value, this information is only useful for a limited period of time.
====== Authentication indexterm:[SSH protocol,authentication] Once the transport layer has constructed a secure tunnel to pass information between the two systems, the server tells the client the different authentication methods supported, such as using a private key-encoded signature or typing a password. The client then tries to authenticate itself to the server using one of these supported methods.
SSH servers and clients can be configured to allow different types of authentication, which gives each side the optimal amount of control. The server can decide which encryption methods it supports based on its security model, and the client can choose the order of authentication methods to attempt from the available options.
====== Channels indexterm:[SSH protocol,layers,channels] After a successful authentication over the SSH transport layer, multiple channels are opened via a technique called _multiplexing_pass:attributes[{blank}]footnote:[A multiplexed connection consists of several signals being sent over a shared, common medium. With SSH, different channels are sent over a common secure connection.]. Each of these channels handles communication for different terminal sessions and for forwarded X11 sessions.
Both clients and servers can create a new channel. Each channel is then assigned a different number on each end of the connection. When the client attempts to open a new channel, the clients sends the channel number along with the request. This information is stored by the server and is used to direct communication to that channel. This is done so that different types of sessions do not affect one another and so that when a given session ends, its channel can be closed without disrupting the primary SSH connection.
Channels also support _flow-control_, which allows them to send and receive data in an orderly fashion. In this way, data is not sent over the channel until the client receives a message that the channel is open.
The client and server negotiate the characteristics of each channel automatically, depending on the type of service the client requests and the way the user is connected to the network. This allows great flexibility in handling different types of remote connections without having to change the basic infrastructure of the protocol.
Configuring OpenSSH
In order to perform tasks described in this section, you must have superuser privileges. To obtain them, log in as `root` by typing:
[command]#su -#
Configuration Files
indexterm:[SSH protocol,configuration files] There are two different sets of configuration files: those for client programs (that is, [command]#ssh#, [command]#scp#, and [command]#sftp#), and those for the server (the [command]#sshd# daemon). indexterm:[SSH protocol,configuration files,system-wide configuration files]indexterm:[SSH protocol,configuration files,user-specific configuration files] System-wide SSH configuration information is stored in the `/etc/ssh/` directory as described in xref:OpenSSH.adoc#table-ssh-configuration-configs-system[System-wide configuration files]. User-specific SSH configuration information is stored in `~/.ssh/` within the user's home directory as described in xref:OpenSSH.adoc#table-ssh-configuration-configs-user[User-specific configuration files].
System-wide configuration files
|File|Description
|`/etc/ssh/moduli`|Contains Diffie-Hellman groups used for the Diffie-Hellman key exchange which is critical for constructing a secure transport layer. When keys are exchanged at the beginning of an SSH session, a shared, secret value is created which cannot be determined by either party alone. This value is then used to provide host authentication.
|`/etc/ssh/ssh_config`|The default SSH client configuration file. Note that it is overridden by `~/.ssh/config` if it exists.
|`/etc/ssh/sshd_config`|The configuration file for the [command]#sshd# daemon.
|`/etc/ssh/ssh_host_ecdsa_key`|The ECDSA private key used by the [command]#sshd# daemon.
|`/etc/ssh/ssh_host_ecdsa_key.pub`|The ECDSA public key used by the [command]#sshd# daemon.
|`/etc/ssh/ssh_host_key`|The RSA private key used by the [command]#sshd# daemon for version 1 of the SSH protocol.
|`/etc/ssh/ssh_host_key.pub`|The RSA public key used by the [command]#sshd# daemon for version 1 of the SSH protocol.
|`/etc/ssh/ssh_host_rsa_key`|The RSA private key used by the [command]#sshd# daemon for version 2 of the SSH protocol.
|`/etc/ssh/ssh_host_rsa_key.pub`|The RSA public key used by the [command]#sshd# daemon for version 2 of the SSH protocol.
|`/etc/pam.d/sshd`|The PAM configuration file for the [command]#sshd# daemon.
|`/etc/sysconfig/sshd`|Configuration file for the `sshd` service.
User-specific configuration files
|File|Description
|`~/.ssh/authorized_keys`|Holds a list of authorized public keys for servers. When the client connects to a server, the server authenticates the client by checking its signed public key stored within this file.
|`~/.ssh/id_ecdsa`|Contains the ECDSA private key of the user.
|`~/.ssh/id_ecdsa.pub`|The ECDSA public key of the user.
|`~/.ssh/id_rsa`|The RSA private key used by [command]#ssh# for version 2 of the SSH protocol.
|`~/.ssh/id_rsa.pub`|The RSA public key used by [command]#ssh# for version 2 of the SSH protocol.
|`~/.ssh/identity`|The RSA private key used by [command]#ssh# for version 1 of the SSH protocol.
|`~/.ssh/identity.pub`|The RSA public key used by [command]#ssh# for version 1 of the SSH protocol.
|`~/.ssh/known_hosts`|Contains host keys of SSH servers accessed by the user. This file is very important for ensuring that the SSH client is connecting to the correct SSH server.
For information concerning various directives that can be used in the SSH configuration files, see the `ssh_config`(5) and `sshd_config`(5) manual pages.
Starting an OpenSSH Server
indexterm:[OpenSSH,server]

Loading…

User avatar None

Source string added
====== Channels indexterm:[SSH protocol,layers,channels] After a successful authentication over the SSH transport layer, multiple channels are opened via a technique called _multiplexing_pass:attributes[{blank}]footnote:[A multiplexed connection consists of several signals being sent over a shared, common medium. With SSH, different channels are sent over a common secure connection.]. Each of these channels handles communication for different terminal sessions and for forwarded X11 sessions.
4 years ago
Browse all string changes

Things to check

Long untranslated

The string has not been translated for a long time

Reset

Glossary

English English
No related strings found in the glossary.

String information

Source string description
type: Plain text
Flags
read-only
Source string location
./pages/infrastructure-services/OpenSSH.adoc:121
String age
4 years ago
Last updated
a year ago
Source string age
4 years ago
Translation file
pot/f26/pages/infrastructure-services/OpenSSH.pot, string 56