X-Git-Url: http://andersk.mit.edu/gitweb/openssh.git/blobdiff_plain/d20f3c9eac865c7dd2e9335becc064e15a420202..040d6b1f7000ee8e36f8d0a21ea82a5f88acb7a5:/ssh.1

diff --git a/ssh.1 b/ssh.1
index 8a55c2f6..568b5314 100644
--- a/ssh.1
+++ b/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.215 2005/12/06 22:38:27 reyk Exp $
-.Dd September 25, 1999
+.\" $OpenBSD: ssh.1,v 1.280 2008/11/09 12:34:47 tobias Exp $
+.Dd $Mdocdate$
 .Dt SSH 1
 .Os
 .Sh NAME
@@ -43,7 +43,7 @@
 .Nd OpenSSH SSH client (remote login program)
 .Sh SYNOPSIS
 .Nm ssh
-.Op Fl 1246AaCfgkMNnqsTtVvXxY
+.Op Fl 1246AaCfgKkMNnqsTtVvXxYy
 .Op Fl b Ar bind_address
 .Op Fl c Ar cipher_spec
 .Oo Fl D\ \&
@@ -77,9 +77,12 @@
 .Sm on
 .Oc
 .Op Fl S Ar ctl_path
-.Op Fl w Ar tunnel : tunnel
+.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
@@ -87,7 +90,7 @@ executing commands on a remote machine.
 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
+X11 connections and arbitrary TCP ports
 can also be forwarded over the secure channel.
 .Pp
 .Nm
@@ -98,312 +101,12 @@ connects and logs into the specified
 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
 If
 .Ar command
 is specified,
-.Ar command
-is executed on the remote host instead of a login shell.
-.Ss SSH protocol version 1
-The first authentication method is the
-.Em rhosts
-or
-.Em hosts.equiv
-method combined with RSA-based host authentication.
-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 log in.
-Additionally, if the server can verify the client's
-host key (see
-.Pa /etc/ssh/ssh_known_hosts
-and
-.Pa ~/.ssh/known_hosts
-in the
-.Sx FILES
-section), only then is login 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
-As a second 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.
-.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 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 ~/.ssh/identity
-and stores the public key in
-.Pa ~/.ssh/identity.pub
-in the user's home directory.
-The user should then copy the
-.Pa identity.pub
-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 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.
-.Ss SSH protocol version 2
-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 ~/.ssh/id_dsa
-or
-.Pa ~/.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 ~/.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 to prove 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 AES, 3DES, Blowfish, CAST128 or Arcfour)
-and integrity (hmac-md5, hmac-sha1, hmac-ripemd160).
-Note that protocol 1 lacks a strong mechanism for ensuring the
-integrity of the connection.
-.Ss Login session and remote execution
-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 .
-.Ss Escape Characters
-When a pseudo-terminal has been requested,
-.Nm
-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 ssh .
-.It Cm ~#
-List forwarded connections.
-.It Cm ~&
-Background
-.Nm
-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
-and
-.Fl R
-options (see below).
-It also allows the cancellation of existing remote port-forwardings
-using
-.Fl KR Ar hostport .
-The 
-.Ic ! 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
-.Ss X11 and TCP forwarding
-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
-.Nm
-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 described later) and
-the user is using an authentication agent, the connection to the agent
-is automatically forwarded to the remote side.
-.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.
-.Ss Server authentication
-.Nm
-automatically maintains and checks a database containing
-identifications 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 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
-.Nm
-can be configured to verify host identification using fingerprint resource
-records (SSHFP) published in DNS.
-The
-.Cm VerifyHostKeyDNS
-option can be used to control how DNS lookups are performed.
-SSHFP resource records can be generated using
-.Xr ssh-keygen 1 .
+it is executed on the remote host instead of a login shell.
 .Pp
 The options are as follows:
 .Bl -tag -width Ds
@@ -444,7 +147,7 @@ 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/IP connections).
+data for forwarded X11 and TCP connections).
 The compression algorithm is the same used by
 .Xr gzip 1 ,
 and the
@@ -464,7 +167,7 @@ Selects the cipher specification for encrypting the session.
 Protocol version 1 allows specification of a single cipher.
 The supported values are
 .Dq 3des ,
-.Dq blowfish
+.Dq blowfish ,
 and
 .Dq des .
 .Ar 3des
@@ -484,29 +187,29 @@ Its use is strongly discouraged due to cryptographic weaknesses.
 The default is
 .Dq 3des .
 .Pp
-For protocol version 2
+For protocol version 2,
 .Ar cipher_spec
 is a comma-separated list of ciphers
 listed in order of preference.
-The supported ciphers are
-.Dq 3des-cbc ,
-.Dq aes128-cbc ,
-.Dq aes192-cbc ,
-.Dq aes256-cbc ,
-.Dq aes128-ctr ,
-.Dq aes192-ctr ,
-.Dq aes256-ctr ,
-.Dq arcfour128 ,
-.Dq arcfour256 ,
-.Dq arcfour ,
-.Dq blowfish-cbc ,
+The supported ciphers are:
+3des-cbc,
+aes128-cbc,
+aes192-cbc,
+aes256-cbc,
+aes128-ctr,
+aes192-ctr,
+aes256-ctr,
+arcfour128,
+arcfour256,
+arcfour,
+blowfish-cbc,
 and
-.Dq cast128-cbc .
-The default is
-.Bd -literal
-  ``aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,
-    arcfour256,arcfour,aes192-cbc,aes256-cbc,aes128-ctr,
-    aes192-ctr,aes256-ctr''
+cast128-cbc.
+The default is:
+.Bd -literal -offset indent
+aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,
+arcfour256,arcfour,aes192-cbc,aes256-cbc,aes128-ctr,
+aes192-ctr,aes256-ctr
 .Ed
 .It Fl D Xo
 .Sm off
@@ -554,7 +257,7 @@ 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 ch | ^ch | none
+.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.
@@ -587,14 +290,24 @@ 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
-Specifies which smartcard device to use.
-The argument is the 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.
@@ -611,6 +324,9 @@ It is possible to have multiple
 .Fl i
 options (and multiple identities specified in
 configuration files).
+.It Fl K
+Enables GSSAPI-based authentication and forwarding (delegation) of GSSAPI
+credentials to the server.
 .It Fl k
 Disables forwarding (delegation) of GSSAPI credentials to the server.
 .It Fl L Xo
@@ -666,6 +382,13 @@ Places the
 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
@@ -738,6 +461,7 @@ For full details of the options listed below, and their possible values, see
 .It ControlPath
 .It DynamicForward
 .It EscapeChar
+.It ExitOnForwardFailure
 .It ForwardAgent
 .It ForwardX11
 .It ForwardX11Trusted
@@ -767,6 +491,7 @@ For full details of the options listed below, and their possible values, see
 .It Protocol
 .It ProxyCommand
 .It PubkeyAuthentication
+.It RekeyLimit
 .It RemoteForward
 .It RhostsRSAAuthentication
 .It RSAAuthentication
@@ -782,6 +507,7 @@ For full details of the options listed below, and their possible values, see
 .It User
 .It UserKnownHostsFile
 .It VerifyHostKeyDNS
+.It VisualHostKey
 .It XAuthLocation
 .El
 .It Fl p Ar port
@@ -790,7 +516,7 @@ This can be specified on a
 per-host basis in the configuration file.
 .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
@@ -824,7 +550,7 @@ using an alternative syntax:
 .Pp
 By default, the listening socket on the server will be bound to the loopback
 interface only.
-This may be overriden by specifying a
+This may be overridden by specifying a
 .Ar bind_address .
 An empty
 .Ar bind_address ,
@@ -858,7 +584,7 @@ Disable pseudo-tty allocation.
 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
@@ -877,13 +603,35 @@ Multiple
 .Fl v
 options increase the verbosity.
 The maximum is 3.
-.It Fl w
-Requests a
+.It Fl w Xo
+.Ar local_tun Ns Op : Ns Ar remote_tun
+.Xc
+Requests
+tunnel
+device forwarding with the specified
 .Xr tun 4
-device on the client and server like the
+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
-directive in
+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.
@@ -910,48 +658,549 @@ Disables X11 forwarding.
 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
-.Sh CONFIGURATION FILES
+.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 .
-.Sh ENVIRONMENT
-.Nm
-will normally set the following environment variables:
-.Bl -tag -width LOGNAME
-.It Ev DISPLAY
-The
-.Ev DISPLAY
-variable indicates the location of the X11 server.
-It is automatically set by
+.Pp
 .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 \*(Ge 1.
+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
-uses this special value to forward X11 connections over the secure
-channel.
-The user should normally not set
-.Ev DISPLAY
-explicitly, as that
-will render the X11 connection insecure (and will require the user to
-manually copy any required authorization cookies).
-.It Ev HOME
-Set to the path of the user's home directory.
-.It Ev LOGNAME
-Synonym for
-.Ev USER ;
-set for compatibility with systems that use this variable.
-.It Ev MAIL
+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
+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
+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
+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
+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
+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
+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 "SSH_ORIGINAL_COMMAND"
+.It Ev DISPLAY
+The
+.Ev DISPLAY
+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
+.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.
+The user should normally not set
+.Ev DISPLAY
+explicitly, as that
+will render the X11 connection insecure (and will require the user to
+manually copy any required authorization cookies).
+.It Ev HOME
+Set to the path of the user's home directory.
+.It Ev LOGNAME
+Synonym for
+.Ev USER ;
+set for compatibility with systems that use this variable.
+.It Ev MAIL
 Set to the path of the user's mailbox.
 .It Ev PATH
 Set to the default
 .Ev PATH ,
 as specified when compiling
-.Nm ssh .
+.Nm .
 .It Ev SSH_ASKPASS
 If
 .Nm
@@ -976,15 +1225,16 @@ 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.
+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
-four space-separated values: client ip-address, client port number,
-server ip-address 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
@@ -994,7 +1244,7 @@ If the current session has no tty,
 this variable is not set.
 .It Ev TZ
 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
+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.
@@ -1006,235 +1256,227 @@ reads
 .Pa ~/.ssh/environment ,
 and adds lines of the format
 .Dq VARNAME=value
-to the environment if the file exists and if users are allowed to
+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 ~/.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 ~/.ssh/identity, ~/.ssh/id_dsa, ~/.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 ~/.ssh/identity.pub, ~/.ssh/id_dsa.pub, ~/.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 ~/.ssh/identity.pub
-file should be added to the file
-.Pa ~/.ssh/authorized_keys
-on all machines
-where the user wishes to log in using protocol version 1 RSA authentication.
-The contents of the
-.Pa ~/.ssh/id_dsa.pub
-and
-.Pa ~/.ssh/id_rsa.pub
-file should be added to
-.Pa ~/.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 ~/.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.
-.It Pa ~/.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
-.Pa .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 in 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 ~/.rhosts
-This file is used in
-.Cm RhostsRSAAuthentication
-and
-.Cm HostbasedAuthentication
-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
-.Xr sshd 8
-allows authentication only in combination with client host key
-authentication before permitting log in.
-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 ~/.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 ~/.ssh/known_hosts .
-.It Pa ~/.shosts
-This file is used exactly the same way as
-.Pa .rhosts .
-The purpose for
-having this file is to be able to use
-.Cm RhostsRSAAuthentication
-and
-.Cm HostbasedAuthentication
-authentication without permitting login with
-.Xr rlogin
-or
-.Xr rsh 1 .
-.It Pa /etc/hosts.equiv
-This file is used during
-.Cm RhostsRSAAuthentication
-and
-.Cm HostbasedAuthentication
-authentication.
-It contains
-canonical hosts names, one per line (the full format is described in 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 client host key authentication is 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 ~/.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 ~/.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 SEE ALSO
-.Xr gzip 1 ,
-.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-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