diff options
Diffstat (limited to 'usr/src/man/man1/ssh.1')
| -rw-r--r-- | usr/src/man/man1/ssh.1 | 1056 |
1 files changed, 1056 insertions, 0 deletions
diff --git a/usr/src/man/man1/ssh.1 b/usr/src/man/man1/ssh.1 new file mode 100644 index 0000000000..1bbf10cf95 --- /dev/null +++ b/usr/src/man/man1/ssh.1 @@ -0,0 +1,1056 @@ +'\" te +.\" To view license terms, attribution, and copyright for OpenSSH, the default path is /var/sadm/pkg/SUNWsshdr/install/copyright. If the Solaris operating environment has been installed anywhere other than the default, modify the specified path to access the file at +.\" the installed location. +.\" Portions Copyright (c) 2009, Sun Microsystems, Inc. All Rights Reserved. +.TH ssh 1 "20 May 2009" "SunOS 5.11" "User Commands" +.SH NAME +ssh \- secure shell client (remote login program) +.SH SYNOPSIS +.LP +.nf +\fBssh\fR [\fB-l\fR \fIlogin_name\fR] \fIhostname\fR | \fIuser@hostname\fR [ \fIcommand\fR] +.fi + +.LP +.nf +\fBssh\fR [\fB-afgknqstvxACNTX1246\fR] [\fB-b\fR \fIbind_address\fR] [\fB-m\fR \fImac_spec\fR] + [\fB-c\fR \fIcipher_spec\fR] [\fB-e\fR \fIescape_char\fR] [\fB-i\fR \fIidentity_file\fR] + [\fB-l\fR \fIlogin_name\fR] [\fB-F\fR \fIconfigfile\fR] [\fB-o\fR \fIoption\fR] [\fB-p\fR \fIport\fR] + [\fB-L\fR [\fIbind_address\fR\fB:\fR]\fIport\fR\fB:\fR\fIhost\fR\fB:\fR\fIhostport\fR] + [\fB-R\fR [\fIbind_address\fR\fB:\fR]\fIport\fR\fB:\fR\fIhost\fR\fB:\fR\fIhostport\fR] + [\fB-D\fR [\fIbind_address\fR\fB:\fR]\fIport\fR] \fIhostname\fR | \fIuser\fR\fB@\fR\fIhostname\fR [\fIcommand\fR] +.fi + +.SH DESCRIPTION +.sp +.LP +\fBssh\fR (Secure Shell) is a program for logging into a remote machine and for +executing commands on a remote machine. It is intended to replace \fBrlogin\fR +and \fBrsh\fR, and to provide secure encrypted communications between two +untrusted hosts over an insecure network. X11 connections and arbitrary TCP/IP +ports can also be forwarded over the secure channel. +.sp +.LP +\fBssh\fR connects and logs into the specified hostname. The user must prove +his or her identity to the remote machine using one of several methods +depending on the protocol version used: +.SS "SSH Protocol Version 1" +.sp +.LP +First, if the machine the user logs in from is listed in \fB/etc/hosts.equiv\fR +or \fB/etc/shosts.equiv\fR on the remote machine, and the user names are the +same on both sides, the user is immediately permitted to log in. Second, +if .\fBrhosts\fR or \fB\&.shosts\fR exists in the user's home directory on the +remote machine and contains a line containing the name of the client machine +and the name of the user on that machine, the user is permitted to log in. This +form of authentication alone is normally not allowed by the server because it +is not secure. +.sp +.LP +The second (and primary) authentication method is the \fBrhosts\fR or +\fBhosts.equiv\fR method combined with RSA-based host authentication. It means +that if the login would be permitted by \fB$HOME/.rhosts\fR, +\fB$HOME/.shosts\fR, \fB/etc/hosts.equiv\fR, or \fB/etc/shosts.equiv\fR, and if +additionally the server can verify the client's host key (see +\fB/etc/ssh_known_hosts\fR in the FILES section), only then is login permitted. +This authentication method closes security holes due to \fBIP\fR spoofing, +\fBDNS\fR spoofing, and routing spoofing. +.sp +.LP +\fBNote to the administrator:\fR \fB/etc/hosts.equiv\fR, \fB$HOME/.rhosts\fR, +and the rlogin/rsh protocol in general, are inherently insecure and should be +disabled if security is desired. +.sp +.LP +As a third authentication method, \fBssh\fR supports \fBRSA\fR-based +authentication. The scheme is based on public-key cryptography. There are +cryptosystems where encryption and decryption are done using separate keys, and +it is not possible to derive the decryption key from the encryption key. +\fBRSA\fR is one such system. 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. The file +\fB$HOME/.ssh/authorized_keys\fR lists the public keys that are permitted for +logging in. When the user logs in, the \fBssh\fR program tells the server which +key pair it would like to use for authentication. The server checks if this key +is permitted, and if so, sends the user (actually the \fBssh\fR program running +on behalf of the user) a challenge in the form of a random number, encrypted by +the user's public key. The challenge can only be decrypted using the proper +private key. The user's client then decrypts the challenge using the private +key, proving that he or she knows the private key but without disclosing it to +the server. +.sp +.LP +\fBssh\fR implements the \fBRSA\fR authentication protocol automatically. The +user creates his or her \fBRSA\fR key pair by running \fBssh-keygen\fR(1). This +stores the private key in \fB$HOME/.ssh/identity\fR and the public key in +\fB$HOME/.ssh/identity.pub\fR in the user's home directory. The user should +then copy the \fBidentity.pub\fR to \fB$HOME/.ssh/authorized_keys\fR in his or +her home directory on the remote machine (the \fBauthorized_keys\fR file +corresponds to the conventional \fB$HOME/.rhosts\fR 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. \fBRSA\fR authentication is much more secure than +\fBrhosts\fR authentication. +.sp +.LP +The most convenient way to use \fBRSA\fR authentication can be with an +authentication agent. See \fBssh-agent\fR(1) for more information. +.sp +.LP +If other authentication methods fail, \fBssh\fR 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. +.SS "SSH Protocol Version 2" +.sp +.LP +The SSH version 2 protocol supports multiple user authentication methods, some +of which are similar to those available with the SSH protocol version 1. These +authentication mechanisms are negotiated by the client and server, with the +client trying methods in the order specified in the +\fBPreferredAuthentications\fR client configuration option. The server decides +when enough authentication methods have passed successfully so as to complete +the authentication phase of the protocol. +.sp +.LP +When a user connects by using protocol version 2, similar authentication +methods are available. Using the default values for +\fBPreferredAuthentications\fR, the client tries to authenticate first by using +the hostbased method. If this method fails, public key authentication is +attempted. Finally, if this method fails, keyboard-interactive and password +authentication are tried. +.sp +.LP +The public key method is similar to \fBRSA\fR authentication described in the +previous section and allows the \fBRSA\fR or \fBDSA\fR algorithm to be used: +The client uses his or her private key, \fB$HOME/.ssh/id_dsa\fR or +\fB$HOME/.ssh/id_rsa\fR, to sign the session identifier and sends the result to +the server. The server checks whether the matching public key is listed in +\fB$HOME/.ssh/authorized_keys\fR and grants access if both the key is found and +the signature is correct. The session identifier is derived from a shared +Diffie-Hellman value and is only known to the client and the server. +.sp +.LP +If public key authentication fails or is not available, a password can be sent +encrypted to the remote host for proving the user's identity, or an extended +prompt/reply protocol can be engaged. +.sp +.LP +Additionally, \fBssh\fR supports hostbased or challenge response +authentication. +.sp +.LP +Protocol 2 provides additional mechanisms for confidentiality (the traffic is +encrypted using 3DES, Blowfish, CAST128 or Arcfour) and integrity +(\fBhmac-sha1\fR, \fBhmac-md5\fR). Protocol 1 lacks a strong mechanism for +ensuring the integrity of the connection. +.SS "Login Session and Remote Execution" +.sp +.LP +When the user's identity has been accepted by the server, the server either +executes the specified 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 is automatically encrypted. +.sp +.LP +If a pseudo-terminal has been allocated (normal login session), the user can +use the escape characters noted below. If a pseudo-terminal has been allocated +(normal login session), the user can disconnect with \fB~.\fR, and suspend +\fBssh\fR with \fB~^Z\fR. All forwarded connections can be listed with +\fB~#\fR. If the session blocks waiting for forwarded X11 or TCP/IP connections +to terminate, \fBssh\fR can be backgrounded with \fB~&\fR, although this should +not be used while the user shell is active, as it can cause the shell to hang. +All available escapes can be listed with \fB~?\fR. +.sp +.LP +A single tilde character can be sent as \fB~~\fR, or by following the tilde +with a character other than those described above. The escape character must +always follow a newline to be interpreted as special. The escape character can +be changed in configuration files or on the command line. +.sp +.LP +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 "\fBnone\fR" also makes the session transparent even if a tty is used. +.sp +.LP +The session terminates when the command or shell on the remote machine exits +and all X11 and TCP/IP connections have been closed. The exit status of the +remote program is returned as the exit status of \fBssh\fR. +.SS "Escape Characters" +.sp +.LP +When a pseudo-terminal has been requested, \fBssh\fR supports a number of +functions through the use of an escape character. +.sp +.LP +A single tilde character can be sent as \fB~~\fR or by following the tilde with +a character other than those described below. The escape character must always +follow a newline to be interpreted as special. The escape character can be +changed in configuration files using the \fBEscapeChar\fR configuration +directive or on the command line by the \fB-e\fR option. +.sp +.LP +The supported escapes, assuming the default \fB~\fR, are: +.sp +.ne 2 +.mk +.na +\fB\fB~.\fR\fR +.ad +.RS 7n +.rt +Disconnect. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB~^Z\fR\fR +.ad +.RS 7n +.rt +Background \fBssh\fR. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB~#\fR\fR +.ad +.RS 7n +.rt +List forwarded connections. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB~&\fR\fR +.ad +.RS 7n +.rt +Background \fBssh\fR at logout when waiting for forwarded connection / X11 +sessions to terminate. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB~?\fR\fR +.ad +.RS 7n +.rt +Display a list of escape characters. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB~B\fR\fR +.ad +.RS 7n +.rt +Send a break to the remote system. Only useful for SSH protocol version 2 and +if the peer supports it. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB~C\fR\fR +.ad +.RS 7n +.rt +Open command line. Only useful for adding port forwardings using the \fB-L\fR +and \fB-R\fR options). +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB~R\fR\fR +.ad +.RS 7n +.rt +Request rekeying of the connection. Only useful for SSH protocol version 2 and +if the peer supports it. +.RE + +.SS "X11 and TCP Forwarding" +.sp +.LP +If the \fBForwardX11\fR variable is set to ``\fByes\fR'' (or, see the +description of the \fB-X\fR and \fB-x\fR options described later) and the user +is using X11 (the \fBDISPLAY\fR environment variable is set), the connection to +the X11 display is automatically forwarded to the remote side in such a way +that any X11 programs started from the shell (or command) goes through the +encrypted channel, and the connection to the real X server is made from the +local machine. The user should not manually set \fBDISPLAY\fR. Forwarding of +X11 connections can be configured on the command line or in configuration +files. +.sp +.LP +The \fBDISPLAY\fR value set by \fBssh\fR points to the server machine, but with +a display number greater than zero. This is normal behavior, because \fBssh\fR +creates a "proxy" X11 server on the server machine for forwarding the +connections over the encrypted channel. +.sp +.LP +\fBssh\fR also automatically sets up \fBXauthority\fR data on the server +machine. For this purpose, it generates a random authorization cookie, store it +in \fBXauthority\fR on the server, and verify that any forwarded connections +carry this cookie and replace it by the real cookie when the connection is +opened. The real authentication cookie is never sent to the server machine (and +no cookies are sent in the plain). +.sp +.LP +If the \fBForwardAgent\fR variable is set to "\fByes\fR" (or, see the +description of the \fB-A\fR and \fB-a\fR options described later) and the user +is using an authentication agent, the connection to the agent is automatically +forwarded to the remote side. +.sp +.LP +Forwarding of arbitrary TCP/IP connections over the secure channel can be +specified either on the command line or in a configuration file. One possible +application of TCP/IP forwarding is a secure connection to an electronic purse. +Another possible application is firewall traversal. +.SS "Server Authentication" +.sp +.LP +\fBssh\fR automatically maintains and checks a database containing +identifications for all hosts it has ever been used with. Host keys are stored +in \fB$HOME/.ssh/known_hosts\fR in the user's home directory. Additionally, the +file \fB/etc/ssh_known_hosts\fR is automatically checked for known hosts. The +behavior of \fBssh\fR with respect to unknown host keys is controlled by the +\fBStrictHostKeyChecking\fR parameter. If a host's identification ever changes, +\fBssh\fR warns about this and disables password authentication to prevent a +trojan horse from getting the user's password. Another purpose of this +mechanism is to prevent attacks by intermediaries which could otherwise be used +to circumvent the encryption. The \fBStrictHostKeyChecking\fR option can be +used to prevent logins to machines whose host key is not known or has changed. +.sp +.LP +However, when using key exchange protected by GSS-API, the server can advertise +a host key. The client automatically adds this host key to its known hosts +file, \fB$HOME/.ssh/known_hosts\fR, regardless of the setting of the +\fBStrictHostKeyChecking\fR option, unless the advertised host key collides +with an existing known hosts entry. +.sp +.LP +When the user's GSS-API credentials expire, the client continues to be able to +rekey the session using the server's public host key to protect the key +exchanges. +.SS "GSS-API User and Server Authentication" +.sp +.LP +\fBssh\fR uses the user's GSS-API credentials to authenticate the client to the +server wherever possible, if \fBGssKeyEx\fR and/or \fBGssAuthentication\fR are +set. +.sp +.LP +With \fBGssKeyEx\fR, one can have an SSHv2 server that has no host public keys, +so that only \fBGssKeyEx\fR can be used. With such servers, rekeying fails if +the client's credentials are expired. +.sp +.LP +GSS-API user authentication has the disadvantage that it does not obviate the +need for SSH host keys, but its failure does not impact rekeying. \fBssh\fR can +try other authentication methods (such as public key, password, and so on) if +GSS-API authentication fails. +.sp +.LP +Delegation of GSS-API credentials can be quite useful, but is not without +danger. As with passwords, users should not delegate GSS credentials to +untrusted servers, since a compromised server can use a user's delegated GSS +credentials to impersonate the user. +.sp +.LP +GSS-API user authorization is covered in \fBgss_auth_rules\fR(5). +.sp +.LP +Rekeying can be used to redelegate credentials when \fBGssKeyEx\fR is +"\fByes\fR". (See \fB~R\fR under \fBEscape Characters\fR above.) +.SH OPTIONS +.sp +.LP +The following options are supported: +.sp +.ne 2 +.mk +.na +\fB\fB-1\fR\fR +.ad +.sp .6 +.RS 4n +Forces \fBssh\fR to try protocol version 1 only. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB-2\fR\fR +.ad +.sp .6 +.RS 4n +Forces \fBssh\fR to try protocol version 2 only. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB-4\fR\fR +.ad +.sp .6 +.RS 4n +Forces \fBssh\fR to use IPv4 addresses only. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB-6\fR\fR +.ad +.sp .6 +.RS 4n +Forces \fBssh\fR to use IPv6 addresses only. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB-a\fR\fR +.ad +.sp .6 +.RS 4n +Disables forwarding of the authentication agent connection. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB-A\fR\fR +.ad +.sp .6 +.RS 4n +Enables forwarding of the authentication agent connection. This can also be +specified on a per-host basis in a configuration file. +.sp +Agent forwarding should be enabled with caution. Users with the ability to +bypass file permissions on the remote host (for the agent's UNIX-domain socket) +can access the local agent through the forwarded connection. An attacker cannot +obtain key material from the agent. However, the attacker can perform +operations on the keys that enable the attacker to authenticate using the +identities loaded into the agent. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB-b\fR \fIbind_address\fR\fR +.ad +.sp .6 +.RS 4n +Specifies the interface to transmit from on machines with multiple interfaces +or aliased addresses. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB-c\fR \fIcipher_spec\fR\fR +.ad +.sp .6 +.RS 4n +Selects the cipher specification for encrypting the session. +.sp +For protocol version 1, \fIcipher_spec\fR is a single cipher. See the +\fBCipher\fR option in \fBssh_config\fR(4) for more information. +.sp +For protocol version 2, \fIcipher_spec\fR is a comma-separated list of ciphers +listed in order of preference. See the \fICiphers\fR option in +\fBssh_config\fR(4) for more information. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB-C\fR\fR +.ad +.sp .6 +.RS 4n +Requests compression of all data (including stdin, stdout, stderr, and data for +forwarded X11 and TCP/IP connections). The compression algorithm is the same +used by \fBgzip\fR(1). The \fBgzip\fR man page is available in the +\fBSUNWsfman\fR package. The "level" can be controlled by the +\fBCompressionLevel\fR option (see \fBssh_config\fR(4)). Compression is +desirable on modem lines and other slow connections, but only slows down things +on fast networks. The default value can be set on a host-by-host basis in the +configuration files. See the \fBCompression\fR option in \fBssh_config\fR(4). +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB-D\fR [\fIbind_address\fR\fB:\fR]\fIport\fR\fR +.ad +.sp .6 +.RS 4n +Specifies a local \fBdynamic\fR application-level port forwarding. This works +by allocating a socket to listen to port on the local side, optionally bound to +the specified \fIbind_address\fR. Whenever a connection is made to this port, +the connection is forwarded over the secure channel. The application protocol +is then used to determine where to connect to from the remote machine. +Currently, the \fBSOCKS4\fR and \fBSOCKS5\fR protocols are supported and +\fBssh\fR acts as a SOCKS server. Only a user with enough privileges can +forward privileged ports. Dynamic port forwardings can also be specified in the +configuration file. +.sp +IPv6 addresses can be specified with an alternative syntax: +\fB[\fR\fIbind_address\fR\fB/]\fR\fIport\fR or by enclosing the address in +square brackets. By default, the local port is bound in accordance with the +\fBGatewayPorts\fR setting. However, an explicit \fIbind_address\fR can be used +to bind the connection to a specific address. The \fIbind_address\fR of +\fBlocalhost\fR indicates that the listening port be bound for local use only, +while an empty address or \fB*\fR indicates that the port should be available +from all interfaces. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB-e\fR \fIch\fR | ^\fIch\fR | none\fR +.ad +.sp .6 +.RS 4n +Sets the escape character for sessions with a pty (default: `\fB~\fR'). The +escape character is only recognized at the beginning of a line. The escape +character followed by a dot (\fB\&.\fR) closes the connection. If followed by +CTRL-z, the escape character suspends the connection. If followed by itself, +the escape character sends itself once. Setting the character to \fBnone\fR +disables any escapes and makes the session fully transparent. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB-f\fR\fR +.ad +.sp .6 +.RS 4n +Requests \fBssh\fR to go to background just before command execution. This is +useful if \fBssh\fR is going to ask for passwords or passphrases, but the user +wants it in the background. This implies the \fB-n\fR option. The recommended +way to start X11 programs at a remote site is with something like \fBssh\fR +\fB-f\fR \fIhost\fR \fIxterm\fR. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB-F\fR \fIconfigfile\fR\fR +.ad +.sp .6 +.RS 4n +Specifies an alternative per-user configuration file. If a configuration file +is specified on the command line, the system-wide configuration file, +\fB/etc/ssh_config\fR, is ignored. The default for the per-user configuration +file is \fB$HOME/.ssh/config\fR. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB-g\fR\fR +.ad +.sp .6 +.RS 4n +Allows remote hosts to connect to local forwarded ports. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB-i\fR \fIidentity_file\fR\fR +.ad +.sp .6 +.RS 4n +Selects a file from which the identity (private key) for \fBRSA\fR or \fBDSA\fR +authentication is read. The default is \fB$HOME/.ssh/identity\fR for protocol +version 1, and \fB$HOME/.ssh/id_rsa\fR and \fB$HOME/.ssh/id_dsa\fR for protocol +version 2. Identity files can also be specified on a per-host basis in the +configuration file. It is possible to have multiple \fB-i\fR options (and +multiple identities specified in configuration files). +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB-l\fR \fIlogin_name\fR\fR +.ad +.sp .6 +.RS 4n +Specifies the user to log in as on the remote machine. This also can be +specified on a per-host basis in the configuration file. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB-L\fR [\fIbind_address:\fR]\fIport\fR:\fIhost\fR:\fIhostport\fR\fR +.ad +.sp .6 +.RS 4n +Specifies that the specified port on the local (client) host is to be forwarded +to the specified host and port on the remote side. This works by allocating a +socket to listen to the port on the local side, optionally bound to the +specified \fIbind_address\fR. Then, whenever a connection is made to this port, +the connection is forwarded over the secure channel and a connection is made to +host port \fIhostport\fR from the remote machine. Port forwardings can also be +specified in the configuration file. Only a user with enough privileges can +forward privileged ports. IPv6 addresses can be specified with an alternative +syntax: \fB[\fR\fIbind_address\fR\fB/]\fR\fIport\fR\fB/\fR\fIhost\fR\fB/\fR\fIh +ostport\fR or by enclosing the address in square brackets. +.sp +By default, the local port is bound in accordance with the \fBGatewayPorts\fR +setting. However, an explicit \fIbind_address\fR can be used to bind the +connection to a specific address. The \fIbind_address\fR of \fBlocalhost\fR +indicates that the listening port be bound for local use only, while an empty +address or \fB*\fR indicates that the port should be available from all +interfaces. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB-m\fR \fImac_spec\fR\fR +.ad +.sp .6 +.RS 4n +Additionally, for protocol version 2 a comma-separated list of \fBMAC\fR +(message authentication code) algorithms can be specified in order of +preference. See the MACs keyword for more information. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB-n\fR\fR +.ad +.sp .6 +.RS 4n +Redirects \fBstdin\fR from \fB/dev/null\fR (actually, prevents reading from +\fBstdin\fR). This must be used when \fBssh\fR is run in the background. A +common trick is to use this to run X11 programs on a remote machine. For +example, +.sp +.in +2 +.nf +ssh -n shadows.cs.hut.fi emacs & +.fi +.in -2 +.sp + +starts an \fBemacs\fR on \fBshadows.cs.hut.fi\fR, and the X11 connection is +automatically forwarded over an encrypted channel. The \fBssh\fR program is put +in the background. This does not work if \fBssh\fR needs to ask for a password +or passphrase. See also the \fB-f\fR option. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB-N\fR\fR +.ad +.sp .6 +.RS 4n +Does not execute a remote command. This is useful if you just want to forward +ports (protocol version 2 only). +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB-o\fR \fIoption\fR\fR +.ad +.sp .6 +.RS 4n +Can be used to give options in the format used in the configuration file. This +is useful for specifying options for which there is no separate command-line +flag. The option has the same format as a line in the configuration file. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB-p\fR \fIport\fR\fR +.ad +.sp .6 +.RS 4n +Specifies the port to connect to on the remote host. This can be specified on a +per-host basis in the configuration file. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB-P\fR\fR +.ad +.sp .6 +.RS 4n +Obsoleted option. SSHv1 connections from privileged ports are not supported. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB-q\fR\fR +.ad +.sp .6 +.RS 4n +Quiet mode. Causes all warning and diagnostic messages to be suppressed. Only +fatal errors are displayed. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB-R\fR [\fIbind_address\fR:]\fIport\fR:\fIhost\fR:\fIhostport\fR\fR +.ad +.sp .6 +.RS 4n +Specifies that the specified port on the remote (server) host is to be +forwarded to the specified host and port on the local side. This works by +allocating a socket to listen to the port on the remote side. Then, whenever a +connection is made to this port, the connection is forwarded over the secure +channel and a connection is made to host port \fIhostport\fR from the local +machine. Port forwardings can also be specified in the configuration file. +Privileged ports can be forwarded only when logging in on the remote machine as +a user with enough privileges. +.sp +IPv6 addresses can be specified by enclosing the address in square braces or +using an alternative syntax: \fB[\fR\fIbind_address\fR\fB/]\fR\fIhost\fR\fB/\fR +\fIport\fR\fB/\fR\fIhostport\fR. +.sp +By default, the listening socket on the server is bound to the loopback +interface only. This can be overridden by specifying a \fIbind_address\fR. An +empty \fIbind_address\fR, or the address \fB*\fR, indicates that the remote +socket should listen on all interfaces. Specifying a remote \fIbind_address\fR +only succeeds if the server's \fBGatewayPorts\fR option is enabled. See +\fBsshd_config\fR(4). +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB-s\fR\fR +.ad +.sp .6 +.RS 4n +Can be used to request invocation of a subsystem on the remote system. +Subsystems are a feature of the SSH2 protocol which facilitate the use of SSH +as a secure transport for other applications, for example, \fBsftp\fR. The +subsystem is specified as the remote command. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB-t\fR\fR +.ad +.sp .6 +.RS 4n +Forces pseudo-tty allocation. This can be used to execute arbitrary +screen-based programs on a remote machine, which can be very useful, for +example, when implementing menu services. Multiple \fB-t\fR options force +allocation, even if \fBssh\fR has no local \fBtty\fR. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB-T\fR\fR +.ad +.sp .6 +.RS 4n +Disables pseudo-tty allocation (protocol version 2 only). +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB-v\fR\fR +.ad +.sp .6 +.RS 4n +Verbose mode. Causes \fBssh\fR to print debugging messages about its progress. +This is helpful in debugging connection, authentication, and configuration +problems. Multiple \fB-v\fR options increase the verbosity. Maximum is 3. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB-x\fR\fR +.ad +.sp .6 +.RS 4n +Disables X11 forwarding. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB-X\fR\fR +.ad +.sp .6 +.RS 4n +Enables X11 forwarding. This can also be specified on a per-host basis in a +configuration file. +.sp +X11 forwarding should be enabled with caution. Users with the ability to bypass +file permissions on the remote host (for the user's X authorization database) +can access the local X11 display through the forwarded connection. An attacker +can then be able to perform activities such as keystroke monitoring. +.sp +For this reason, X11 forwarding might be subjected to X11 SECURITY extension +restrictions. Refer to the \fBForwardX11Trusted\fR directive in +\fBssh_config\fR(4) for more information. +.sp +If X11 forwarding is enabled, remote X11 clients is trusted by default. This +means that they have full access to the original X11 display. +.RE + +.SH ENVIRONMENT VARIABLES +.sp +.LP +\fBssh\fR normally sets the following environment variables: +.sp +.ne 2 +.mk +.na +\fB\fBDISPLAY\fR\fR +.ad +.sp .6 +.RS 4n +The \fBDISPLAY\fR variable must be set for X11 display forwarding to work. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fBSSH_ASKPASS\fR\fR +.ad +.sp .6 +.RS 4n +If \fBssh\fR needs a passphrase, it reads the passphrase from the current +terminal if it was run from a terminal. If \fBssh\fR does not have a terminal +associated with it but \fBDISPLAY\fR and \fBSSH_ASKPASS\fR are set, it executes +the program specified by \fBSSH_ASKPASS\fR and opens an X11 window to read the +passphrase. This is particularly useful when calling \fBssh\fR from a .Xsession +or related script. On some machines it might be necessary to redirect the input +from \fB/dev/null\fR to make this work. The system is shipped with +\fB/usr/lib/ssh/ssh-askpass\fR which is the default value for \fBSSH_ASKPASS\fR +.RE + +.sp +.ne 2 +.mk +.na +\fB\fBSSH_AUTH_SOCK\fR\fR +.ad +.sp .6 +.RS 4n +Indicates the path of a unix-domain socket used to communicate with the agent. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fBSSH_LANGS\fR\fR +.ad +.sp .6 +.RS 4n +A comma-separated list of IETF language tags (see RFC3066) indicating the +languages that the user can read and write. Used for negotiation of the locale +on the server. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fBLANG\fR, \fBLC_ALL\fR, \fBLC_COLLATE\fR, \fBLC_CTYPE\fR,\fR +.ad +.br +.na +\fB\fBLC_MESSAGES\fR, \fBLC_MONETARY\fR, \fBLC_NUMERIC\fR, \fBLC_TIME\fR\fR +.ad +.sp .6 +.RS 4n +The values of these environment variables can be set in remote sessions +according to the locale settings on the client side and availability of support +for those locales on the server side. Environment Variable Passing (see \fIRFC +4254\fR) is used for passing them over to the server side. +.RE + +.sp +.LP +See the \fBENVIRONMENT VARIABLES\fR section in the \fBsshd\fR(1M) man page for +more information on how locale setting can be further changed depending on +server side configuration. +.SH EXIT STATUS +.sp +.LP +The status of the remote program is returned as the exit status of \fBssh\fR. +\fB255\fR is returned if an error occurred at anytime during the \fBssh\fR +connection, including the initial key exchange. +.SH FILES +.sp +.ne 2 +.mk +.na +\fB\fB$HOME/.ssh/known_hosts\fR\fR +.ad +.RS 26n +.rt +Records host keys for all hosts the user has logged into that are not in +\fB/etc/ssh/ssh_known_hosts\fR. See \fBsshd\fR(1M). +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB$HOME/.ssh/identity\fR\fR +.ad +.br +.na +\fB\fB$HOME/.ssh/id_dsa\fR\fR +.ad +.br +.na +\fB\fB$HOME/.ssh/id_ssa\fR\fR +.ad +.RS 26n +.rt +Contains the authentication identity of the user. These files are for protocol +1 \fBRSA\fR, protocol 2 \fBDSA\fR, and protocol 2 \fBRSA\fR, respectively. +These files contain sensitive data and should be readable by the user but not +accessible by others (read/write/execute). \fBssh\fR ignores a private key file +if it is accessible by others. It is possible to specify a passphrase when +generating the key. The passphrase is used to encrypt the sensitive part of +this file using \fB3DES\fR. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB/etc/ssh/sshrc\fR\fR +.ad +.RS 26n +.rt +Commands in this file are executed by \fBssh\fR when the user logs in just +before the user's shell or command is started. See \fBsshd\fR(1M) for more +information. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB$HOME/.ssh/rc\fR\fR +.ad +.RS 26n +.rt +Commands in this file are executed by \fBssh\fR when the user logs in just +before the user's shell or command is started. See \fBsshd\fR(1M) for more +information. +.RE + +.sp +.ne 2 +.mk +.na +\fB\fB$HOME/.ssh/environment\fR\fR +.ad +.RS 26n +.rt +Contains additional definitions for environment variables. See ENVIRONMENT +VARIABLES. +.RE + +.SH ATTRIBUTES +.sp +.LP +See \fBattributes\fR(5) for descriptions of the following attributes: +.sp + +.sp +.TS +tab() box; +cw(2.75i) |cw(2.75i) +lw(2.75i) |lw(2.75i) +. +ATTRIBUTE TYPEATTRIBUTE VALUE +_ +Interface StabilitySee below. +.TE + +.sp +.LP +The command line syntax is Committed. The remote locale selection through +passing \fBLC_*\fR environment variables is Uncommitted. +.SH SEE ALSO +.sp +.LP +\fBrlogin\fR(1), \fBrsh\fR(1), \fBscp\fR(1), \fBssh-add\fR(1), +\fBssh-agent\fR(1), \fBssh-keygen\fR(1), \fBssh-http-proxy-connect\fR(1), +\fBssh-socks5-proxy-connect\fR(1), \fBtelnet\fR(1), \fBsshd\fR(1M), +\fBssh_config\fR(4), \fBsshd_config\fR(4), \fBattributes\fR(5), +\fBgss_auth_rules\fR(5), \fBkerberos\fR(5), \fBprivileges\fR(5) +.sp +.LP +\fIRFC 1928\fR +.sp +.LP +\fIRFC 4254\fR |