ssh - OpenSSH SSH client (remote login program)

Overview (SYNOPSIS)

ssh [-l login_name ] hostname | user@hostname [command ]

ssh -words [-afgknqstvxACNTX1246 ] [-b bind_address ] [-c cipher_spec ] [-e escape_char ] [-i identity_file ] [-l login_name ] [-m mac_spec ] [-o option ] [-p port ] [-F configfile ] [-L port host hostport ] -words [-R port host hostport ] [-D port ] hostname | user@hostname [command ]

Description (DESCRIPTION)

(SSH client) used to log the remote host and execute commands on a remote host. Its purpose is to replace the rsh rlogin and, at the same time over an insecure network, mutual distrust between the two hosts, providing encrypted , secure communication connection. X11 connections and arbitrary TCP / IP ports can be forwarded via this secure channel (forward).

When a user connect and login host hostname after, according to the version of the protocol used, the user must prove his / her identity to the remote host via one of the following methods:

The first edition of the SSH protocol

First, if the host issues a login command is already listed in the local remote host or /etc/ssh/shosts.equiv /etc/hosts.equiv file, the user name and the same at both ends, immediately allow the user to log in. The second there is .rhosts or .shosts If the remote host under the root directory of user (home directory) and in which there is a line that contains the user name on the client's name and client, the user is allowed to log in. in general, the server does not allow individual use this authentication method, because it is unsafe.

The second authentication method is the rhosts or hosts.equiv file combined with RSA-based host authentication. This means that if $ HOME / .rhosts $ HOME / .shosts /etc/hosts.equiv or /etc/ssh/shosts.equiv allowed to log on and if the server can verify the client's host key (host key) (see Sx file (fILE) section of the / etc / ssh / ssh_known_hosts and $ HOME / .ssh / known_hosts), the host allowed customers to log in. this authentication method closes . because the IP spoofing, DNS spoofing and routing spoofing security vulnerability caused by [the system administrator Note: in general nature /etc/hosts.equiv $ HOME / .rhosts and the rlogin / rsh protocol is not reliable, it is safe to they should be turned off.]

As a third authentication method, this supports the RSA-based authentication scheme relies on public key algorithms: cryptography encryption and decryption by different keys is completed, the decryption key can not be deduced by RSA encryption key is this kind of password system. each user creates a public / private key one pair for authentication server knows the user's public key, only the user knows his own private key. $ HOME / .ssh / authorized_keys file lists allow login (user ) public key. when users log in to start the program tells the server to which it is prepared to use key (public key) to do authentication server checks only key (public key) is licensed, if the license server to the user (actually, the user running before) issued test, encrypted with the public users of a random number. this random number can only be decrypted with the correct private key. then the user's client program with the private solving test numbers to prove his / her grasp private key, but do not need (the private key) exposed to the server.

It automates RSA authentication protocol. Users create his / her RSA key pair by running ssh-keygen1. Private key stored in the user's home directory $ HOME / .ssh / identity, whereas the public key is stored in $ HOME /. ssh / identity.pub subsequently, the user should copy to a remote server identity.pub as $ HOME / .ssh / authorized_keys to store his / her user root directory (authorized_keys corresponding to the conventional $ HOME / .rhosts file each line has only one key, although a line can be very long). users do not need a password to log in directly. RSA authentication than rhosts authentication security.

RAS certification is probably the most convenient usage authentication agent (authentication agent) a. See ssh-agent1 man page.

If these authentication methods fail, it prompts the user to enter a password (password), and then verify the password to the server to do. As the entire communication process is encrypted so that others can not obtain the password by listening to the network.

SSH Protocol version

When a user connects to a second protocol version, as similar to the authentication method is effective if used. PreferredAuthentications default content, the client attempts to connect in the connection of a host based authentication method; If this method fails to methods for using the public key certification; and finally, if it fails, then enter the keyboard, try the user password authentication.

The public-key method is similar to the one described authentication RAS and RAS or DSA algorithm allows the use of: the client using his private key ($ HOME / .ssh / id_dsa or $ HOME / .ssh / id_rsa) the session identifier Fu (session identifier) signature, then the result is sent to the server. the server checks whether the matching public key $ HOME / .ssh / authorized_keys, if the keys and signatures are correct, the access can proceed. from the shared session identifier the Diffie-Hellman value, only the client and the server did not know the value.

If public key authentication fails or is invalid, the encrypted password will be sent to the remote host to prove the user's identity.

In addition, support for host-based authentication or test response.

Protocol version provides an additional mechanism for enhanced confidentiality (data flow with 3DES, Blowfish, CAST128 Arcfour or encryption) and integrity (hmac-md5, hmac-sha1). Note that the first version of the protocol mechanism to ensure a complete lack of strong connection sex.

Login session and remote execution

After the server accepts the user's identity, that is, the server can execute a given command also allows users to log in and give him a normal shell. All communications and remote command or shell is automatically encrypted.

If the pseudo-terminal (pseudo-terminal) (normal login session) is assigned, the user may use the escape character to be mentioned later.

If there is no assigned pseudo-terminal, then the session is clear (transparent), the binary data can be reliably transmitted. On most systems, even if the terminal is assigned, the escape character to `` none '' may be transparent to let the session.

When the command or shell on the remote host out, that is the end of the session, and close all X11 and TCP / IP connections. Return code as the remote procedure returns a return code.

Escape character

If a pseudo-terminal enabled to support a set of functions through the escape character.

Alone tilde can ~~ sent out, as long as the back is not listed with the following characters, it can be directly sent out. Escape character must be connected to a line feed (NEWLINE) back, so that it has a particular meaning may be in the configuration file with EscapeChar command to change the escape character on the command line you can use the - E option changes.

Has supported the escape command (assuming that is the default `~ ') are:

~.: Disconnect
~ ^ Z: The ssh to background
~#: Lists forwarded connection (forwarded connection)
~&: When the waiting forwarded connection / X11 sessions, ssh in the background Log
~?: Displays a list of escape characters
~C: Open a command line (only for - L and - R options to increase port forwarding)
~R: Reconstruction request (rekeying) connection (only for the second edition SSH protocol, and other support)

X11 and TCP forwarding (forwarding)

If ForwardX11 variable is set to `` yes '' (see the face or - X- and - X described options), and the user is using X11 (set DISPLAY environment variable), and the display will be automatically connected to X11 form in this forwarded to the distal end: X11 program starts with any shell or command through the encrypted channel, connected to the real X server from the local machine user should manually set. the DISPLAY may be on the command line, you may be provided in the configuration file X11 forwarded connection.

Set DISPLAY value will point to the server, but the display resolution is greater than zero. This is natural, because creating a `` proxy '' X server on the server, the connection forwarded over an encrypted channel.

Will automatically be set on the server Xauthority data object is a:. SSH generate a random authorization cookie, stored in Xauthority server SSH check and make sure to forward connections carry this cookie, after opening the connection, replace it with the real. the cookie. the real authentication cookie will not be sent to the server (there will not be any cookie transmitted in clear text).

If ForwardAgent variable is set to `` yes '' (or see the face after - A and - A description of the option), and the user is using an authentication agent (authentication agent), and the proxy connection will be automatically forwarded to the remote host.

Both can be specified on the command line in the configuration file via an encrypted channel to forward any TCP / IP. Application of TCP / IP are turned, for example, and an electronic wallet secure connection, or through the firewall.

Server authentication

Automatic maintenance and checks an identity database that contains all identity data (success) visiting the host. The host key stored in the user's home directory $ HOME / .ssh / known_hosts file. In addition, SSH automatically checks the / etc / ssh / ssh_known_hosts inside known hosts. any new hosts are automatically added to the user file. If the identity of a host of changes, will be issued a warning and shut down its password authentication to prevent a Trojan horse to steal user passwords. another purpose of this mechanism is to prevent man in the middle attacks, such attacks might otherwise bypass the encryption system. StrictHostKeyChecking option to prevent those who log on to the host machine does not recognize or change the key of.

Command line options are:

-a: Prohibit the forwarding of the authentication agent connection.
-A: Forwards the authentication proxy allows the connection. This parameter can be set individually for each host in the configuration file.
Forwarding agents to be cautious. Some users can bypass file access permissions on the remote host (Because proxy UNIX domain socket), they can access the local agent through the forwarded connection. An attacker can not obtain key material from the agent, but they able to operate these keys, identity information is loaded into use on the proxy certified.
-b bind_address: On machines with multiple interfaces or alias addresses, the specified transmit-receive interface.
-c blowfish|3des|des: Select the encrypted session cryptography 3des is the default algorithm. 3des (Triple-des) made with a different encryption key three - decrypt - encrypt operation three times, is considered to be more reliable blowfish is a fast packet encryption (block cipher), very safe, and faster than 3des much faster. des supports only client, the purpose of old-fashioned and can not support the 3des the first version of the protocol interoperability. due to the weakness of its cryptographic algorithms, it is strongly recommended to avoid using.
-c cipher_spec: Further, for the second protocol version, where you can specify a set of comma-separated, arranged in order of priority cryptography. See Ciphers
-e ch|^ch|none: Pty session set the escape character (default character: `~ '). Escape character is only effective first line, behind the escape character followed by a point ('. ') Indicates the end connected with a control-Z represents a pending connection (Suspend) , with the escape character himself said output of this character. this character is set to `` none '' disables escape function, the session fully transparent.
-f: Requirements to retreat backstage before executing the command when it is ready to ask for a password or passphrase, but the user wants it in the background This option implies -.. The n- . Options recommended way to start X11 programs on a remote machine that is similar to the ssh -f host xterm command.
-g: Allow remote host local port forwarding.
-i identity_file: Specify a required RSA or DSA authentication identity (private key) file. The default file is the protocol of the first edition $ HOME / .ssh / identity and the protocol of the second edition of the $ HOME / .ssh / id_rsa and $ HOME / .ssh . / id_dsa file can also be specified in the configuration file for each individual host may be used simultaneously a plurality of identification documents -. I option (may also specify an identity document in the plurality of configuration files).
-I smartcard_device: Specifies the smart card (SmartCard) equipment parameter is a device file, it is possible to use a smart card communication, a smart card which stores a user's RSA private key.
-k: And Kerberos tickets prohibited forwarding AFS token. This parameter can be set individually for each host in the configuration file.
-l login_name: Specifies the user login to the remote host. This parameter can be set individually for each host in the configuration file.
-m mac_spec: Further, for the second protocol version, where you can specify a set of comma-separated, arranged in order of priority MAC (Message Authentication Code) algorithm (message authentication code). For more details, in MACs as a keyword query.
-n: Redirect the stdin to / dev / null (actually prevents read data from stdin). Will use this option to run in the background. It is common technique is to run remote X11 program. For example, SSH -n shadows.cs. hut.fi emacs will start on shadows.cs.hut.fi emacs, X11 and automatically forwarding an encrypted connection channels running in the background (if it requires a password or passphrase, this approach will not work;. Referring - F option.)
-N: Not execute remote commands for forwarding ports (protocol only second edition)
-o option: Here are some options may be, format and configuration file format as it is used to set options that no command-line switches.
-p port: Specified remote host port. This parameter can be set individually for each host in the configuration file.
-q: Quiet mode. Eliminate all warnings and diagnostic information.
-s: Activating a remote system requesting subsystem subsystem is a characteristic SSH2 protocols, could assist other applications (e.g. SFTP) is used as the SSH secure access subsystem is specified by a remote command.
-t: Force distribution may perform any pseudo-terminal full screen (screen-based) program on the remote machine, it is very useful, for example parallel to the menu service -. T option forces the distribution terminal, even without a local terminal.
-T: Prohibiting assignment pseudo-terminal.
-v: . For more redundant mode the print debug information about the operation is very useful when debugging connection, authentication, and configuration problems in parallel -. V option to increase the level of detail up to three redundant.
-x: X11 forwarding prohibited.
-X: Allows X11 forwarding. This parameter can be set individually for each host in the configuration file.
X11 forwarding should be used with caution. If users can bypass file access permissions on the remote host (according to the user's X authorization database), he can. An attacker could then take action by forwarding the connection to access the local X11 display, such as a keyboard monitor input and so on.
-C: Data compression is required (including stdin, stdout, stderr X11 and forwarding data and TCP / IP connection) compression algorithm as gzip (1), the first version of the protocol, the compression level `` level '' with CompressionLevel option control the compression technology is useful in connecting the modem line or other slow, but they may slow down on the high-speed network. this parameter can be set individually for each host in the configuration file. see compression option.
-F configfile: Specify a user-level configuration file. If you specify a configuration file on the command line, system-wide configuration file (/ etc / ssh / ssh_config) will be ignored. The default user-level configuration file is $ HOME / .ssh / config
-L port:host:hostport: Forwards the local machine (the client) to specify a port to the remote machine specified port. Works like this, and on the local machine is assigned a socket listening on port port, once you have this port, the connection is forwarded through a secure channel, and the remote host and host of hostport port forwarding can be specified to establish a connection port in the configuration file only root can forward privileged ports IPv6 address format with another explanation:... port / host / hostport
-R port:host:hostport: Forwards remote host (server) to a port terminal designated local machine specified port works like this, the remote host is assigned a socket listening on port port, once you have this port, the connection is through safe passage turned out, while the local host and host of hostport port to establish a connection can be specified in the configuration file the port forwarding only login to remote host can forward privileged ports with root IPv6 address format with another explanation:... port / host / hostport
-D harbor: Specify a local machine `` dynamic '' application port forwarding working principle is that, on the local machine is assigned a socket listening on port port, once you have this port, the connection is forwarded through a secure channel, Under the agreement the application can determine where to connect the remote host and currently supports SOCKS4 protocol, will act as a SOCKS4 server. only root can forward privileged ports. You can specify dynamic port forwarding in the configuration file.
-1: Forced to use only the first version of the agreement.
-2: Mandatory use of only the second edition of the protocol.
-4: Forced to use only IPv4 addresses.
-6: Forced to use only IPv6 addresses.

Profiles (CONFIGURATION FILES)

You can get more configuration profile data from a user-level and system-level configuration file. Configuration file format and contents see ssh_config5.

"Environment Variables (ENVIRONMENT)

Generally set the following environment variables:

DISPLAY: Environment variable DISPLAY indicate the position X11 server automatically sets this variable, variable points `` hostname:. Data n '' format, where hostname noted host running the shell, and n is an integer of 1 according to this data, the safety. path forwarding X11 connections. users generally do not need to take the initiative to set DISPLAY variable, otherwise it will lead to X11 connection insecure (and will cause the user to manually copy the required authorization cookie).
HOME: Set the user's home directory path.
LOGNAME: Equal to USER for the use of compatible systems of this variable.
MAIL: Set the path for the user's mailbox.
PATH: Set as the default PATH as compiled ssh as required when.
SSH_ASKPASS: If you need a passphrase (passphrase), as long as it is started on the terminal, it reads from the current terminal. If you do not connect the terminals, but set the DISPLAY and SSH_ASKPASS variables, run SSH_ASKPASS specified program, open an X11 window to read take passphrase. when called from .Xsession or similar script, this function is particularly useful. (Note that on some machines may need to redirect input to / dev / null to work.)
SSH_AUTH_SOCK: UNIX domain socket of a path identifier and a communication proxy.
SSH_CONNECTION: The client and server identify the connection variable contains four space-separated fields: client IP address, client port number, server IP address, server port number.
SSH_ORIGINAL_COMMAND: If the enforcement of a command, this variable will hold the initial command line. It can be used to obtain initial parameters.
SSH_TTY: Set associated with the current command shell or terminal name (path of the device). If the terminal session is not, this variable is not set.
TZ: If you start setting a background process (daemon) time zone, you set the time zone variable, it pointed out that the current time zone (that is to say, this variable will pass the background process new connections).
USER: Set to log the user name.

Further, if the environment allows users to change their data, but also $ HOME / .ssh / environment file, wherein the read data, add the environmental data area data line `` VARNAME = value '' in this format. Another see sshd_config5 of PermitUserEnvironment options.

File (FILES)

$HOME/.ssh/known_hosts: Record host key, recording a user logs onto, but no host / etc / ssh / ssh_known_hosts columns in. See sshd (8).
$HOME/.ssh/identity, $HOME/.ssh/id_dsa, $HOME/.ssh/id_rsa: Contains the user's identity information. They are the first edition of the protocol RSA, protocol of the second edition of the DSA, the protocol of the second edition of the RSA. These documents reveal sensitive information, the user should only be read, not allow other users access (read / write / execute). Note that if a private key file to allow other users to access, will ignore this file. You can specify a passphrase (passphrase) at the time of key generation, with this sensitive passphrase and 3DES encrypted files section.
$HOME/.ssh/identity.pub, $HOME/.ssh/id_dsa.pub, $HOME/.ssh/id_rsa.pub: Contains the public key for authentication (public part of identity saved in text format files). If the user wants to log these machines use RSA authentication protocol of the first edition, $ HOME / .ssh / identity.pub content should be added to all machines the $ HOME / .ssh / authorized_keys If the user want to use the second version of the agreement DSA RSA authentication login / these machines, $ HOME / .ssh / id_dsa.pub and $ HOME / .ssh / id_rsa.pub content should be added . to all machines $ HOME / .ssh / authorized_keys no sensitive data in these files, you can (but need not) let anyone read ssh will never automatically access these files, they are not indispensable;. only to users these files are provided as a convenience.
$HOME/.ssh/config: User-level configuration file. Ssh_config5 describes the file format and configuration options.
$HOME/.ssh/authorized_keys: Storage RSA / DSA public key, through which the user logs on the machine. Sshd (8) manual page describes the format of this file. The easiest .pub identity files and file formats as File content is not highly sensitive, it is recommended to make this only user read and write files, and deny other users access.
/etc/ssh/ssh_known_hosts: System-level list of known host key. The system administrator should be ready this document, the public needed to host saved in a file inside. This document should be read globally. File a public line, the format is (fields separated by spaces): system name, public key, an optional comment field if the same machine using multiple names, all names should be (separated by commas) file format listed in sshd (8).. Manual pages are described.
Login time, sshd (8) with a standardized system name (the name returned by the server) the client acknowledgment; other names need, because no verification key before converting the name of the user to provide the name will prevent operable name people deceive server host authentication.
/etc/ssh/ssh_config: System-wide configuration file. Ssh_config5 describes the file format and configuration options.
/etc/ssh/ssh_host_key, /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_rsa_key: These three files contain the private parts of the host keys, which are used RhostsRSAAuthentication and HostbasedAuthentication If you are using the first version of the protocol RhostsRSAAuthentication method, must be setuid root, since only root can read the host key. For the second agreement version HostbasedAuthentication method using ssh-keysign8 access host key. this eliminates the requirement for verifying the identity of setuid root. By default is not setuid root.
$HOME/.rhosts: The .rhosts file for authentication, which allows the host to list the login / user right. (Note that rlogin and rsh also use this file, resulting in the application of this document become unsafe) for each line in the file consists of a host name (with the name will return the name server), and the user name on the host, separated by a space. on some machines, if the user is located in the root directory NFS partition, this may require world-readable file, because sshd (8) reads as root it addition, the file must belong to the user, other people are not allowed to hold written permission. recommended for most machines access is that its users can read and write, and not let others access.
Note that installs sshd (8) by default, and therefore allowed . Before rhosts authentication, sshd (8) requires the successful RSA host authentication. If there is no / etc / ssh / ssh_known_hosts file storage client host key, key can be stored in $ HOME / .ssh / known_hosts simplest approach is to connect back to the client from the server using ssh;. this will automatically add host keys to the $ HOME / .ssh / known_hosts
$HOME/.shosts: Usage and .rhosts This file is exactly the same. Its purpose is allowed to do rhosts authentication while preventing rlogin or rsh (1) log in.
/etc/hosts.equiv: .rhosts authentication using this file. It contains the canonical host name, one per line (sshd (8) man page describes the complete format). If the file is found the name of the client, and the same user name of the client and server, is automatically allowed to log in. In addition, under normal circumstances requires RSA host authentication is successful. this file should only allow root write.
/etc/ssh/shosts.equiv: Usage and /etc/hosts.equiv This file is exactly the same. Login is allowed for, but does not allow rsh / rlogin time.
/etc/ssh/sshrc: When the user logs on, before running shell (or command), execute the commands in the file. See sshd (8) manual page.
$HOME/.ssh/rc: When the user logs on, before running shell (or command), execute the commands in the file. See sshd (8) manual page.
$HOME/.ssh/environment: Contains additional definition of environment variables, see the previous Sx ENVIRONMENT section.