X-Git-Url: http://andersk.mit.edu/gitweb/gssapi-openssh.git/blobdiff_plain/f5799ae11d9a6d85b68449a35cd4077ae9090357..b5afdff53b51d529e596da3b4c2aa5ee14cc8b08:/openssh/ssh.1 diff --git a/openssh/ssh.1 b/openssh/ssh.1 index 8ada41f..6c6271e 100644 --- a/openssh/ssh.1 +++ b/openssh/ssh.1 @@ -34,8 +34,8 @@ .\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF .\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. .\" -.\" $OpenBSD: ssh.1,v 1.158 2002/06/20 19:56:07 stevesk Exp $ -.Dd September 25, 1999 +.\" $OpenBSD: ssh.1,v 1.283 2009/03/19 15:15:09 jmc Exp $ +.Dd $Mdocdate: March 19 2009 $ .Dt SSH 1 .Os .Sh NAME @@ -43,369 +43,138 @@ .Nd OpenSSH SSH client (remote login program) .Sh SYNOPSIS .Nm ssh -.Op Fl l Ar login_name -.Ar hostname | user@hostname -.Op Ar command -.Pp -.Nm ssh -.Op Fl afgknqstvxACNPTX1246 +.Op Fl 1246AaCfgKkMNnqsTtVvXxYy .Op Fl b Ar bind_address .Op Fl c Ar cipher_spec +.Oo Fl D\ \& +.Sm off +.Oo Ar bind_address : Oc +.Ar port +.Sm on +.Oc .Op Fl e Ar escape_char +.Op Fl F Ar configfile +.Bk -words .Op Fl i Ar identity_file +.Ek +.Oo Fl L\ \& +.Sm off +.Oo Ar bind_address : Oc +.Ar port : host : hostport +.Sm on +.Oc +.Bk -words .Op Fl l Ar login_name +.Ek .Op Fl m Ar mac_spec +.Op Fl O Ar ctl_cmd .Op Fl o Ar option .Op Fl p Ar port -.Op Fl F Ar configfile -.Oo Fl L Xo +.Oo Fl R\ \& .Sm off -.Ar port : -.Ar host : -.Ar hostport +.Oo Ar bind_address : Oc +.Ar port : host : hostport .Sm on -.Xc .Oc -.Oo Fl R Xo -.Sm off -.Ar port : -.Ar host : -.Ar hostport -.Sm on -.Xc -.Oc -.Op Fl D Ar port -.Ar hostname | user@hostname +.Op Fl S Ar ctl_path +.Bk -words +.Oo Fl w Ar local_tun Ns +.Op : Ns Ar remote_tun Oc +.Oo Ar user Ns @ Oc Ns Ar hostname .Op Ar command +.Ek .Sh DESCRIPTION .Nm (SSH client) is a program for logging into a remote machine and for executing commands on a remote machine. -It is intended to replace -rlogin and rsh, and provide secure encrypted communications between +It is intended to replace rlogin and rsh, +and 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. +X11 connections and arbitrary TCP ports +can also be forwarded over the secure channel. .Pp .Nm connects and logs into the specified -.Ar hostname . +.Ar hostname +(with optional +.Ar user +name). The user must prove his/her identity to the remote machine using one of several methods -depending on the protocol version used: +depending on the protocol version used (see below). .Pp -.Ss SSH protocol version 1 -.Pp -First, if the machine the user logs in from is listed in -.Pa /etc/hosts.equiv -or -.Pa /etc/shosts.equiv -on the remote machine, and the user names are -the same on both sides, the user is immediately permitted to log in. -Second, if -.Pa \&.rhosts -or -.Pa \&.shosts -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. -.Pp -The second authentication method is the -.Pa rhosts -or -.Pa hosts.equiv -method combined with RSA-based host authentication. -It means that if the login would be permitted by -.Pa $HOME/.rhosts , -.Pa $HOME/.shosts , -.Pa /etc/hosts.equiv , -or -.Pa /etc/shosts.equiv , -and if additionally the server can verify the client's -host key (see -.Pa /etc/ssh/ssh_known_hosts -and -.Pa $HOME/.ssh/known_hosts -in the -.Sx FILES -section), only then login is permitted. -This authentication method closes security holes due to IP -spoofing, DNS spoofing and routing spoofing. -[Note to the administrator: -.Pa /etc/hosts.equiv , -.Pa $HOME/.rhosts , -and the rlogin/rsh protocol in general, are inherently insecure and should be -disabled if security is desired.] -.Pp -As a third authentication method, -.Nm -supports RSA 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. -RSA 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 -.Pa $HOME/.ssh/authorized_keys -lists the public keys that are permitted for logging -in. -When the user logs in, the -.Nm -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 -.Nm -program running on behalf of the user) a challenge, 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/she knows the private -key but without disclosing it to the server. -.Pp -.Nm -implements the RSA authentication protocol automatically. -The user creates his/her RSA key pair by running -.Xr ssh-keygen 1 . -This stores the private key in -.Pa $HOME/.ssh/identity -and the public key in -.Pa $HOME/.ssh/identity.pub -in the user's home directory. -The user should then copy the -.Pa identity.pub -to -.Pa $HOME/.ssh/authorized_keys -in his/her home directory on the remote machine (the -.Pa authorized_keys -file corresponds to the conventional -.Pa $HOME/.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. -RSA authentication is much -more secure than rhosts authentication. -.Pp -The most convenient way to use RSA authentication may be with an -authentication agent. -See -.Xr ssh-agent 1 -for more information. -.Pp -If other authentication methods fail, -.Nm -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. -.Pp -.Ss SSH protocol version 2 -.Pp -When a user connects using protocol version 2 -similar authentication methods are available. -Using the default values for -.Cm PreferredAuthentications , -the client will try to authenticate first using the hostbased method; -if this method fails public key authentication is attempted, -and finally if this method fails keyboard-interactive and -password authentication are tried. -.Pp -The public key method is similar to RSA authentication described -in the previous section and allows the RSA or DSA algorithm to be used: -The client uses his private key, -.Pa $HOME/.ssh/id_dsa -or -.Pa $HOME/.ssh/id_rsa , -to sign the session identifier and sends the result to the server. -The server checks whether the matching public key is listed in -.Pa $HOME/.ssh/authorized_keys -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. -.Pp -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. -.Pp -Additionally, -.Nm -supports hostbased or challenge response authentication. -.Pp -Protocol 2 provides additional mechanisms for confidentiality -(the traffic is encrypted using 3DES, Blowfish, CAST128 or Arcfour) -and integrity (hmac-md5, hmac-sha1). -Note that protocol 1 lacks a strong mechanism for ensuring the -integrity of the connection. -.Pp -.Ss Login session and remote execution -.Pp -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. -.Pp -If a pseudo-terminal has been allocated (normal login session), the -user may use the escape characters noted below. -.Pp -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 -.Dq none -will also make the session transparent even if a tty is used. -.Pp -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 -.Nm ssh . -.Pp -.Ss Escape Characters -.Pp -When a pseudo terminal has been requested, ssh supports a number of functions -through the use of an escape character. -.Pp -A single tilde character can be sent as -.Ic ~~ -or by following the tilde by 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 -.Cm EscapeChar -configuration directive or on the command line by the -.Fl e -option. +If +.Ar command +is specified, +it is executed on the remote host instead of a login shell. .Pp -The supported escapes (assuming the default -.Ql ~ ) -are: +The options are as follows: .Bl -tag -width Ds -.It Cm ~. -Disconnect -.It Cm ~^Z -Background ssh -.It Cm ~# -List forwarded connections -.It Cm ~& -Background ssh at logout when waiting for forwarded connection / X11 sessions -to terminate -.It Cm ~? -Display a list of escape characters -.It Cm ~C -Open command line (only useful for adding port forwardings using the -.Fl L -and -.Fl R -options) -.It Cm ~R -Request rekeying of the connection (only useful for SSH protocol version 2 -and if the peer supports it) -.El -.Pp -.Ss X11 and TCP forwarding -.Pp -If the -.Cm ForwardX11 -variable is set to -.Dq yes -(or, see the description of the -.Fl X -and -.Fl x -options described later) -and the user is using X11 (the -.Ev DISPLAY -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) will go through the -encrypted channel, and the connection to the real X server will be made -from the local machine. -The user should not manually set -.Ev DISPLAY . -Forwarding of X11 connections can be -configured on the command line or in configuration files. -.Pp -The -.Ev DISPLAY -value set by +.It Fl 1 +Forces .Nm -will point to the server machine, but with a display number greater -than zero. -This is normal, and happens because +to try protocol version 1 only. +.It Fl 2 +Forces .Nm -creates a -.Dq proxy -X server on the server machine for forwarding the -connections over the encrypted channel. -.Pp +to try protocol version 2 only. +.It Fl 4 +Forces .Nm -will also automatically set up Xauthority data on the server machine. -For this purpose, it will generate a random authorization cookie, -store it in Xauthority 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). -.Pp -If the user is using an authentication agent, the connection to the agent -is automatically forwarded to the remote side unless disabled on -the command line or in a configuration file. -.Pp -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 is going through firewalls. -.Pp -.Ss Server authentication -.Pp +to use IPv4 addresses only. +.It Fl 6 +Forces .Nm -automatically maintains and checks a database containing -identifications for all hosts it has ever been used with. -Host keys are stored in -.Pa $HOME/.ssh/known_hosts -in the user's home directory. -Additionally, the file -.Pa /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, -.Nm -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 man-in-the-middle attacks which could -otherwise be used to circumvent the encryption. -The -.Cm StrictHostKeyChecking -option can be used to prevent logins to machines whose -host key is not known or has changed. -.Pp -The options are as follows: -.Bl -tag -width Ds -.It Fl a -Disables forwarding of the authentication agent connection. +to use IPv6 addresses only. .It Fl A Enables forwarding of the authentication agent connection. This can also be specified on a per-host basis in a configuration file. +.Pp +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 they can perform operations on the keys that enable them to +authenticate using the identities loaded into the agent. +.It Fl a +Disables forwarding of the authentication agent connection. .It Fl b Ar bind_address -Specify the interface to transmit from on machines with multiple -interfaces or aliased addresses. -.It Fl c Ar blowfish|3des|des -Selects the cipher to use for encrypting the session. -.Ar 3des -is used by default. -It is believed to be secure. +Use +.Ar bind_address +on the local machine as the source address +of the connection. +Only useful on systems with more than one address. +.It Fl C +Requests compression of all data (including stdin, stdout, stderr, and +data for forwarded X11 and TCP connections). +The compression algorithm is the same used by +.Xr gzip 1 , +and the +.Dq level +can be controlled by the +.Cm CompressionLevel +option for protocol version 1. +Compression is desirable on modem lines and other +slow connections, but will only slow down things on fast networks. +The default value can be set on a host-by-host basis in the +configuration files; see the +.Cm Compression +option. +.It Fl c Ar cipher_spec +Selects the cipher specification for encrypting the session. +.Pp +Protocol version 1 allows specification of a single cipher. +The supported values are +.Dq 3des , +.Dq blowfish , +and +.Dq des . .Ar 3des (triple-des) is an encrypt-decrypt-encrypt triple with three different keys. +It is believed to be secure. .Ar blowfish -is a fast block cipher, it appears very secure and is much faster than +is a fast block cipher; it appears very secure and is much faster than .Ar 3des . .Ar des is only supported in the @@ -413,26 +182,84 @@ is only supported in the client for interoperability with legacy protocol 1 implementations that do not support the .Ar 3des -cipher. Its use is strongly discouraged due to cryptographic -weaknesses. -.It Fl c Ar cipher_spec -Additionally, for protocol version 2 a comma-separated list of ciphers can -be specified in order of preference. -See +cipher. +Its use is strongly discouraged due to cryptographic weaknesses. +The default is +.Dq 3des . +.Pp +For protocol version 2, +.Ar cipher_spec +is a comma-separated list of ciphers +listed in order of preference. +See the .Cm Ciphers -for more information. -.It Fl e Ar ch|^ch|none +keyword for more information. +.It Fl D Xo +.Sm off +.Oo Ar bind_address : Oc +.Ar port +.Sm on +.Xc +Specifies a local +.Dq dynamic +application-level port forwarding. +This works by allocating a socket to listen to +.Ar port +on the local side, optionally bound to the specified +.Ar bind_address . +Whenever a connection is made to this port, the +connection is forwarded over the secure channel, and the application +protocol is then used to determine where to connect to from the +remote machine. +Currently the SOCKS4 and SOCKS5 protocols are supported, and +.Nm +will act as a SOCKS server. +Only root can forward privileged ports. +Dynamic port forwardings can also be specified in the configuration file. +.Pp +IPv6 addresses can be specified with an alternative syntax: +.Sm off +.Xo +.Op Ar bind_address No / +.Ar port +.Xc +.Sm on +or by enclosing the address in square brackets. +Only the superuser can forward privileged ports. +By default, the local port is bound in accordance with the +.Cm GatewayPorts +setting. +However, an explicit +.Ar bind_address +may be used to bind the connection to a specific address. +The +.Ar bind_address +of +.Dq localhost +indicates that the listening port be bound for local use only, while an +empty address or +.Sq * +indicates that the port should be available from all interfaces. +.It Fl e Ar escape_char Sets the escape character for sessions with a pty (default: .Ql ~ ) . The escape character is only recognized at the beginning of a line. The escape character followed by a dot .Pq Ql \&. -closes the connection, followed -by control-Z suspends the connection, and followed by itself sends the -escape character once. +closes the connection; +followed by control-Z suspends the connection; +and followed by itself sends the escape character once. Setting the character to .Dq none disables any escapes and makes the session fully transparent. +.It Fl F Ar configfile +Specifies an alternative per-user configuration file. +If a configuration file is given on the command line, +the system-wide configuration file +.Pq Pa /etc/ssh/ssh_config +will be ignored. +The default for the per-user configuration file is +.Pa ~/.ssh/config . .It Fl f Requests .Nm @@ -446,17 +273,33 @@ This implies The recommended way to start X11 programs at a remote site is with something like .Ic ssh -f host xterm . +.Pp +If the +.Cm ExitOnForwardFailure +configuration option is set to +.Dq yes , +then a client started with +.Fl f +will wait for all remote port forwards to be successfully established +before placing itself in the background. .It Fl g Allows remote hosts to connect to local forwarded ports. +.It Fl I Ar smartcard_device +Specify the device +.Nm +should use to communicate with a smartcard used for storing the user's +private RSA key. +This option is only available if support for smartcard devices +is compiled in (default is no support). .It Fl i Ar identity_file Selects a file from which the identity (private key) for RSA or DSA authentication is read. The default is -.Pa $HOME/.ssh/identity +.Pa ~/.ssh/identity for protocol version 1, and -.Pa $HOME/.ssh/id_rsa +.Pa ~/.ssh/id_rsa and -.Pa $HOME/.ssh/id_dsa +.Pa ~/.ssh/id_dsa for protocol version 2. Identity files may also be specified on a per-host basis in the configuration file. @@ -464,18 +307,76 @@ It is possible to have multiple .Fl i options (and multiple identities specified in configuration files). -.It Fl I Ar smartcard_device -Specifies which smartcard device to use. The argument is -the device -.Nm -should use to communicate with a smartcard used for storing the user's -private RSA key. +.It Fl K +Enables GSSAPI-based authentication and forwarding (delegation) of GSSAPI +credentials to the server. .It Fl k -Disables forwarding of Kerberos tickets and AFS tokens. -This may also be specified on a per-host basis in the configuration file. +Disables forwarding (delegation) of GSSAPI credentials to the server. +.It Fl L Xo +.Sm off +.Oo Ar bind_address : Oc +.Ar port : host : hostport +.Sm on +.Xc +Specifies that the given port on the local (client) host is to be +forwarded to the given host and port on the remote side. +This works by allocating a socket to listen to +.Ar port +on the local side, optionally bound to the specified +.Ar bind_address . +Whenever a connection is made to this port, the +connection is forwarded over the secure channel, and a connection is +made to +.Ar host +port +.Ar hostport +from the remote machine. +Port forwardings can also be specified in the configuration file. +IPv6 addresses can be specified with an alternative syntax: +.Sm off +.Xo +.Op Ar bind_address No / +.Ar port No / Ar host No / +.Ar hostport +.Xc +.Sm on +or by enclosing the address in square brackets. +Only the superuser can forward privileged ports. +By default, the local port is bound in accordance with the +.Cm GatewayPorts +setting. +However, an explicit +.Ar bind_address +may be used to bind the connection to a specific address. +The +.Ar bind_address +of +.Dq localhost +indicates that the listening port be bound for local use only, while an +empty address or +.Sq * +indicates that the port should be available from all interfaces. .It Fl l Ar login_name Specifies the user to log in as on the remote machine. This also may be specified on a per-host basis in the configuration file. +.It Fl M +Places the +.Nm +client into +.Dq master +mode for connection sharing. +Multiple +.Fl M +options places +.Nm +into +.Dq master +mode with confirmation required before slave connections are accepted. +Refer to the description of +.Cm ControlMaster +in +.Xr ssh_config 5 +for details. .It Fl m Ar mac_spec Additionally, for protocol version 2 a comma-separated list of MAC (message authentication code) algorithms can @@ -483,6 +384,10 @@ be specified in order of preference. See the .Cm MACs keyword for more information. +.It Fl N +Do not execute a remote command. +This is useful for just forwarding ports +(protocol version 2 only). .It Fl n Redirects stdin from .Pa /dev/null @@ -503,46 +408,180 @@ program will be put in the background. needs to ask for a password or passphrase; see also the .Fl f option.) -.It Fl N -Do not execute a remote command. -This is useful for just forwarding ports -(protocol version 2 only). +.It Fl O Ar ctl_cmd +Control an active connection multiplexing master process. +When the +.Fl O +option is specified, the +.Ar ctl_cmd +argument is interpreted and passed to the master process. +Valid commands are: +.Dq check +(check that the master process is running) and +.Dq exit +(request the master to exit). .It Fl o Ar option 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. +For full details of the options listed below, and their possible values, see +.Xr ssh_config 5 . +.Pp +.Bl -tag -width Ds -offset indent -compact +.It AddressFamily +.It BatchMode +.It BindAddress +.It ChallengeResponseAuthentication +.It CheckHostIP +.It Cipher +.It Ciphers +.It ClearAllForwardings +.It Compression +.It CompressionLevel +.It ConnectionAttempts +.It ConnectTimeout +.It ControlMaster +.It ControlPath +.It DynamicForward +.It EscapeChar +.It ExitOnForwardFailure +.It ForwardAgent +.It ForwardX11 +.It ForwardX11Trusted +.It GatewayPorts +.It GlobalKnownHostsFile +.It GSSAPIAuthentication +.It GSSAPIDelegateCredentials +.It HashKnownHosts +.It Host +.It HostbasedAuthentication +.It HostKeyAlgorithms +.It HostKeyAlias +.It HostName +.It IdentityFile +.It IdentitiesOnly +.It KbdInteractiveDevices +.It LocalCommand +.It LocalForward +.It LogLevel +.It MACs +.It NoHostAuthenticationForLocalhost +.It NumberOfPasswordPrompts +.It PasswordAuthentication +.It PermitLocalCommand +.It Port +.It PreferredAuthentications +.It Protocol +.It ProxyCommand +.It PubkeyAuthentication +.It RekeyLimit +.It RemoteForward +.It RhostsRSAAuthentication +.It RSAAuthentication +.It SendEnv +.It ServerAliveInterval +.It ServerAliveCountMax +.It SmartcardDevice +.It StrictHostKeyChecking +.It TCPKeepAlive +.It Tunnel +.It TunnelDevice +.It UsePrivilegedPort +.It User +.It UserKnownHostsFile +.It VerifyHostKeyDNS +.It VisualHostKey +.It XAuthLocation +.El .It Fl p Ar port Port to connect to on the remote host. This can be specified on a per-host basis in the configuration file. -.It Fl P -Use a non-privileged port for outgoing connections. -This can be used if a firewall does -not permit connections from privileged ports. -Note that this option turns off -.Cm RhostsAuthentication -and -.Cm RhostsRSAAuthentication -for older servers. .It Fl q Quiet mode. -Causes all warning and diagnostic messages to be suppressed. +Causes most warning and diagnostic messages to be suppressed. +.It Fl R Xo +.Sm off +.Oo Ar bind_address : Oc +.Ar port : host : hostport +.Sm on +.Xc +Specifies that the given port on the remote (server) host is to be +forwarded to the given host and port on the local side. +This works by allocating a socket to listen to +.Ar port +on the remote side, and whenever a connection is made to this port, the +connection is forwarded over the secure channel, and a connection is +made to +.Ar host +port +.Ar hostport +from the local machine. +.Pp +Port forwardings can also be specified in the configuration file. +Privileged ports can be forwarded only when +logging in as root on the remote machine. +IPv6 addresses can be specified by enclosing the address in square braces or +using an alternative syntax: +.Sm off +.Xo +.Op Ar bind_address No / +.Ar host No / Ar port No / +.Ar hostport +.Xc . +.Sm on +.Pp +By default, the listening socket on the server will be bound to the loopback +interface only. +This may be overridden by specifying a +.Ar bind_address . +An empty +.Ar bind_address , +or the address +.Ql * , +indicates that the remote socket should listen on all interfaces. +Specifying a remote +.Ar bind_address +will only succeed if the server's +.Cm GatewayPorts +option is enabled (see +.Xr sshd_config 5 ) . +.Pp +If the +.Ar port +argument is +.Ql 0 , +the listen port will be dynamically allocated on the server and reported +to the client at run time. +.It Fl S Ar ctl_path +Specifies the location of a control socket for connection sharing. +Refer to the description of +.Cm ControlPath +and +.Cm ControlMaster +in +.Xr ssh_config 5 +for details. .It Fl s -May 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 (eg. sftp). The -subsystem is specified as the remote command. +May 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 (eg.\& +.Xr sftp 1 ) . +The subsystem is specified as the remote command. +.It Fl T +Disable pseudo-tty allocation. .It Fl t Force pseudo-tty allocation. This can be used to execute arbitrary screen-based programs on a remote machine, which can be very useful, -e.g., when implementing menu services. +e.g. when implementing menu services. Multiple .Fl t options force tty allocation, even if .Nm has no local tty. -.It Fl T -Disable pseudo-tty allocation. +.It Fl V +Display the version number and exit. .It Fl v Verbose mode. Causes @@ -552,111 +591,572 @@ This is helpful in debugging connection, authentication, and configuration problems. Multiple .Fl v -options increases the verbosity. -Maximum is 3. -.It Fl x -Disables X11 forwarding. +options increase the verbosity. +The maximum is 3. +.It Fl w Xo +.Ar local_tun Ns Op : Ns Ar remote_tun +.Xc +Requests +tunnel +device forwarding with the specified +.Xr tun 4 +devices between the client +.Pq Ar local_tun +and the server +.Pq Ar remote_tun . +.Pp +The devices may be specified by numerical ID or the keyword +.Dq any , +which uses the next available tunnel device. +If +.Ar remote_tun +is not specified, it defaults to +.Dq any . +See also the +.Cm Tunnel +and +.Cm TunnelDevice +directives in +.Xr ssh_config 5 . +If the +.Cm Tunnel +directive is unset, it is set to the default tunnel mode, which is +.Dq point-to-point . .It Fl X Enables X11 forwarding. This can also be specified on a per-host basis in a configuration file. -.It Fl C -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 -.Xr gzip 1 , -and the -.Dq level -can be controlled by the -.Cm CompressionLevel -option. -Compression is desirable on modem lines and other -slow connections, but will only slow down things on fast networks. -The default value can be set on a host-by-host basis in the -configuration files; see the -.Cm Compression -option. -.It Fl F Ar configfile -Specifies an alternative per-user configuration file. -If a configuration file is given on the command line, -the system-wide configuration file -.Pq Pa /etc/ssh/ssh_config -will be ignored. -The default for the per-user configuration file is -.Pa $HOME/.ssh/config . -.It Fl L Ar port:host:hostport -Specifies that the given port on the local (client) host is to be -forwarded to the given host and port on the remote side. -This works by allocating a socket to listen to -.Ar port -on the local side, and whenever a connection is made to this port, the -connection is forwarded over the secure channel, and a connection is -made to -.Ar host -port -.Ar hostport -from the remote machine. -Port forwardings can also be specified in the configuration file. -Only root can forward privileged ports. -IPv6 addresses can be specified with an alternative syntax: -.Ar port/host/hostport -.It Fl R Ar port:host:hostport -Specifies that the given port on the remote (server) host is to be -forwarded to the given host and port on the local side. -This works by allocating a socket to listen to -.Ar port -on the remote side, and whenever a connection is made to this port, the -connection is forwarded over the secure channel, and a connection is -made to -.Ar host -port -.Ar hostport -from the local machine. -Port forwardings can also be specified in the configuration file. -Privileged ports can be forwarded only when -logging in as root on the remote machine. -IPv6 addresses can be specified with an alternative syntax: -.Ar port/host/hostport -.It Fl D Ar port -Specifies a local -.Dq dynamic -application-level port forwarding. -This works by allocating a socket to listen to -.Ar port -on the local side, and whenever a connection is made to this port, the -connection is forwarded over the secure channel, and the application -protocol is then used to determine where to connect to from the -remote machine. Currently the SOCKS4 protocol is supported, and +.Pp +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 may then be able to perform activities such as keystroke monitoring. +.Pp +For this reason, X11 forwarding is subjected to X11 SECURITY extension +restrictions by default. +Please refer to the +.Nm +.Fl Y +option and the +.Cm ForwardX11Trusted +directive in +.Xr ssh_config 5 +for more information. +.It Fl x +Disables X11 forwarding. +.It Fl Y +Enables trusted X11 forwarding. +Trusted X11 forwardings are not subjected to the X11 SECURITY extension +controls. +.It Fl y +Send log information using the +.Xr syslog 3 +system module. +By default this information is sent to stderr. +.El +.Pp +.Nm +may additionally obtain configuration data from +a per-user configuration file and a system-wide configuration file. +The file format and configuration options are described in +.Xr ssh_config 5 . +.Pp +.Nm +exits with the exit status of the remote command or with 255 +if an error occurred. +.Sh AUTHENTICATION +The OpenSSH SSH client supports SSH protocols 1 and 2. +Protocol 2 is the default, with +.Nm +falling back to protocol 1 if it detects protocol 2 is unsupported. +These settings may be altered using the +.Cm Protocol +option in +.Xr ssh_config 5 , +or enforced using the +.Fl 1 +and +.Fl 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, umac-64, hmac-ripemd160). +Protocol 1 lacks a strong mechanism for ensuring the +integrity of the connection. +.Pp +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: +.Cm PreferredAuthentications . +.Pp +Host-based authentication works as follows: +If the machine the user logs in from is listed in +.Pa /etc/hosts.equiv +or +.Pa /etc/shosts.equiv +on the remote machine, and the user names are +the same on both sides, or if the files +.Pa ~/.rhosts +or +.Pa ~/.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 +.Em must +be able to verify the client's +host key (see the description of +.Pa /etc/ssh/ssh_known_hosts +and +.Pa ~/.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: +.Pa /etc/hosts.equiv , +.Pa ~/.rhosts , +and the rlogin/rsh protocol in general, are inherently insecure and should be +disabled if security is desired.] +.Pp +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. +.Nm +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 +.Sx HISTORY +section of +.Xr ssl 8 +contains a brief discussion of the two algorithms. +.Pp +The file +.Pa ~/.ssh/authorized_keys +lists the public keys that are permitted for logging in. +When the user logs in, the +.Nm +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. +.Pp +The user creates his/her key pair by running +.Xr ssh-keygen 1 . +This stores the private key in +.Pa ~/.ssh/identity +(protocol 1), +.Pa ~/.ssh/id_dsa +(protocol 2 DSA), +or +.Pa ~/.ssh/id_rsa +(protocol 2 RSA) +and stores the public key in +.Pa ~/.ssh/identity.pub +(protocol 1), +.Pa ~/.ssh/id_dsa.pub +(protocol 2 DSA), +or +.Pa ~/.ssh/id_rsa.pub +(protocol 2 RSA) +in the user's home directory. +The user should then copy the public key +to +.Pa ~/.ssh/authorized_keys +in his/her home directory on the remote machine. +The +.Pa authorized_keys +file corresponds to the conventional +.Pa ~/.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. +.Pp +The most convenient way to use public key authentication may be with an +authentication agent. +See +.Xr ssh-agent 1 +for more information. +.Pp +Challenge-response authentication works as follows: +The server sends an arbitrary +.Qq challenge +text, and prompts for a response. +Protocol 2 allows multiple challenges and responses; +protocol 1 is restricted to just one challenge/response. +Examples of challenge-response authentication include +BSD Authentication (see +.Xr login.conf 5 ) +and PAM (some non-OpenBSD systems). +.Pp +Finally, if other authentication methods fail, +.Nm +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. +.Pp +.Nm +automatically maintains and checks a database containing +identification for all hosts it has ever been used with. +Host keys are stored in +.Pa ~/.ssh/known_hosts +in the user's home directory. +Additionally, the file +.Pa /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, +.Nm +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 +.Cm StrictHostKeyChecking +option can be used to control logins to machines whose +host key is not known or has changed. +.Pp +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. +.Pp +If a pseudo-terminal has been allocated (normal login session), the +user may use the escape characters noted below. +.Pp +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 +.Dq none +will also make the session transparent even if a tty is used. +.Pp +The session terminates when the command or shell on the remote +machine exits and all X11 and TCP connections have been closed. +.Sh ESCAPE CHARACTERS +When a pseudo-terminal has been requested, .Nm -will act as a SOCKS4 server. -Only root can forward privileged ports. -Dynamic port forwardings can also be specified in the configuration file. -.It Fl 1 -Forces +supports a number of functions through the use of an escape character. +.Pp +A single tilde character can be sent as +.Ic ~~ +or by following the tilde by 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 +.Cm EscapeChar +configuration directive or on the command line by the +.Fl e +option. +.Pp +The supported escapes (assuming the default +.Ql ~ ) +are: +.Bl -tag -width Ds +.It Cm ~. +Disconnect. +.It Cm ~^Z +Background +.Nm . +.It Cm ~# +List forwarded connections. +.It Cm ~& +Background .Nm -to try protocol version 1 only. -.It Fl 2 -Forces +at logout when waiting for forwarded connection / X11 sessions to terminate. +.It Cm ~? +Display a list of escape characters. +.It Cm ~B +Send a BREAK to the remote system +(only useful for SSH protocol version 2 and if the peer supports it). +.It Cm ~C +Open command line. +Currently this allows the addition of port forwardings using the +.Fl L , +.Fl R +and +.Fl D +options (see above). +It also allows the cancellation of existing remote port-forwardings +using +.Sm off +.Fl KR Oo Ar bind_address : Oc Ar port . +.Sm on +.Ic !\& Ns Ar command +allows the user to execute a local command if the +.Ic PermitLocalCommand +option is enabled in +.Xr ssh_config 5 . +Basic help is available, using the +.Fl h +option. +.It Cm ~R +Request rekeying of the connection +(only useful for SSH protocol version 2 and if the peer supports it). +.El +.Sh TCP FORWARDING +Forwarding of arbitrary TCP connections over the secure channel can +be specified either on the command line or in a configuration file. +One possible application of TCP forwarding is a secure connection to a +mail server; another is going through firewalls. +.Pp +In the example below, we look at encrypting communication between +an IRC client and server, even though the IRC server does not directly +support encrypted communications. +This works as follows: +the user connects to the remote host using +.Nm , +specifying a port to be used to forward connections +to the remote server. +After that it is possible to start the service which is to be encrypted +on the client machine, +connecting to the same local port, +and .Nm -to try protocol version 2 only. -.It Fl 4 -Forces +will encrypt and forward the connection. +.Pp +The following example tunnels an IRC session from client machine +.Dq 127.0.0.1 +(localhost) +to remote server +.Dq server.example.com : +.Bd -literal -offset 4n +$ ssh -f -L 1234:localhost:6667 server.example.com sleep 10 +$ irc -c '#users' -p 1234 pinky 127.0.0.1 +.Ed +.Pp +This tunnels a connection to IRC server +.Dq server.example.com , +joining channel +.Dq #users , +nickname +.Dq pinky , +using port 1234. +It doesn't matter which port is used, +as long as it's greater than 1023 +(remember, only root can open sockets on privileged ports) +and doesn't conflict with any ports already in use. +The connection is forwarded to port 6667 on the remote server, +since that's the standard port for IRC services. +.Pp +The +.Fl f +option backgrounds .Nm -to use IPv4 addresses only. -.It Fl 6 -Forces +and the remote command +.Dq sleep 10 +is specified to allow an amount of time +(10 seconds, in the example) +to start the service which is to be tunnelled. +If no connections are made within the time specified, .Nm -to use IPv6 addresses only. -.El -.Sh CONFIGURATION FILES +will exit. +.Sh X11 FORWARDING +If the +.Cm ForwardX11 +variable is set to +.Dq yes +(or see the description of the +.Fl X , +.Fl x , +and +.Fl Y +options above) +and the user is using X11 (the +.Ev DISPLAY +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) will go through the +encrypted channel, and the connection to the real X server will be made +from the local machine. +The user should not manually set +.Ev DISPLAY . +Forwarding of X11 connections can be +configured on the command line or in configuration files. +.Pp +The +.Ev DISPLAY +value set by .Nm -may additionally obtain configuration data from -a per-user configuration file and a system-wide configuration file. -The file format and configuration options are described in -.Xr ssh_config 5 . +will point to the server machine, but with a display number greater than zero. +This is normal, and happens because +.Nm +creates a +.Dq proxy +X server on the server machine for forwarding the +connections over the encrypted channel. +.Pp +.Nm +will also automatically set up Xauthority data on the server machine. +For this purpose, it will generate a random authorization cookie, +store it in Xauthority 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). +.Pp +If the +.Cm ForwardAgent +variable is set to +.Dq yes +(or see the description of the +.Fl A +and +.Fl a +options above) and +the user is using an authentication agent, the connection to the agent +is automatically forwarded to the remote side. +.Sh VERIFYING HOST KEYS +When connecting to a server for the first time, +a fingerprint of the server's public key is presented to the user +(unless the option +.Cm StrictHostKeyChecking +has been disabled). +Fingerprints can be determined using +.Xr ssh-keygen 1 : +.Pp +.Dl $ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key +.Pp +If the fingerprint is already known, it can be matched +and the key can be accepted or rejected. +Because of the difficulty of comparing host keys +just by looking at hex strings, +there is also support to compare host keys visually, +using +.Em random art . +By setting the +.Cm VisualHostKey +option to +.Dq yes , +a small ASCII graphic gets displayed on every login to a server, no matter +if the session itself is interactive or not. +By learning the pattern a known server produces, a user can easily +find out that the host key has changed when a completely different pattern +is displayed. +Because these patterns are not unambiguous however, a pattern that looks +similar to the pattern remembered only gives a good probability that the +host key is the same, not guaranteed proof. +.Pp +To get a listing of the fingerprints along with their random art for +all known hosts, the following command line can be used: +.Pp +.Dl $ ssh-keygen -lv -f ~/.ssh/known_hosts +.Pp +If the fingerprint is unknown, +an alternative method of verification is available: +SSH fingerprints verified by DNS. +An additional resource record (RR), +SSHFP, +is added to a zonefile +and the connecting client is able to match the fingerprint +with that of the key presented. +.Pp +In this example, we are connecting a client to a server, +.Dq host.example.com . +The SSHFP resource records should first be added to the zonefile for +host.example.com: +.Bd -literal -offset indent +$ ssh-keygen -r host.example.com. +.Ed +.Pp +The output lines will have to be added to the zonefile. +To check that the zone is answering fingerprint queries: +.Pp +.Dl $ dig -t SSHFP host.example.com +.Pp +Finally the client connects: +.Bd -literal -offset indent +$ ssh -o "VerifyHostKeyDNS ask" host.example.com +[...] +Matching host key fingerprint found in DNS. +Are you sure you want to continue connecting (yes/no)? +.Ed +.Pp +See the +.Cm VerifyHostKeyDNS +option in +.Xr ssh_config 5 +for more information. +.Sh SSH-BASED VIRTUAL PRIVATE NETWORKS +.Nm +contains support for Virtual Private Network (VPN) tunnelling +using the +.Xr tun 4 +network pseudo-device, +allowing two networks to be joined securely. +The +.Xr sshd_config 5 +configuration option +.Cm PermitTunnel +controls whether the server supports this, +and at what level (layer 2 or 3 traffic). +.Pp +The following example would connect client network 10.0.50.0/24 +with remote network 10.0.99.0/24 using a point-to-point connection +from 10.1.1.1 to 10.1.1.2, +provided that the SSH server running on the gateway to the remote network, +at 192.168.1.15, allows it. +.Pp +On the client: +.Bd -literal -offset indent +# ssh -f -w 0:1 192.168.1.15 true +# ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252 +# route add 10.0.99.0/24 10.1.1.2 +.Ed +.Pp +On the server: +.Bd -literal -offset indent +# ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252 +# route add 10.0.50.0/24 10.1.1.1 +.Ed +.Pp +Client access may be more finely tuned via the +.Pa /root/.ssh/authorized_keys +file (see below) and the +.Cm PermitRootLogin +server option. +The following entry would permit connections on +.Xr tun 4 +device 1 from user +.Dq jane +and on tun device 2 from user +.Dq john , +if +.Cm PermitRootLogin +is set to +.Dq forced-commands-only : +.Bd -literal -offset 2n +tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... jane +tunnel="2",command="sh /etc/netstart tun2" ssh-rsa ... john +.Ed +.Pp +Since an SSH-based setup entails a fair amount of overhead, +it may be more suited to temporary setups, +such as for wireless VPNs. +More permanent VPNs are better provided by tools such as +.Xr ipsecctl 8 +and +.Xr isakmpd 8 . .Sh ENVIRONMENT .Nm will normally set the following environment variables: -.Bl -tag -width Ds +.Bl -tag -width "SSH_ORIGINAL_COMMAND" .It Ev DISPLAY The .Ev DISPLAY @@ -664,9 +1164,12 @@ variable indicates the location of the X11 server. It is automatically set by .Nm to point to a value of the form -.Dq hostname:n -where hostname indicates -the host where the shell runs, and n is an integer >= 1. +.Dq hostname:n , +where +.Dq hostname +indicates the host where the shell runs, and +.Sq n +is an integer \*(Ge 1. .Nm uses this special value to forward X11 connections over the secure channel. @@ -687,7 +1190,7 @@ Set to the path of the user's mailbox. Set to the default .Ev PATH , as specified when compiling -.Nm ssh . +.Nm . .It Ev SSH_ASKPASS If .Nm @@ -705,22 +1208,23 @@ and open an X11 window to read the passphrase. This is particularly useful when calling .Nm from a -.Pa .Xsession +.Pa .xsession or related script. (Note that on some machines it may be necessary to redirect the input from .Pa /dev/null to make this work.) .It Ev SSH_AUTH_SOCK -Identifies the path of a unix-domain socket used to communicate with the -agent. -.It Ev SSH_CLIENT -Identifies the client end of the connection. +Identifies the path of a +.Ux Ns -domain +socket used to communicate with the agent. +.It Ev SSH_CONNECTION +Identifies the client and server ends of the connection. The variable contains -three space-separated values: client ip-address, client port number, -and server port number. +four space-separated values: client IP address, client port number, +server IP address, and server port number. .It Ev SSH_ORIGINAL_COMMAND -The variable contains the original command line if a forced command +This variable contains the original command line if a forced command is executed. It can be used to extract the original arguments. .It Ev SSH_TTY @@ -729,8 +1233,8 @@ with the current shell or command. If the current session has no tty, this variable is not set. .It Ev TZ -The timezone variable is set to indicate the present timezone if it -was set when the daemon was started (i.e., the daemon passes the value +This variable is set to indicate the present time zone if it +was set when the daemon was started (i.e. the daemon passes the value on to new connections). .It Ev USER Set to the name of the user logging in. @@ -739,230 +1243,237 @@ Set to the name of the user logging in. Additionally, .Nm reads -.Pa $HOME/.ssh/environment , +.Pa ~/.ssh/environment , and adds lines of the format .Dq VARNAME=value -to the environment. +to the environment if the file exists and users are allowed to +change their environment. +For more information, see the +.Cm PermitUserEnvironment +option in +.Xr sshd_config 5 . .Sh FILES -.Bl -tag -width Ds -.It Pa $HOME/.ssh/known_hosts -Records host keys for all hosts the user has logged into that are not -in -.Pa /etc/ssh/ssh_known_hosts . -See -.Xr sshd 8 . -.It Pa $HOME/.ssh/identity, $HOME/.ssh/id_dsa, $HOME/.ssh/id_rsa -Contains the authentication identity of the user. -They are for protocol 1 RSA, protocol 2 DSA, and protocol 2 RSA, respectively. +.Bl -tag -width Ds -compact +.It ~/.rhosts +This file is used for host-based authentication (see above). +On some machines this file may need to be +world-readable if the user's home directory is on an NFS partition, +because +.Xr sshd 8 +reads it as root. +Additionally, this file must be owned by the user, +and must not have write permissions for anyone else. +The recommended +permission for most machines is read/write for the user, and not +accessible by others. +.Pp +.It ~/.shosts +This file is used in exactly the same way as +.Pa .rhosts , +but allows host-based authentication without permitting login with +rlogin/rsh. +.Pp +.It ~/.ssh/ +This directory is the default location for all user-specific configuration +and authentication information. +There is no general requirement to keep the entire contents of this directory +secret, but the recommended permissions are read/write/execute for the user, +and not accessible by others. +.Pp +.It ~/.ssh/authorized_keys +Lists the public keys (RSA/DSA) that can be used for logging in as this user. +The format of this file is described in the +.Xr sshd 8 +manual page. +This file is not highly sensitive, but the recommended +permissions are read/write for the user, and not accessible by others. +.Pp +.It ~/.ssh/config +This is the per-user configuration file. +The file format and configuration options are described in +.Xr ssh_config 5 . +Because of the potential for abuse, this file must have strict permissions: +read/write for the user, and not accessible by others. +.Pp +.It ~/.ssh/environment +Contains additional definitions for environment variables; see +.Sx ENVIRONMENT , +above. +.Pp +.It ~/.ssh/identity +.It ~/.ssh/id_dsa +.It ~/.ssh/id_rsa +Contains the private key for authentication. These files contain sensitive data and should be readable by the user but not accessible by others (read/write/execute). -Note that .Nm -ignores a private key file if it is accessible by others. +will simply ignore a private key file if it is accessible by others. It is possible to specify a passphrase when -generating the key; the passphrase will be used to encrypt the +generating the key which will be used to encrypt the sensitive part of this file using 3DES. -.It Pa $HOME/.ssh/identity.pub, $HOME/.ssh/id_dsa.pub, $HOME/.ssh/id_rsa.pub -Contains the public key for authentication (public part of the -identity file in human-readable form). -The contents of the -.Pa $HOME/.ssh/identity.pub -file should be added to -.Pa $HOME/.ssh/authorized_keys -on all machines -where the user wishes to log in using protocol version 1 RSA authentication. -The contents of the -.Pa $HOME/.ssh/id_dsa.pub -and -.Pa $HOME/.ssh/id_rsa.pub -file should be added to -.Pa $HOME/.ssh/authorized_keys -on all machines -where the user wishes to log in using protocol version 2 DSA/RSA authentication. +.Pp +.It ~/.ssh/identity.pub +.It ~/.ssh/id_dsa.pub +.It ~/.ssh/id_rsa.pub +Contains the public key for authentication. These files are not sensitive and can (but need not) be readable by anyone. -These files are -never used automatically and are not necessary; they are only provided for -the convenience of the user. -.It Pa $HOME/.ssh/config -This is the per-user configuration file. -The file format and configuration options are described in -.Xr ssh_config 5 . -.It Pa $HOME/.ssh/authorized_keys -Lists the public keys (RSA/DSA) that can be used for logging in as this user. -The format of this file is described in the -.Xr sshd 8 -manual page. -In the simplest form the format is the same as the .pub -identity files. -This file is not highly sensitive, but the recommended -permissions are read/write for the user, and not accessible by others. -.It Pa /etc/ssh/ssh_known_hosts -Systemwide list of known host keys. -This file should be prepared by the -system administrator to contain the public host keys of all machines in the -organization. -This file should be world-readable. -This file contains -public keys, one per line, in the following format (fields separated -by spaces): system name, public key and optional comment field. -When different names are used -for the same machine, all such names should be listed, separated by -commas. -The format is described on the -.Xr sshd 8 -manual page. .Pp -The canonical system name (as returned by name servers) is used by +.It ~/.ssh/known_hosts +Contains a list of host keys for all hosts the user has logged into +that are not already in the systemwide list of known host keys. +See .Xr sshd 8 -to verify the client host when logging in; other names are needed because +for further details of the format of this file. +.Pp +.It ~/.ssh/rc +Commands in this file are executed by .Nm -does not convert the user-supplied name to a canonical name before -checking the key, because someone with access to the name servers -would then be able to fool host authentication. +when the user logs in, just before the user's shell (or command) is +started. +See the +.Xr sshd 8 +manual page for more information. +.Pp +.It /etc/hosts.equiv +This file is for host-based authentication (see above). +It should only be writable by root. +.Pp +.It /etc/shosts.equiv +This file is used in exactly the same way as +.Pa hosts.equiv , +but allows host-based authentication without permitting login with +rlogin/rsh. +.Pp .It Pa /etc/ssh/ssh_config Systemwide configuration file. The file format and configuration options are described in .Xr ssh_config 5 . -.It Pa /etc/ssh/ssh_host_key, /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_rsa_key +.Pp +.It /etc/ssh/ssh_host_key +.It /etc/ssh/ssh_host_dsa_key +.It /etc/ssh/ssh_host_rsa_key These three files contain the private parts of the host keys -and are used for -.Cm RhostsRSAAuthentication -and -.Cm HostbasedAuthentication . -If the protocol version 1 -.Cm RhostsRSAAuthentication -method is used, +and are used for host-based authentication. +If protocol version 1 is used, .Nm must be setuid root, since the host key is readable only by root. For protocol version 2, .Nm uses .Xr ssh-keysign 8 -to access the host keys for -.Cm HostbasedAuthentication . -This eliminates the requirement that +to access the host keys, +eliminating the requirement that .Nm -be setuid root when that authentication method is used. +be setuid root when host-based authentication is used. By default .Nm is not setuid root. -.It Pa $HOME/.rhosts -This file is used in -.Pa \&.rhosts -authentication to list the -host/user pairs that are permitted to log in. -(Note that this file is -also used by rlogin and rsh, which makes using this file insecure.) -Each line of the file contains a host name (in the canonical form -returned by name servers), and then a user name on that host, -separated by a space. -On some machines this file may need to be -world-readable if the user's home directory is on a NFS partition, -because -.Xr sshd 8 -reads it as root. -Additionally, this file must be owned by the user, -and must not have write permissions for anyone else. -The recommended -permission for most machines is read/write for the user, and not -accessible by others. .Pp -Note that by default -.Xr sshd 8 -will be installed so that it requires successful RSA host -authentication before permitting \s+2.\s0rhosts authentication. -If the server machine does not have the client's host key in -.Pa /etc/ssh/ssh_known_hosts , -it can be stored in -.Pa $HOME/.ssh/known_hosts . -The easiest way to do this is to -connect back to the client from the server machine using ssh; this -will automatically add the host key to -.Pa $HOME/.ssh/known_hosts . -.It Pa $HOME/.shosts -This file is used exactly the same way as -.Pa \&.rhosts . -The purpose for -having this file is to be able to use rhosts authentication with -.Nm -without permitting login with -.Nm rlogin -or -.Xr rsh 1 . -.It Pa /etc/hosts.equiv -This file is used during -.Pa \&.rhosts authentication. -It contains -canonical hosts names, one per line (the full format is described on -the -.Xr sshd 8 -manual page). -If the client host is found in this file, login is -automatically permitted provided client and server user names are the -same. -Additionally, successful RSA host authentication is normally -required. -This file should only be writable by root. -.It Pa /etc/shosts.equiv -This file is processed exactly as -.Pa /etc/hosts.equiv . -This file may be useful to permit logins using -.Nm -but not using rsh/rlogin. -.It Pa /etc/ssh/sshrc -Commands in this file are executed by -.Nm -when the user logs in just before the user's shell (or command) is started. -See the +.It /etc/ssh/ssh_known_hosts +Systemwide list of known host keys. +This file should be prepared by the +system administrator to contain the public host keys of all machines in the +organization. +It should be world-readable. +See .Xr sshd 8 -manual page for more information. -.It Pa $HOME/.ssh/rc +for further details of the format of this file. +.Pp +.It /etc/ssh/sshrc Commands in this file are executed by .Nm -when the user logs in just before the user's shell (or command) is -started. +when the user logs in, just before the user's shell (or command) is started. See the .Xr sshd 8 manual page for more information. -.It Pa $HOME/.ssh/environment -Contains additional definitions for environment variables, see section -.Sx ENVIRONMENT -above. .El -.Sh DIAGNOSTICS -.Nm -exits with the exit status of the remote command or with 255 -if an error occurred. -.Sh AUTHORS -OpenSSH is a derivative of the original and free -ssh 1.2.12 release by Tatu Ylonen. -Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, -Theo de Raadt and Dug Song -removed many bugs, re-added newer features and -created OpenSSH. -Markus Friedl contributed the support for SSH -protocol versions 1.5 and 2.0. .Sh SEE ALSO -.Xr rsh 1 , .Xr scp 1 , .Xr sftp 1 , .Xr ssh-add 1 , .Xr ssh-agent 1 , .Xr ssh-keygen 1 , -.Xr telnet 1 , -.Xr ssh_config 4 , -.Xr ssh-keysign 8, +.Xr ssh-keyscan 1 , +.Xr tun 4 , +.Xr hosts.equiv 5 , +.Xr ssh_config 5 , +.Xr ssh-keysign 8 , .Xr sshd 8 .Rs -.%A T. Ylonen -.%A T. Kivinen -.%A M. Saarinen -.%A T. Rinne -.%A S. Lehtinen -.%T "SSH Protocol Architecture" -.%N draft-ietf-secsh-architecture-12.txt -.%D January 2002 -.%O work in progress material +.%R RFC 4250 +.%T "The Secure Shell (SSH) Protocol Assigned Numbers" +.%D 2006 +.Re +.Rs +.%R RFC 4251 +.%T "The Secure Shell (SSH) Protocol Architecture" +.%D 2006 +.Re +.Rs +.%R RFC 4252 +.%T "The Secure Shell (SSH) Authentication Protocol" +.%D 2006 +.Re +.Rs +.%R RFC 4253 +.%T "The Secure Shell (SSH) Transport Layer Protocol" +.%D 2006 +.Re +.Rs +.%R RFC 4254 +.%T "The Secure Shell (SSH) Connection Protocol" +.%D 2006 +.Re +.Rs +.%R RFC 4255 +.%T "Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints" +.%D 2006 +.Re +.Rs +.%R RFC 4256 +.%T "Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)" +.%D 2006 +.Re +.Rs +.%R RFC 4335 +.%T "The Secure Shell (SSH) Session Channel Break Extension" +.%D 2006 +.Re +.Rs +.%R RFC 4344 +.%T "The Secure Shell (SSH) Transport Layer Encryption Modes" +.%D 2006 +.Re +.Rs +.%R RFC 4345 +.%T "Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol" +.%D 2006 +.Re +.Rs +.%R RFC 4419 +.%T "Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol" +.%D 2006 +.Re +.Rs +.%R RFC 4716 +.%T "The Secure Shell (SSH) Public Key File Format" +.%D 2006 +.Re +.Rs +.%T "Hash Visualization: a New Technique to improve Real-World Security" +.%A A. Perrig +.%A D. Song +.%D 1999 +.%O "International Workshop on Cryptographic Techniques and E-Commerce (CrypTEC '99)" .Re +.Sh AUTHORS +OpenSSH is a derivative of the original and free +ssh 1.2.12 release by Tatu Ylonen. +Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, +Theo de Raadt and Dug Song +removed many bugs, re-added newer features and +created OpenSSH. +Markus Friedl contributed the support for SSH +protocol versions 1.5 and 2.0.