diff options
Diffstat (limited to 'crypto/openssh/ssh.1')
-rw-r--r-- | crypto/openssh/ssh.1 | 1429 |
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. |