summaryrefslogtreecommitdiffstats
path: root/crypto/openssh/ssh.1
diff options
context:
space:
mode:
Diffstat (limited to 'crypto/openssh/ssh.1')
-rw-r--r--crypto/openssh/ssh.11429
1 files changed, 0 insertions, 1429 deletions
diff --git a/crypto/openssh/ssh.1 b/crypto/openssh/ssh.1
deleted file mode 100644
index 93be52f..0000000
--- a/crypto/openssh/ssh.1
+++ /dev/null
@@ -1,1429 +0,0 @@
-.\" -*- nroff -*-
-.\"
-.\" Author: Tatu Ylonen <ylo@cs.hut.fi>
-.\" Copyright (c) 1995 Tatu Ylonen <ylo@cs.hut.fi>, Espoo, Finland
-.\" All rights reserved
-.\"
-.\" As far as I am concerned, the code I have written for this software
-.\" can be used freely for any purpose. Any derived versions of this
-.\" software must be clearly marked as such, and if the derived work is
-.\" incompatible with the protocol description in the RFC file, it must be
-.\" called by a name other than "ssh" or "Secure Shell".
-.\"
-.\" Copyright (c) 1999,2000 Markus Friedl. All rights reserved.
-.\" Copyright (c) 1999 Aaron Campbell. All rights reserved.
-.\" Copyright (c) 1999 Theo de Raadt. All rights reserved.
-.\"
-.\" Redistribution and use in source and binary forms, with or without
-.\" modification, are permitted provided that the following conditions
-.\" are met:
-.\" 1. Redistributions of source code must retain the above copyright
-.\" notice, this list of conditions and the following disclaimer.
-.\" 2. Redistributions in binary form must reproduce the above copyright
-.\" notice, this list of conditions and the following disclaimer in the
-.\" documentation and/or other materials provided with the distribution.
-.\"
-.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
-.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
-.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
-.\" IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
-.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
-.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
-.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-.\" (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.265 2006/10/28 18:08:10 otto Exp $
-.Dd September 25, 1999
-.Dt SSH 1
-.Os
-.Sh NAME
-.Nm ssh
-.Nd OpenSSH SSH client (remote login program)
-.Sh SYNOPSIS
-.Nm ssh
-.Op Fl 1246AaCfgkMNnqsTtVvXxY
-.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
-.Oo Fl R\ \&
-.Sm off
-.Oo Ar bind_address : Oc
-.Ar port : host : hostport
-.Sm on
-.Oc
-.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
-two untrusted hosts over an insecure network.
-X11 connections and arbitrary TCP ports
-can also be forwarded over the secure channel.
-.Pp
-.Nm
-connects and logs into the specified
-.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 (see below).
-.Pp
-If
-.Ar command
-is specified,
-it is executed on the remote host instead of a login shell.
-.Pp
-The options are as follows:
-.Bl -tag -width Ds
-.It Fl 1
-Forces
-.Nm
-to try protocol version 1 only.
-.It Fl 2
-Forces
-.Nm
-to try protocol version 2 only.
-.It Fl 4
-Forces
-.Nm
-to use IPv4 addresses only.
-.It Fl 6
-Forces
-.Nm
-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
-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
-.Ar 3des .
-.Ar des
-is only supported in the
-.Nm
-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.
-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.
-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
-.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.
-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
-to go to background just before command execution.
-This is useful if
-.Nm
-is going to ask for passwords or passphrases, but the user
-wants it in the background.
-This implies
-.Fl n .
-The recommended way to start X11 programs at a remote site is with
-something like
-.Ic ssh -f host xterm .
-.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 ~/.ssh/identity
-for protocol version 1, and
-.Pa ~/.ssh/id_rsa
-and
-.Pa ~/.ssh/id_dsa
-for protocol version 2.
-Identity files may also be specified on
-a per-host basis in the configuration file.
-It is possible to have multiple
-.Fl i
-options (and multiple identities specified in
-configuration files).
-.It Fl k
-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
-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
-(actually, prevents reading from stdin).
-This must be used when
-.Nm
-is run in the background.
-A common trick is to use this to run X11 programs on a remote machine.
-For example,
-.Ic ssh -n shadows.cs.hut.fi emacs &
-will start an emacs on shadows.cs.hut.fi, and the X11
-connection will be automatically forwarded over an encrypted channel.
-The
-.Nm
-program will be put in the background.
-(This does not work if
-.Nm
-needs to ask for a password or passphrase; see also the
-.Fl f
-option.)
-.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 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 q
-Quiet mode.
-Causes all 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 overriden 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 ) .
-.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.\&
-.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.
-Multiple
-.Fl t
-options force tty allocation, even if
-.Nm
-has no local tty.
-.It Fl V
-Display the version number and exit.
-.It Fl v
-Verbose mode.
-Causes
-.Nm
-to print debugging messages about its progress.
-This is helpful in
-debugging connection, authentication, and configuration problems.
-Multiple
-.Fl v
-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.
-.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.
-.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, 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
-and
-.Fl R
-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 verified,
-and the key can be accepted.
-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 .
-.It Ev SSH_ASKPASS
-If
-.Nm
-needs a passphrase, it will read the passphrase from the current
-terminal if it was run from a terminal.
-If
-.Nm
-does not have a terminal associated with it but
-.Ev DISPLAY
-and
-.Ev SSH_ASKPASS
-are set, it will execute the program specified by
-.Ev SSH_ASKPASS
-and open an X11 window to read the passphrase.
-This is particularly useful when calling
-.Nm
-from a
-.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
-.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.
-.It Ev SSH_ORIGINAL_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
-This is set to the name of the tty (path to the device) associated
-with the current shell or command.
-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
-on to new connections).
-.It Ev USER
-Set to the name of the user logging in.
-.El
-.Pp
-Additionally,
-.Nm
-reads
-.Pa ~/.ssh/environment ,
-and adds lines of the format
-.Dq VARNAME=value
-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 -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/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).
-.Nm
-will simply ignore a private key file if it is accessible by others.
-It is possible to specify a passphrase when
-generating the key which will be used to encrypt the
-sensitive part of this file using 3DES.
-.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.
-.Pp
-.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
-for further details of the format of this file.
-.Pp
-.It ~/.ssh/rc
-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
-.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 .
-.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 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,
-eliminating the requirement that
-.Nm
-be setuid root when host-based authentication is used.
-By default
-.Nm
-is not setuid root.
-.Pp
-.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
-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.
-See the
-.Xr sshd 8
-manual page for more information.
-.El
-.Sh SEE ALSO
-.Xr scp 1 ,
-.Xr sftp 1 ,
-.Xr ssh-add 1 ,
-.Xr ssh-agent 1 ,
-.Xr ssh-keygen 1 ,
-.Xr ssh-keyscan 1 ,
-.Xr tun 4 ,
-.Xr hosts.equiv 5 ,
-.Xr ssh_config 5 ,
-.Xr ssh-keysign 8 ,
-.Xr sshd 8
-.Rs
-.%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
-.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.
OpenPOWER on IntegriCloud