.\" (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.264 2006/09/25 04:55:38 ray Exp $
-.Dd September 25, 1999
+.\" $OpenBSD: ssh.1,v 1.289 2010/01/09 23:04:13 dtucker Exp $
+.Dd $Mdocdate$
.Dt SSH 1
.Os
.Sh NAME
.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\ \&
.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.
+(for the agent's
+.Ux Ns -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.
.Ar cipher_spec
is a comma-separated list of ciphers
listed in order of preference.
-The supported ciphers are:
-3des-cbc,
-aes128-cbc,
-aes192-cbc,
-aes256-cbc,
-aes128-ctr,
-aes192-ctr,
-aes256-ctr,
-arcfour128,
-arcfour256,
-arcfour,
-blowfish-cbc,
-and
-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
+See the
+.Cm Ciphers
+keyword for more information.
.It Fl D Xo
.Sm off
.Oo Ar bind_address : Oc
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
.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
.It User
.It UserKnownHostsFile
.It VerifyHostKeyDNS
+.It VisualHostKey
.It XAuthLocation
.El
.It Fl p Ar port
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
.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 ,
.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
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
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
+The default is to use protocol 2 only,
+though this can be changed via the
.Cm Protocol
option in
-.Xr ssh_config 5 ,
-or enforced using the
+.Xr ssh_config 5
+or the
.Fl 1
and
.Fl 2
options (see above).
Both protocols support similar authentication methods,
-but protocol 2 is preferred since
+but protocol 2 is the default since
it provides additional mechanisms for confidentiality
(the traffic is encrypted using AES, 3DES, Blowfish, CAST128, or Arcfour)
-and integrity (hmac-md5, hmac-sha1, hmac-ripemd160).
+and integrity (hmac-md5, hmac-sha1, umac-64, hmac-ripemd160).
Protocol 1 lacks a strong mechanism for ensuring the
integrity of the connection.
.Pp
.It Cm ~C
Open command line.
Currently this allows the addition of port forwardings using the
-.Fl L
-and
+.Fl L ,
.Fl R
+and
+.Fl D
options (see above).
It also allows the cancellation of existing remote port-forwardings
using
.Pp
.Dl $ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key
.Pp
-If the fingerprint is already known,
-it can be matched and verified,
-and the key can be accepted.
+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.
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, provided that the SSH server
-running on the gateway to the remote network,
-at 192.168.1.15, allows it:
+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.0.50.1 10.0.99.1 netmask 255.255.255.252
+# 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
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
.%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.