+++ /dev/null
-SCP(1) OpenBSD Reference Manual SCP(1)
-
-NAME
- scp - secure copy (remote file copy program)
-
-SYNOPSIS
- scp [-1246BCpqrv] [-c cipher] [-F ssh_config] [-i identity_file]
- [-l limit] [-o ssh_option] [-P port] [-S program]
- [[user@]host1:]file1 [...] [[user@]host2:]file2
-
-DESCRIPTION
- scp copies files between hosts on a network. It uses ssh(1) for data
- transfer, and uses the same authentication and provides the same security
- as ssh(1). Unlike rcp(1), scp will ask for passwords or passphrases if
- they are needed for authentication.
-
- Any file name may contain a host and user specification to indicate that
- the file is to be copied to/from that host. Copies between two remote
- hosts are permitted.
-
- The options are as follows:
-
- -1 Forces scp to use protocol 1.
-
- -2 Forces scp to use protocol 2.
-
- -4 Forces scp to use IPv4 addresses only.
-
- -6 Forces scp to use IPv6 addresses only.
-
- -B Selects batch mode (prevents asking for passwords or passphras-
- es).
-
- -C Compression enable. Passes the -C flag to ssh(1) to enable com-
- pression.
-
- -c cipher
- Selects the cipher to use for encrypting the data transfer. This
- option is directly passed to ssh(1).
-
- -F ssh_config
- Specifies an alternative per-user configuration file for ssh.
- This option is directly passed to ssh(1).
-
- -i identity_file
- Selects the file from which the identity (private key) for RSA
- authentication is read. This option is directly passed to
- ssh(1).
-
- -l limit
- Limits the used bandwidth, specified in Kbit/s.
-
- -o ssh_option
- Can be used to pass options to ssh in the format used in
- ssh_config(5). This is useful for specifying options for which
- there is no separate scp command-line flag. For full details of
- the options listed below, and their possible values, see
- ssh_config(5).
-
- AddressFamily
- BatchMode
- BindAddress
- ChallengeResponseAuthentication
- CheckHostIP
- Cipher
- Ciphers
- Compression
- CompressionLevel
- ConnectionAttempts
- ConnectTimeout
- ControlMaster
- ControlPath
- GlobalKnownHostsFile
- GSSAPIAuthentication
- GSSAPIDelegateCredentials
- HashKnownHosts
- Host
- HostbasedAuthentication
- HostKeyAlgorithms
- HostKeyAlias
- HostName
- IdentityFile
- IdentitiesOnly
- KbdInteractiveDevices
- LogLevel
- MACs
- NoHostAuthenticationForLocalhost
- NumberOfPasswordPrompts
- PasswordAuthentication
- Port
- PreferredAuthentications
- Protocol
- ProxyCommand
- PubkeyAuthentication
- RekeyLimit
- RhostsRSAAuthentication
- RSAAuthentication
- SendEnv
- ServerAliveInterval
- ServerAliveCountMax
- SmartcardDevice
- StrictHostKeyChecking
- TCPKeepAlive
- UsePrivilegedPort
- User
- UserKnownHostsFile
- VerifyHostKeyDNS
-
- -P port
- Specifies the port to connect to on the remote host. Note that
- this option is written with a capital `P', because -p is already
- reserved for preserving the times and modes of the file in
- rcp(1).
-
- -p Preserves modification times, access times, and modes from the
- original file.
-
- -q Disables the progress meter.
-
- -r Recursively copy entire directories.
-
- -S program
- Name of program to use for the encrypted connection. The program
- must understand ssh(1) options.
-
- -v Verbose mode. Causes scp and ssh(1) to print debugging messages
- about their progress. This is helpful in debugging connection,
- authentication, and configuration problems.
-
- The scp utility exits 0 on success, and >0 if an error occurs.
-
-SEE ALSO
- rcp(1), sftp(1), ssh(1), ssh-add(1), ssh-agent(1), ssh-keygen(1),
- ssh_config(5), sshd(8)
-
-HISTORY
- scp is based on the rcp(1) program in BSD source code from the Regents of
- the University of California.
-
-AUTHORS
- Timo Rinne <tri@iki.fi>
- Tatu Ylonen <ylo@cs.hut.fi>
-
-OpenBSD 4.0 September 25, 1999 3
+++ /dev/null
-SFTP-SERVER(8) OpenBSD System Manager's Manual SFTP-SERVER(8)
-
-NAME
- sftp-server - SFTP server subsystem
-
-SYNOPSIS
- sftp-server [-f log_facility] [-l log_level]
-
-DESCRIPTION
- sftp-server is a program that speaks the server side of SFTP protocol to
- stdout and expects client requests from stdin. sftp-server is not in-
- tended to be called directly, but from sshd(8) using the Subsystem op-
- tion.
-
- Command-line flags to sftp-server should be specified in the Subsystem
- declaration. See sshd_config(5) for more information.
-
- Valid options are:
-
- -f log_facility
- Specifies the facility code that is used when logging messages
- from sftp-server. The possible values are: DAEMON, USER, AUTH,
- LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7.
- The default is AUTH.
-
- -l log_level
- Specifies which messages will be logged by sftp-server. The pos-
- sible values are: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DE-
- BUG1, DEBUG2, and DEBUG3. INFO and VERBOSE log transactions that
- sftp-server performs on behalf of the client. DEBUG and DEBUG1
- are equivalent. DEBUG2 and DEBUG3 each specify higher levels of
- debugging output. The default is ERROR.
-
-SEE ALSO
- sftp(1), ssh(1), sshd_config(5), sshd(8)
-
- T. Ylonen and S. Lehtinen, SSH File Transfer Protocol, draft-ietf-secsh-
- filexfer-00.txt, January 2001, work in progress material.
-
-HISTORY
- sftp-server first appeared in OpenBSD 2.8.
-
-AUTHORS
- Markus Friedl <markus@openbsd.org>
-
-OpenBSD 4.0 August 30, 2000 1
+++ /dev/null
-SFTP(1) OpenBSD Reference Manual SFTP(1)
-
-NAME
- sftp - secure file transfer program
-
-SYNOPSIS
- sftp [-1Cv] [-B buffer_size] [-b batchfile] [-F ssh_config]
- [-o ssh_option] [-P sftp_server_path] [-R num_requests] [-S program]
- [-s subsystem | sftp_server] host
- sftp [[user@]host[:file [file]]]
- sftp [[user@]host[:dir[/]]]
- sftp -b batchfile [user@]host
-
-DESCRIPTION
- sftp is an interactive file transfer program, similar to ftp(1), which
- performs all operations over an encrypted ssh(1) transport. It may also
- use many features of ssh, such as public key authentication and compres-
- sion. sftp connects and logs into the specified host, then enters an in-
- teractive command mode.
-
- The second usage format will retrieve files automatically if a non-inter-
- active authentication method is used; otherwise it will do so after suc-
- cessful interactive authentication.
-
- The third usage format allows sftp to start in a remote directory.
-
- The final usage format allows for automated sessions using the -b option.
- In such cases, it is necessary to configure non-interactive authentica-
- tion to obviate the need to enter a password at connection time (see
- sshd(8) and ssh-keygen(1) for details). The options are as follows:
-
- -1 Specify the use of protocol version 1.
-
- -B buffer_size
- Specify the size of the buffer that sftp uses when transferring
- files. Larger buffers require fewer round trips at the cost of
- higher memory consumption. The default is 32768 bytes.
-
- -b batchfile
- Batch mode reads a series of commands from an input batchfile in-
- stead of stdin. Since it lacks user interaction it should be
- used in conjunction with non-interactive authentication. A
- batchfile of `-' may be used to indicate standard input. sftp
- will abort if any of the following commands fail: get, put,
- rename, ln, rm, mkdir, chdir, ls, lchdir, chmod, chown, chgrp,
- lpwd and lmkdir. Termination on error can be suppressed on a
- command by command basis by prefixing the command with a `-'
- character (for example, -rm /tmp/blah*).
-
- -C Enables compression (via ssh's -C flag).
-
- -F ssh_config
- Specifies an alternative per-user configuration file for ssh(1).
- This option is directly passed to ssh(1).
-
- -o ssh_option
- Can be used to pass options to ssh in the format used in
- ssh_config(5). This is useful for specifying options for which
- there is no separate sftp command-line flag. For example, to
- specify an alternate port use: sftp -oPort=24. For full details
- of the options listed below, and their possible values, see
- ssh_config(5).
-
- AddressFamily
- BatchMode
- BindAddress
- ChallengeResponseAuthentication
- CheckHostIP
- Cipher
- Ciphers
- Compression
- CompressionLevel
- ConnectionAttempts
- ConnectTimeout
- ControlMaster
- ControlPath
- GlobalKnownHostsFile
- GSSAPIAuthentication
- GSSAPIDelegateCredentials
- HashKnownHosts
- Host
- HostbasedAuthentication
- HostKeyAlgorithms
- HostKeyAlias
- HostName
- IdentityFile
- IdentitiesOnly
- KbdInteractiveDevices
- LogLevel
- MACs
- NoHostAuthenticationForLocalhost
- NumberOfPasswordPrompts
- PasswordAuthentication
- Port
- PreferredAuthentications
- Protocol
- ProxyCommand
- PubkeyAuthentication
- RekeyLimit
- RhostsRSAAuthentication
- RSAAuthentication
- SendEnv
- ServerAliveInterval
- ServerAliveCountMax
- SmartcardDevice
- StrictHostKeyChecking
- TCPKeepAlive
- UsePrivilegedPort
- User
- UserKnownHostsFile
- VerifyHostKeyDNS
-
- -P sftp_server_path
- Connect directly to a local sftp server (rather than via ssh(1)).
- This option may be useful in debugging the client and server.
-
- -R num_requests
- Specify how many requests may be outstanding at any one time.
- Increasing this may slightly improve file transfer speed but will
- increase memory usage. The default is 16 outstanding requests.
-
- -S program
- Name of the program to use for the encrypted connection. The
- program must understand ssh(1) options.
-
- -s subsystem | sftp_server
- Specifies the SSH2 subsystem or the path for an sftp server on
- the remote host. A path is useful for using sftp over protocol
- version 1, or when the remote sshd(8) does not have an sftp sub-
- system configured.
-
- -v Raise logging level. This option is also passed to ssh.
-
-INTERACTIVE COMMANDS
- Once in interactive mode, sftp understands a set of commands similar to
- those of ftp(1). Commands are case insensitive. Pathnames that contain
- spaces must be enclosed in quotes. Any special characters contained
- within pathnames that are recognized by glob(3) must be escaped with
- backslashes (`\').
-
- bye Quit sftp.
-
- cd path
- Change remote directory to path.
-
- chgrp grp path
- Change group of file path to grp. path may contain glob(3) char-
- acters and may match multiple files. grp must be a numeric GID.
-
- chmod mode path
- Change permissions of file path to mode. path may contain
- glob(3) characters and may match multiple files.
-
- chown own path
- Change owner of file path to own. path may contain glob(3) char-
- acters and may match multiple files. own must be a numeric UID.
-
- exit Quit sftp.
-
- get [-P] remote-path [local-path]
- Retrieve the remote-path and store it on the local machine. If
- the local path name is not specified, it is given the same name
- it has on the remote machine. remote-path may contain glob(3)
- characters and may match multiple files. If it does and local-
- path is specified, then local-path must specify a directory. If
- the -P flag is specified, then full file permissions and access
- times are copied too.
-
- help Display help text.
-
- lcd path
- Change local directory to path.
-
- lls [ls-options [path]]
- Display local directory listing of either path or current direc-
- tory if path is not specified. ls-options may contain any flags
- supported by the local system's ls(1) command. path may contain
- glob(3) characters and may match multiple files.
-
- lmkdir path
- Create local directory specified by path.
-
- ln oldpath newpath
- Create a symbolic link from oldpath to newpath.
-
- lpwd Print local working directory.
-
- ls [-1aflnrSt] [path]
- Display a remote directory listing of either path or the current
- directory if path is not specified. path may contain glob(3)
- characters and may match multiple files.
-
- The following flags are recognized and alter the behaviour of ls
- accordingly:
-
- -1 Produce single columnar output.
-
- -a List files beginning with a dot (`.').
-
- -f Do not sort the listing. The default sort order is lexi-
- cographical.
-
- -l Display additional details including permissions and own-
- ership information.
-
- -n Produce a long listing with user and group information
- presented numerically.
-
- -r Reverse the sort order of the listing.
-
- -S Sort the listing by file size.
-
- -t Sort the listing by last modification time.
-
- lumask umask
- Set local umask to umask.
-
- mkdir path
- Create remote directory specified by path.
-
- progress
- Toggle display of progress meter.
-
- put [-P] local-path [remote-path]
- Upload local-path and store it on the remote machine. If the re-
- mote path name is not specified, it is given the same name it has
- on the local machine. local-path may contain glob(3) characters
- and may match multiple files. If it does and remote-path is
- specified, then remote-path must specify a directory. If the -P
- flag is specified, then the file's full permission and access
- time are copied too.
-
- pwd Display remote working directory.
-
- quit Quit sftp.
-
- rename oldpath newpath
- Rename remote file from oldpath to newpath.
-
- rm path
- Delete remote file specified by path.
-
- rmdir path
- Remove remote directory specified by path.
-
- symlink oldpath newpath
- Create a symbolic link from oldpath to newpath.
-
- version
- Display the sftp protocol version.
-
- ! command
- Execute command in local shell.
-
- ! Escape to local shell.
-
- ? Synonym for help.
-
-SEE ALSO
- ftp(1), ls(1), scp(1), ssh(1), ssh-add(1), ssh-keygen(1), glob(3),
- ssh_config(5), sftp-server(8), sshd(8)
-
- T. Ylonen and S. Lehtinen, SSH File Transfer Protocol, draft-ietf-secsh-
- filexfer-00.txt, January 2001, work in progress material.
-
-OpenBSD 4.0 February 4, 2001 4
+++ /dev/null
-SSH-ADD(1) OpenBSD Reference Manual SSH-ADD(1)
-
-NAME
- ssh-add - adds RSA or DSA identities to the authentication agent
-
-SYNOPSIS
- ssh-add [-cDdLlXx] [-t life] [file ...]
- ssh-add -s reader
- ssh-add -e reader
-
-DESCRIPTION
- ssh-add adds RSA or DSA identities to the authentication agent,
- ssh-agent(1). When run without arguments, it adds the files
- ~/.ssh/id_rsa, ~/.ssh/id_dsa and ~/.ssh/identity. Alternative file names
- can be given on the command line. If any file requires a passphrase,
- ssh-add asks for the passphrase from the user. The passphrase is read
- from the user's tty. ssh-add retries the last passphrase if multiple
- identity files are given.
-
- The authentication agent must be running and the SSH_AUTH_SOCK environ-
- ment variable must contain the name of its socket for ssh-add to work.
-
- The options are as follows:
-
- -c Indicates that added identities should be subject to confirmation
- before being used for authentication. Confirmation is performed
- by the SSH_ASKPASS program mentioned below. Successful confirma-
- tion is signaled by a zero exit status from the SSH_ASKPASS pro-
- gram, rather than text entered into the requester.
-
- -D Deletes all identities from the agent.
-
- -d Instead of adding the identity, removes the identity from the
- agent.
-
- -e reader
- Remove key in smartcard reader.
-
- -L Lists public key parameters of all identities currently repre-
- sented by the agent.
-
- -l Lists fingerprints of all identities currently represented by the
- agent.
-
- -s reader
- Add key in smartcard reader.
-
- -t life
- Set a maximum lifetime when adding identities to an agent. The
- lifetime may be specified in seconds or in a time format speci-
- fied in sshd_config(5).
-
- -X Unlock the agent.
-
- -x Lock the agent with a password.
-
-ENVIRONMENT
- DISPLAY and SSH_ASKPASS
- If ssh-add needs a passphrase, it will read the passphrase from
- the current terminal if it was run from a terminal. If ssh-add
- does not have a terminal associated with it but DISPLAY and
- SSH_ASKPASS are set, it will execute the program specified by
- SSH_ASKPASS and open an X11 window to read the passphrase. This
- is particularly useful when calling ssh-add from a .xsession or
- related script. (Note that on some machines it may be necessary
- to redirect the input from /dev/null to make this work.)
-
- SSH_AUTH_SOCK
- Identifies the path of a unix-domain socket used to communicate
- with the agent.
-
-FILES
- ~/.ssh/identity
- Contains the protocol version 1 RSA authentication identity of
- the user.
-
- ~/.ssh/id_dsa
- Contains the protocol version 2 DSA authentication identity of
- the user.
-
- ~/.ssh/id_rsa
- Contains the protocol version 2 RSA authentication identity of
- the user.
-
- Identity files should not be readable by anyone but the user. Note that
- ssh-add ignores identity files if they are accessible by others.
-
-DIAGNOSTICS
- Exit status is 0 on success, 1 if the specified command fails, and 2 if
- ssh-add is unable to contact the authentication agent.
-
-SEE ALSO
- ssh(1), ssh-agent(1), ssh-keygen(1), sshd(8)
-
-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 cre-
- ated OpenSSH. Markus Friedl contributed the support for SSH protocol
- versions 1.5 and 2.0.
-
-OpenBSD 4.0 September 25, 1999 2
+++ /dev/null
-SSH-AGENT(1) OpenBSD Reference Manual SSH-AGENT(1)
-
-NAME
- ssh-agent - authentication agent
-
-SYNOPSIS
- ssh-agent [-a bind_address] [-c | -s] [-t life] [-d] [command [args ...]]
- ssh-agent [-c | -s] -k
-
-DESCRIPTION
- ssh-agent is a program to hold private keys used for public key authenti-
- cation (RSA, DSA). The idea is that ssh-agent is started in the begin-
- ning of an X-session or a login session, and all other windows or pro-
- grams are started as clients to the ssh-agent program. Through use of
- environment variables the agent can be located and automatically used for
- authentication when logging in to other machines using ssh(1).
-
- The options are as follows:
-
- -a bind_address
- Bind the agent to the unix-domain socket bind_address. The de-
- fault is /tmp/ssh-XXXXXXXXXX/agent.<ppid>.
-
- -c Generate C-shell commands on stdout. This is the default if
- SHELL looks like it's a csh style of shell.
-
- -s Generate Bourne shell commands on stdout. This is the default if
- SHELL does not look like it's a csh style of shell.
-
- -k Kill the current agent (given by the SSH_AGENT_PID environment
- variable).
-
- -t life
- Set a default value for the maximum lifetime of identities added
- to the agent. The lifetime may be specified in seconds or in a
- time format specified in sshd_config(5). A lifetime specified
- for an identity with ssh-add(1) overrides this value. Without
- this option the default maximum lifetime is forever.
-
- -d Debug mode. When this option is specified ssh-agent will not
- fork.
-
- If a commandline is given, this is executed as a subprocess of the agent.
- When the command dies, so does the agent.
-
- The agent initially does not have any private keys. Keys are added using
- ssh-add(1). When executed without arguments, ssh-add(1) adds the files
- ~/.ssh/id_rsa, ~/.ssh/id_dsa and ~/.ssh/identity. If the identity has a
- passphrase, ssh-add(1) asks for the passphrase (using a small X11 appli-
- cation if running under X11, or from the terminal if running without X).
- It then sends the identity to the agent. Several identities can be
- stored in the agent; the agent can automatically use any of these identi-
- ties. ssh-add -l displays the identities currently held by the agent.
-
- The idea is that the agent is run in the user's local PC, laptop, or ter-
- minal. Authentication data need not be stored on any other machine, and
- authentication passphrases never go over the network. However, the con-
- nection to the agent is forwarded over SSH remote logins, and the user
- can thus use the privileges given by the identities anywhere in the net-
- work in a secure way.
-
- There are two main ways to get an agent set up: The first is that the
- agent starts a new subcommand into which some environment variables are
- exported, eg ssh-agent xterm &. The second is that the agent prints the
- needed shell commands (either sh(1) or csh(1) syntax can be generated)
- which can be evalled in the calling shell, eg eval `ssh-agent -s` for
- Bourne-type shells such as sh(1) or ksh(1) and eval `ssh-agent -c` for
- csh(1) and derivatives.
-
- Later ssh(1) looks at these variables and uses them to establish a con-
- nection to the agent.
-
- The agent will never send a private key over its request channel. In-
- stead, operations that require a private key will be performed by the
- agent, and the result will be returned to the requester. This way, pri-
- vate keys are not exposed to clients using the agent.
-
- A unix-domain socket is created and the name of this socket is stored in
- the SSH_AUTH_SOCK environment variable. The socket is made accessible
- only to the current user. This method is easily abused by root or anoth-
- er instance of the same user.
-
- The SSH_AGENT_PID environment variable holds the agent's process ID.
-
- The agent exits automatically when the command given on the command line
- terminates.
-
-FILES
- ~/.ssh/identity
- Contains the protocol version 1 RSA authentication identity of
- the user.
-
- ~/.ssh/id_dsa
- Contains the protocol version 2 DSA authentication identity of
- the user.
-
- ~/.ssh/id_rsa
- Contains the protocol version 2 RSA authentication identity of
- the user.
-
- /tmp/ssh-XXXXXXXXXX/agent.<ppid>
- Unix-domain sockets used to contain the connection to the authen-
- tication agent. These sockets should only be readable by the
- owner. The sockets should get automatically removed when the
- agent exits.
-
-SEE ALSO
- ssh(1), ssh-add(1), ssh-keygen(1), sshd(8)
-
-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 cre-
- ated OpenSSH. Markus Friedl contributed the support for SSH protocol
- versions 1.5 and 2.0.
-
-OpenBSD 4.0 September 25, 1999 2
+++ /dev/null
-SSH-KEYGEN(1) OpenBSD Reference Manual SSH-KEYGEN(1)
-
-NAME
- ssh-keygen - authentication key generation, management and conversion
-
-SYNOPSIS
- ssh-keygen [-q] [-b bits] -t type [-N new_passphrase] [-C comment]
- [-f output_keyfile]
- ssh-keygen -p [-P old_passphrase] [-N new_passphrase] [-f keyfile]
- ssh-keygen -i [-f input_keyfile]
- ssh-keygen -e [-f input_keyfile]
- ssh-keygen -y [-f input_keyfile]
- ssh-keygen -c [-P passphrase] [-C comment] [-f keyfile]
- ssh-keygen -l [-f input_keyfile]
- ssh-keygen -B [-f input_keyfile]
- ssh-keygen -D reader
- ssh-keygen -F hostname [-f known_hosts_file]
- ssh-keygen -H [-f known_hosts_file]
- ssh-keygen -R hostname [-f known_hosts_file]
- ssh-keygen -U reader [-f input_keyfile]
- ssh-keygen -r hostname [-f input_keyfile] [-g]
- ssh-keygen -G output_file [-v] [-b bits] [-M memory] [-S start_point]
- ssh-keygen -T output_file -f input_file [-v] [-a num_trials] [-W
- generator]
-
-DESCRIPTION
- ssh-keygen generates, manages and converts authentication keys for
- ssh(1). ssh-keygen can create RSA keys for use by SSH protocol version 1
- and RSA or DSA keys for use by SSH protocol version 2. The type of key
- to be generated is specified with the -t option. If invoked without any
- arguments, ssh-keygen will generate an RSA key for use in SSH protocol 2
- connections.
-
- ssh-keygen is also used to generate groups for use in Diffie-Hellman
- group exchange (DH-GEX). See the MODULI GENERATION section for details.
-
- Normally each user wishing to use SSH with RSA or DSA authentication runs
- this once to create the authentication key in ~/.ssh/identity,
- ~/.ssh/id_dsa or ~/.ssh/id_rsa. Additionally, the system administrator
- may use this to generate host keys, as seen in /etc/rc.
-
- Normally this program generates the key and asks for a file in which to
- store the private key. The public key is stored in a file with the same
- name but ``.pub'' appended. The program also asks for a passphrase. The
- passphrase may be empty to indicate no passphrase (host keys must have an
- empty passphrase), or it may be a string of arbitrary length. A
- passphrase is similar to a password, except it can be a phrase with a se-
- ries of words, punctuation, numbers, whitespace, or any string of charac-
- ters you want. Good passphrases are 10-30 characters long, are not sim-
- ple sentences or otherwise easily guessable (English prose has only 1-2
- bits of entropy per character, and provides very bad passphrases), and
- contain a mix of upper and lowercase letters, numbers, and non-alphanu-
- meric characters. The passphrase can be changed later by using the -p
- option.
-
- There is no way to recover a lost passphrase. If the passphrase is lost
- or forgotten, a new key must be generated and copied to the corresponding
- public key to other machines.
-
- For RSA1 keys, there is also a comment field in the key file that is only
- for convenience to the user to help identify the key. The comment can
- tell what the key is for, or whatever is useful. The comment is initial-
- ized to ``user@host'' when the key is created, but can be changed using
- the -c option.
-
- After a key is generated, instructions below detail where the keys should
- be placed to be activated.
-
- The options are as follows:
-
- -a trials
- Specifies the number of primality tests to perform when screening
- DH-GEX candidates using the -T command.
-
- -B Show the bubblebabble digest of specified private or public key
- file.
-
- -b bits
- Specifies the number of bits in the key to create. For RSA keys,
- the minimum size is 768 bits and the default is 2048 bits. Gen-
- erally, 2048 bits is considered sufficient. DSA keys must be ex-
- actly 1024 bits as specified by FIPS 186-2.
-
- -C comment
- Provides a new comment.
-
- -c Requests changing the comment in the private and public key
- files. This operation is only supported for RSA1 keys. The pro-
- gram will prompt for the file containing the private keys, for
- the passphrase if the key has one, and for the new comment.
-
- -D reader
- Download the RSA public key stored in the smartcard in reader.
-
- -e This option will read a private or public OpenSSH key file and
- print the key in a `SECSH Public Key File Format' to stdout.
- This option allows exporting keys for use by several commercial
- SSH implementations.
-
- -F hostname
- Search for the specified hostname in a known_hosts file, listing
- any occurrences found. This option is useful to find hashed host
- names or addresses and may also be used in conjunction with the
- -H option to print found keys in a hashed format.
-
- -f filename
- Specifies the filename of the key file.
-
- -G output_file
- Generate candidate primes for DH-GEX. These primes must be
- screened for safety (using the -T option) before use.
-
- -g Use generic DNS format when printing fingerprint resource records
- using the -r command.
-
- -H Hash a known_hosts file. This replaces all hostnames and ad-
- dresses with hashed representations within the specified file;
- the original content is moved to a file with a .old suffix.
- These hashes may be used normally by ssh and sshd, but they do
- not reveal identifying information should the file's contents be
- disclosed. This option will not modify existing hashed hostnames
- and is therefore safe to use on files that mix hashed and non-
- hashed names.
-
- -i This option will read an unencrypted private (or public) key file
- in SSH2-compatible format and print an OpenSSH compatible private
- (or public) key to stdout. ssh-keygen also reads the `SECSH
- Public Key File Format'. This option allows importing keys from
- several commercial SSH implementations.
-
- -l Show fingerprint of specified public key file. Private RSA1 keys
- are also supported. For RSA and DSA keys ssh-keygen tries to
- find the matching public key file and prints its fingerprint.
-
- -M memory
- Specify the amount of memory to use (in megabytes) when generat-
- ing candidate moduli for DH-GEX.
-
- -N new_passphrase
- Provides the new passphrase.
-
- -P passphrase
- Provides the (old) passphrase.
-
- -p Requests changing the passphrase of a private key file instead of
- creating a new private key. The program will prompt for the file
- containing the private key, for the old passphrase, and twice for
- the new passphrase.
-
- -q Silence ssh-keygen. Used by /etc/rc when creating a new key.
-
- -R hostname
- Removes all keys belonging to hostname from a known_hosts file.
- This option is useful to delete hashed hosts (see the -H option
- above).
-
- -r hostname
- Print the SSHFP fingerprint resource record named hostname for
- the specified public key file.
-
- -S start
- Specify start point (in hex) when generating candidate moduli for
- DH-GEX.
-
- -T output_file
- Test DH group exchange candidate primes (generated using the -G
- option) for safety.
-
- -t type
- Specifies the type of key to create. The possible values are
- ``rsa1'' for protocol version 1 and ``rsa'' or ``dsa'' for proto-
- col version 2.
-
- -U reader
- Upload an existing RSA private key into the smartcard in reader.
-
- -v Verbose mode. Causes ssh-keygen to print debugging messages
- about its progress. This is helpful for debugging moduli genera-
- tion. Multiple -v options increase the verbosity. The maximum
- is 3.
-
- -W generator
- Specify desired generator when testing candidate moduli for DH-
- GEX.
-
- -y This option will read a private OpenSSH format file and print an
- OpenSSH public key to stdout.
-
-MODULI GENERATION
- ssh-keygen may be used to generate groups for the Diffie-Hellman Group
- Exchange (DH-GEX) protocol. Generating these groups is a two-step pro-
- cess: first, candidate primes are generated using a fast, but memory in-
- tensive process. These candidate primes are then tested for suitability
- (a CPU-intensive process).
-
- Generation of primes is performed using the -G option. The desired
- length of the primes may be specified by the -b option. For example:
-
- # ssh-keygen -G moduli-2048.candidates -b 2048
-
- By default, the search for primes begins at a random point in the desired
- length range. This may be overridden using the -S option, which speci-
- fies a different start point (in hex).
-
- Once a set of candidates have been generated, they must be tested for
- suitability. This may be performed using the -T option. In this mode
- ssh-keygen will read candidates from standard input (or a file specified
- using the -f option). For example:
-
- # ssh-keygen -T moduli-2048 -f moduli-2048.candidates
-
- By default, each candidate will be subjected to 100 primality tests.
- This may be overridden using the -a option. The DH generator value will
- be chosen automatically for the prime under consideration. If a specific
- generator is desired, it may be requested using the -W option. Valid
- generator values are 2, 3, and 5.
-
- Screened DH groups may be installed in /etc/moduli. It is important that
- this file contains moduli of a range of bit lengths and that both ends of
- a connection share common moduli.
-
-FILES
- ~/.ssh/identity
- Contains the protocol version 1 RSA authentication identity of
- the user. This file should not be readable by anyone but the us-
- er. It is possible to specify a passphrase when generating the
- key; that passphrase will be used to encrypt the private part of
- this file using 3DES. This file is not automatically accessed by
- ssh-keygen but it is offered as the default file for the private
- key. ssh(1) will read this file when a login attempt is made.
-
- ~/.ssh/identity.pub
- Contains the protocol version 1 RSA public key for authentica-
- tion. The contents of this file should be added to
- ~/.ssh/authorized_keys on all machines where the user wishes to
- log in using RSA authentication. There is no need to keep the
- contents of this file secret.
-
- ~/.ssh/id_dsa
- Contains the protocol version 2 DSA authentication identity of
- the user. This file should not be readable by anyone but the us-
- er. It is possible to specify a passphrase when generating the
- key; that passphrase will be used to encrypt the private part of
- this file using 3DES. This file is not automatically accessed by
- ssh-keygen but it is offered as the default file for the private
- key. ssh(1) will read this file when a login attempt is made.
-
- ~/.ssh/id_dsa.pub
- Contains the protocol version 2 DSA public key for authentica-
- tion. The contents of this file should be added to
- ~/.ssh/authorized_keys on all machines where the user wishes to
- log in using public key authentication. There is no need to keep
- the contents of this file secret.
-
- ~/.ssh/id_rsa
- Contains the protocol version 2 RSA authentication identity of
- the user. This file should not be readable by anyone but the us-
- er. It is possible to specify a passphrase when generating the
- key; that passphrase will be used to encrypt the private part of
- this file using 3DES. This file is not automatically accessed by
- ssh-keygen but it is offered as the default file for the private
- key. ssh(1) will read this file when a login attempt is made.
-
- ~/.ssh/id_rsa.pub
- Contains the protocol version 2 RSA public key for authentica-
- tion. The contents of this file should be added to
- ~/.ssh/authorized_keys on all machines where the user wishes to
- log in using public key authentication. There is no need to keep
- the contents of this file secret.
-
- /etc/moduli
- Contains Diffie-Hellman groups used for DH-GEX. The file format
- is described in moduli(5).
-
-SEE ALSO
- ssh(1), ssh-add(1), ssh-agent(1), moduli(5), sshd(8)
-
- J. Galbraith and R. Thayer, SECSH Public Key File Format, draft-ietf-
- secsh-publickeyfile-01.txt, March 2001, work in progress material.
-
-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.
-
-OpenBSD 4.0 September 25, 1999 5
+++ /dev/null
-SSH-KEYSCAN(1) OpenBSD Reference Manual SSH-KEYSCAN(1)
-
-NAME
- ssh-keyscan - gather ssh public keys
-
-SYNOPSIS
- ssh-keyscan [-46Hv] [-f file] [-p port] [-T timeout] [-t type]
- [host | addrlist namelist] [...]
-
-DESCRIPTION
- ssh-keyscan is a utility for gathering the public ssh host keys of a num-
- ber of hosts. It was designed to aid in building and verifying
- ssh_known_hosts files. ssh-keyscan provides a minimal interface suitable
- for use by shell and perl scripts.
-
- ssh-keyscan uses non-blocking socket I/O to contact as many hosts as pos-
- sible in parallel, so it is very efficient. The keys from a domain of
- 1,000 hosts can be collected in tens of seconds, even when some of those
- hosts are down or do not run ssh. For scanning, one does not need login
- access to the machines that are being scanned, nor does the scanning pro-
- cess involve any encryption.
-
- The options are as follows:
-
- -4 Forces ssh-keyscan to use IPv4 addresses only.
-
- -6 Forces ssh-keyscan to use IPv6 addresses only.
-
- -f file
- Read hosts or addrlist namelist pairs from this file, one per
- line. If - is supplied instead of a filename, ssh-keyscan will
- read hosts or addrlist namelist pairs from the standard input.
-
- -H Hash all hostnames and addresses in the output. Hashed names may
- be used normally by ssh and sshd, but they do not reveal identi-
- fying information should the file's contents be disclosed.
-
- -p port
- Port to connect to on the remote host.
-
- -T timeout
- Set the timeout for connection attempts. If timeout seconds have
- elapsed since a connection was initiated to a host or since the
- last time anything was read from that host, then the connection
- is closed and the host in question considered unavailable. De-
- fault is 5 seconds.
-
- -t type
- Specifies the type of the key to fetch from the scanned hosts.
- The possible values are ``rsa1'' for protocol version 1 and
- ``rsa'' or ``dsa'' for protocol version 2. Multiple values may
- be specified by separating them with commas. The default is
- ``rsa1''.
-
- -v Verbose mode. Causes ssh-keyscan to print debugging messages
- about its progress.
-
-SECURITY
- If a ssh_known_hosts file is constructed using ssh-keyscan without veri-
- fying the keys, users will be vulnerable to man in the middle attacks.
- On the other hand, if the security model allows such a risk, ssh-keyscan
- can help in the detection of tampered keyfiles or man in the middle at-
- tacks which have begun after the ssh_known_hosts file was created.
-
-FILES
- Input format:
-
- 1.2.3.4,1.2.4.4 name.my.domain,name,n.my.domain,n,1.2.3.4,1.2.4.4
-
- Output format for rsa1 keys:
-
- host-or-namelist bits exponent modulus
-
- Output format for rsa and dsa keys:
-
- host-or-namelist keytype base64-encoded-key
-
- Where keytype is either ``ssh-rsa'' or ``ssh-dss''.
-
- /etc/ssh/ssh_known_hosts
-
-EXAMPLES
- Print the rsa1 host key for machine hostname:
-
- $ ssh-keyscan hostname
-
- Find all hosts from the file ssh_hosts which have new or different keys
- from those in the sorted file ssh_known_hosts:
-
- $ ssh-keyscan -t rsa,dsa -f ssh_hosts | \
- sort -u - ssh_known_hosts | diff ssh_known_hosts -
-
-SEE ALSO
- ssh(1), sshd(8)
-
-AUTHORS
- David Mazieres <dm@lcs.mit.edu> wrote the initial version, and Wayne
- Davison <wayned@users.sourceforge.net> added support for protocol version
- 2.
-
-BUGS
- It generates "Connection closed by remote host" messages on the consoles
- of all the machines it scans if the server is older than version 2.9.
- This is because it opens a connection to the ssh port, reads the public
- key, and drops the connection as soon as it gets the key.
-
-OpenBSD 4.0 January 1, 1996 2
+++ /dev/null
-SSH-KEYSIGN(8) OpenBSD System Manager's Manual SSH-KEYSIGN(8)
-
-NAME
- ssh-keysign - ssh helper program for host-based authentication
-
-SYNOPSIS
- ssh-keysign
-
-DESCRIPTION
- ssh-keysign is used by ssh(1) to access the local host keys and generate
- the digital signature required during host-based authentication with SSH
- protocol version 2.
-
- ssh-keysign is disabled by default and can only be enabled in the global
- client configuration file /etc/ssh/ssh_config by setting EnableSSHKeysign
- to ``yes''.
-
- ssh-keysign is not intended to be invoked by the user, but from ssh(1).
- See ssh(1) and sshd(8) for more information about host-based authentica-
- tion.
-
-FILES
- /etc/ssh/ssh_config
- Controls whether ssh-keysign is enabled.
-
- /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_rsa_key
- These files contain the private parts of the host keys used to
- generate the digital signature. They should be owned by root,
- readable only by root, and not accessible to others. Since they
- are readable only by root, ssh-keysign must be set-uid root if
- host-based authentication is used.
-
-SEE ALSO
- ssh(1), ssh-keygen(1), ssh_config(5), sshd(8)
-
-HISTORY
- ssh-keysign first appeared in OpenBSD 3.2.
-
-AUTHORS
- Markus Friedl <markus@openbsd.org>
-
-OpenBSD 4.0 May 24, 2002 1
+++ /dev/null
-SSH-RAND-HELPER(8) OpenBSD System Manager's Manual SSH-RAND-HELPER(8)
-
-NAME
- ssh-rand-helper - Random number gatherer for OpenSSH
-
-SYNOPSIS
- ssh-rand-hlper [-vxXh] [-b bytes]
-
-DESCRIPTION
- ssh-rand-helper is a small helper program used by ssh(1), ssh-add(1),
- ssh-agent(1), ssh-keygen(1), ssh-keyscan(1) and sshd(8) to gather random
- numbers of cryptographic quality if the openssl(4) library has not been
- configured to provide them itself.
-
- Normally ssh-rand-helper will generate a strong random seed and provide
- it to the calling program via standard output. If standard output is a
- tty, ssh-rand-helper will instead print the seed in hexidecimal format
- unless told otherwise.
-
- ssh-rand-helper will by default gather random numbers from the system
- commands listed in /etc/ssh/ssh_prng_cmds. The output of each of the
- commands listed will be hashed and used to generate a random seed for the
- calling program. ssh-rand-helper will also store seed files in
- ~/.ssh/prng_seed between executions.
-
- Alternately, ssh-rand-helper may be configured at build time to collect
- random numbers from a EGD/PRNGd server via a unix domain or localhost tcp
- socket.
-
- This program is not intended to be run by the end-user, so the few com-
- mandline options are for debugging purposes only.
-
- -b bytes
- Specify the number of random bytes to include in the output.
-
- -x Output a hexidecimal instead of a binary seed.
-
- -X Force output of a binary seed, even if standard output is a tty
-
- -v Turn on debugging message. Multiple -v options will increase the
- debugging level. -h Display a summary of options.
-
-AUTHORS
- Damien Miller <djm@mindrot.org>
-
-SEE ALSO
- ssh(1), ssh-add(1), ssh-keygen(1), sshd(8)
-
-OpenBSD 4.0 April 14, 2002 1
+++ /dev/null
-SSH(1) OpenBSD Reference Manual SSH(1)
-
-NAME
- ssh - OpenSSH SSH client (remote login program)
-
-SYNOPSIS
- ssh [-1246AaCfgkMNnqsTtVvXxY] [-b bind_address] [-c cipher_spec]
- [-D [bind_address:]port] [-e escape_char] [-F configfile]
- [-i identity_file] [-L [bind_address:]port:host:hostport]
- [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
- [-R [bind_address:]port:host:hostport] [-S ctl_path]
- [-w local_tun[:remote_tun]] [user@]hostname [command]
-
-DESCRIPTION
- ssh (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 untrust-
- ed hosts over an insecure network. X11 connections and arbitrary TCP
- ports can also be forwarded over the secure channel.
-
- ssh connects and logs into the specified hostname (with optional 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 be-
- low).
-
- If command is specified, it is executed on the remote host instead of a
- login shell.
-
- The options are as follows:
-
- -1 Forces ssh to try protocol version 1 only.
-
- -2 Forces ssh to try protocol version 2 only.
-
- -4 Forces ssh to use IPv4 addresses only.
-
- -6 Forces ssh to use IPv6 addresses only.
-
- -A Enables forwarding of the authentication agent connection. This
- can also be specified on a per-host basis in a configuration
- file.
-
- 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.
-
- -a Disables forwarding of the authentication agent connection.
-
- -b bind_address
- Use bind_address on the local machine as the source address of
- the connection. Only useful on systems with more than one ad-
- dress.
-
- -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 gzip(1), and the
- ``level'' can be controlled by the 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 Compression option.
-
- -c cipher_spec
- Selects the cipher specification for encrypting the session.
-
- Protocol version 1 allows specification of a single cipher. The
- supported values are ``3des'', ``blowfish'', and ``des''. 3des
- (triple-des) is an encrypt-decrypt-encrypt triple with three dif-
- ferent keys. It is believed to be secure. blowfish is a fast
- block cipher; it appears very secure and is much faster than
- 3des. des is only supported in the ssh client for interoperabil-
- ity with legacy protocol 1 implementations that do not support
- the 3des cipher. Its use is strongly discouraged due to crypto-
- graphic weaknesses. The default is ``3des''.
-
- For protocol version 2, 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, blow-
- fish-cbc, and cast128-cbc. The default is:
-
- aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,
- arcfour256,arcfour,aes192-cbc,aes256-cbc,aes128-ctr,
- aes192-ctr,aes256-ctr
-
- -D [bind_address:]port
- Specifies a local ``dynamic'' application-level port forwarding.
- This works by allocating a socket to listen to port on the local
- side, optionally bound to the specified 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 ssh will act
- as a SOCKS server. Only root can forward privileged ports. Dy-
- namic port forwardings can also be specified in the configuration
- file.
-
- IPv6 addresses can be specified with an alternative syntax:
- [bind_address/]port or by enclosing the address in square brack-
- ets. Only the superuser can forward privileged ports. By de-
- fault, the local port is bound in accordance with the
- GatewayPorts setting. However, an explicit bind_address may be
- used to bind the connection to a specific address. The
- bind_address of ``localhost'' indicates that the listening port
- be bound for local use only, while an empty address or `*' indi-
- cates that the port should be available from all interfaces.
-
- -e escape_char
- Sets the escape character for sessions with a pty (default: `~').
- The escape character is only recognized at the beginning of a
- line. The escape character followed by a dot (`.') closes the
- connection; followed by control-Z suspends the connection; and
- followed by itself sends the escape character once. Setting the
- character to ``none'' disables any escapes and makes the session
- fully transparent.
-
- -F configfile
- Specifies an alternative per-user configuration file. If a con-
- figuration file is given on the command line, the system-wide
- configuration file (/etc/ssh/ssh_config) will be ignored. The
- default for the per-user configuration file is ~/.ssh/config.
-
- -f Requests ssh to go to background just before command execution.
- This is useful if ssh is going to ask for passwords or passphras-
- es, but the user wants it in the background. This implies -n.
- The recommended way to start X11 programs at a remote site is
- with something like ssh -f host xterm.
-
- -g Allows remote hosts to connect to local forwarded ports.
-
- -I smartcard_device
- Specify the device ssh 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 (de-
- fault is no support).
-
- -i identity_file
- Selects a file from which the identity (private key) for RSA or
- DSA authentication is read. The default is ~/.ssh/identity for
- protocol version 1, and ~/.ssh/id_rsa and ~/.ssh/id_dsa for pro-
- tocol version 2. Identity files may also be specified on a per-
- host basis in the configuration file. It is possible to have
- multiple -i options (and multiple identities specified in config-
- uration files).
-
- -k Disables forwarding (delegation) of GSSAPI credentials to the
- server.
-
- -L [bind_address:]port:host:hostport
- Specifies that the given port on the local (client) host is to be
- forwarded to the given host and port on the remote side. This
- works by allocating a socket to listen to port on the local side,
- optionally bound to the specified bind_address. Whenever a con-
- nection is made to this port, the connection is forwarded over
- the secure channel, and a connection is made to host port
- hostport from the remote machine. Port forwardings can also be
- specified in the configuration file. IPv6 addresses can be spec-
- ified with an alternative syntax: [bind_address/]port/host/host-
- port 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 GatewayPorts setting. How-
- ever, an explicit bind_address may be used to bind the connection
- to a specific address. The bind_address of ``localhost'' indi-
- cates that the listening port be bound for local use only, while
- an empty address or `*' indicates that the port should be avail-
- able from all interfaces.
-
- -l 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.
-
- -M Places the ssh client into ``master'' mode for connection shar-
- ing. Multiple -M options places ssh into ``master'' mode with
- confirmation required before slave connections are accepted. Re-
- fer to the description of ControlMaster in ssh_config(5) for de-
- tails.
-
- -m 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 MACs keyword for more information.
-
- -N Do not execute a remote command. This is useful for just for-
- warding ports (protocol version 2 only).
-
- -n Redirects stdin from /dev/null (actually, prevents reading from
- stdin). This must be used when ssh is run in the background. A
- common trick is to use this to run X11 programs on a remote ma-
- chine. For example, ssh -n shadows.cs.hut.fi emacs & will start
- an emacs on shadows.cs.hut.fi, and the X11 connection will be au-
- tomatically forwarded over an encrypted channel. The ssh program
- will be put in the background. (This does not work if ssh needs
- to ask for a password or passphrase; see also the -f option.)
-
- -O ctl_cmd
- Control an active connection multiplexing master process. When
- the -O option is specified, the ctl_cmd argument is interpreted
- and passed to the master process. Valid commands are: ``check''
- (check that the master process is running) and ``exit'' (request
- the master to exit).
-
- -o option
- Can be used to give options in the format used in the configura-
- tion file. This is useful for specifying options for which there
- is no separate command-line flag. For full details of the op-
- tions listed below, and their possible values, see ssh_config(5).
-
- AddressFamily
- BatchMode
- BindAddress
- ChallengeResponseAuthentication
- CheckHostIP
- Cipher
- Ciphers
- ClearAllForwardings
- Compression
- CompressionLevel
- ConnectionAttempts
- ConnectTimeout
- ControlMaster
- ControlPath
- DynamicForward
- EscapeChar
- ExitOnForwardFailure
- ForwardAgent
- ForwardX11
- ForwardX11Trusted
- GatewayPorts
- GlobalKnownHostsFile
- GSSAPIAuthentication
- GSSAPIDelegateCredentials
- HashKnownHosts
- Host
- HostbasedAuthentication
- HostKeyAlgorithms
- HostKeyAlias
- HostName
- IdentityFile
- IdentitiesOnly
- KbdInteractiveDevices
- LocalCommand
- LocalForward
- LogLevel
- MACs
- NoHostAuthenticationForLocalhost
- NumberOfPasswordPrompts
- PasswordAuthentication
- PermitLocalCommand
- Port
- PreferredAuthentications
- Protocol
- ProxyCommand
- PubkeyAuthentication
- RekeyLimit
- RemoteForward
- RhostsRSAAuthentication
- RSAAuthentication
- SendEnv
- ServerAliveInterval
- ServerAliveCountMax
- SmartcardDevice
- StrictHostKeyChecking
- TCPKeepAlive
- Tunnel
- TunnelDevice
- UsePrivilegedPort
- User
- UserKnownHostsFile
- VerifyHostKeyDNS
- XAuthLocation
-
- -p port
- Port to connect to on the remote host. This can be specified on
- a per-host basis in the configuration file.
-
- -q Quiet mode. Causes all warning and diagnostic messages to be
- suppressed.
-
- -R [bind_address:]port:host:hostport
- Specifies that the given port on the remote (server) host is to
- be forwarded to the given host and port on the local side. This
- works by allocating a socket to listen to port on the remote
- side, and whenever a connection is made to this port, the connec-
- tion is forwarded over the secure channel, and a connection is
- made to host port hostport from the local machine.
-
- Port forwardings can also be specified in the configuration file.
- Privileged ports can be forwarded only when logging in as root on
- the remote machine. IPv6 addresses can be specified by enclosing
- the address in square braces or using an alternative syntax:
- [bind_address/]host/port/hostport.
-
- By default, the listening socket on the server will be bound to
- the loopback interface only. This may be overriden by specifying
- a bind_address. An empty bind_address, or the address `*', indi-
- cates that the remote socket should listen on all interfaces.
- Specifying a remote bind_address will only succeed if the serv-
- er's GatewayPorts option is enabled (see sshd_config(5)).
-
- -S ctl_path
- Specifies the location of a control socket for connection shar-
- ing. Refer to the description of ControlPath and ControlMaster
- in ssh_config(5) for details.
-
- -s May be used to request invocation of a subsystem on the remote
- system. Subsystems are a feature of the SSH2 protocol which fa-
- cilitate the use of SSH as a secure transport for other applica-
- tions (eg. sftp(1)). The subsystem is specified as the remote
- command.
-
- -T Disable pseudo-tty allocation.
-
- -t Force pseudo-tty allocation. This can be used to execute arbi-
- trary screen-based programs on a remote machine, which can be
- very useful, e.g. when implementing menu services. Multiple -t
- options force tty allocation, even if ssh has no local tty.
-
- -V Display the version number and exit.
-
- -v Verbose mode. Causes ssh to print debugging messages about its
- progress. This is helpful in debugging connection, authentica-
- tion, and configuration problems. Multiple -v options increase
- the verbosity. The maximum is 3.
-
- -w local_tun[:remote_tun]
- Requests tunnel device forwarding with the specified tun(4) de-
- vices between the client (local_tun) and the server (remote_tun).
-
- The devices may be specified by numerical ID or the keyword
- ``any'', which uses the next available tunnel device. If
- remote_tun is not specified, it defaults to ``any''. See also
- the Tunnel and TunnelDevice directives in ssh_config(5). If the
- Tunnel directive is unset, it is set to the default tunnel mode,
- which is ``point-to-point''.
-
- -X Enables X11 forwarding. This can also be specified on a per-host
- basis in a configuration file.
-
- 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.
-
- For this reason, X11 forwarding is subjected to X11 SECURITY ex-
- tension restrictions by default. Please refer to the ssh -Y op-
- tion and the ForwardX11Trusted directive in ssh_config(5) for
- more information.
-
- -x Disables X11 forwarding.
-
- -Y Enables trusted X11 forwarding. Trusted X11 forwardings are not
- subjected to the X11 SECURITY extension controls.
-
- ssh may additionally obtain configuration data from a per-user configura-
- tion file and a system-wide configuration file. The file format and con-
- figuration options are described in ssh_config(5).
-
- ssh exits with the exit status of the remote command or with 255 if an
- error occurred.
-
-AUTHENTICATION
- The OpenSSH SSH client supports SSH protocols 1 and 2. Protocol 2 is the
- default, with ssh falling back to protocol 1 if it detects protocol 2 is
- unsupported. These settings may be altered using the Protocol option in
- ssh_config(5), or enforced using the -1 and -2 options (see above). Both
- protocols support similar authentication methods, but protocol 2 is pre-
- ferred 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.
-
- The methods available for authentication are: GSSAPI-based authentica-
- tion, host-based authentication, public key authentication, challenge-re-
- sponse authentication, and password authentication. Authentication meth-
- ods are tried in the order specified above, though protocol 2 has a con-
- figuration option to change the default order: PreferredAuthentications.
-
- Host-based authentication works as follows: If the machine the user logs
- in from is listed in /etc/hosts.equiv or /etc/shosts.equiv on the remote
- machine, and the user names are the same on both sides, or if the files
- ~/.rhosts or ~/.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 must be able to verify the client's host key
- (see the description of /etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts,
- below) for login to be permitted. This authentication method closes se-
- curity holes due to IP spoofing, DNS spoofing, and routing spoofing.
- [Note to the administrator: /etc/hosts.equiv, ~/.rhosts, and the
- rlogin/rsh protocol in general, are inherently insecure and should be
- disabled if security is desired.]
-
- Public key authentication works as follows: The scheme is based on pub-
- lic-key cryptography, using cryptosystems where encryption and decryption
- are done using separate keys, and it is unfeasible to derive the decryp-
- tion 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. ssh 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 HISTORY section of ssl(8) contains a
- brief discussion of the two algorithms.
-
- The file ~/.ssh/authorized_keys lists the public keys that are permitted
- for logging in. When the user logs in, the ssh 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.
-
- The user creates his/her key pair by running ssh-keygen(1). This stores
- the private key in ~/.ssh/identity (protocol 1), ~/.ssh/id_dsa (protocol
- 2 DSA), or ~/.ssh/id_rsa (protocol 2 RSA) and stores the public key in
- ~/.ssh/identity.pub (protocol 1), ~/.ssh/id_dsa.pub (protocol 2 DSA), or
- ~/.ssh/id_rsa.pub (protocol 2 RSA) in the user's home directory. The us-
- er should then copy the public key to ~/.ssh/authorized_keys in his/her
- home directory on the remote machine. The authorized_keys file corre-
- sponds to the conventional ~/.rhosts file, and has one key per line,
- though the lines can be very long. After this, the user can log in with-
- out giving the password.
-
- The most convenient way to use public key authentication may be with an
- authentication agent. See ssh-agent(1) for more information.
-
- Challenge-response authentication works as follows: The server sends an
- arbitrary "challenge" text, and prompts for a response. Protocol 2 al-
- lows multiple challenges and responses; protocol 1 is restricted to just
- one challenge/response. Examples of challenge-response authentication
- include BSD Authentication (see login.conf(5)) and PAM (some non-OpenBSD
- systems).
-
- Finally, if other authentication methods fail, ssh 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.
-
- ssh automatically maintains and checks a database containing identifica-
- tion for all hosts it has ever been used with. Host keys are stored in
- ~/.ssh/known_hosts in the user's home directory. Additionally, the file
- /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 iden-
- tification ever changes, ssh warns about this and disables password au-
- thentication to prevent server spoofing or man-in-the-middle attacks,
- which could otherwise be used to circumvent the encryption. The
- StrictHostKeyChecking option can be used to control logins to machines
- whose host key is not known or has changed.
-
- When the user's identity has been accepted by the server, the server ei-
- ther 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.
-
- If a pseudo-terminal has been allocated (normal login session), the user
- may use the escape characters noted below.
-
- 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 ``none'' will also make the session transparent even
- if a tty is used.
-
- The session terminates when the command or shell on the remote machine
- exits and all X11 and TCP connections have been closed.
-
-ESCAPE CHARACTERS
- When a pseudo-terminal has been requested, ssh supports a number of func-
- tions through the use of an escape character.
-
- A single tilde character can be sent as ~~ 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 charac-
- ter can be changed in configuration files using the EscapeChar configura-
- tion directive or on the command line by the -e option.
-
- The supported escapes (assuming the default `~') are:
-
- ~. Disconnect.
-
- ~^Z Background ssh.
-
- ~# List forwarded connections.
-
- ~& Background ssh at logout when waiting for forwarded connection /
- X11 sessions to terminate.
-
- ~? Display a list of escape characters.
-
- ~B Send a BREAK to the remote system (only useful for SSH protocol
- version 2 and if the peer supports it).
-
- ~C Open command line. Currently this allows the addition of port
- forwardings using the -L and -R options (see above). It also al-
- lows the cancellation of existing remote port-forwardings using
- -KR[bind_address:]port. !command allows the user to execute a
- local command if the PermitLocalCommand option is enabled in
- ssh_config(5). Basic help is available, using the -h option.
-
- ~R Request rekeying of the connection (only useful for SSH protocol
- version 2 and if the peer supports it).
-
-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.
-
- 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 ssh, specifying a port to be used to forward con-
- nections 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 ssh will encrypt and forward the connection.
-
- The following example tunnels an IRC session from client machine
- ``127.0.0.1'' (localhost) to remote server ``server.example.com'':
-
- $ ssh -f -L 1234:localhost:6667 server.example.com sleep 10
- $ irc -c '#users' -p 1234 pinky 127.0.0.1
-
- This tunnels a connection to IRC server ``server.example.com'', joining
- channel ``#users'', nickname ``pinky'', using port 1234. It doesn't mat-
- ter 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.
-
- The -f option backgrounds ssh and the remote command ``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, ssh will exit.
-
-X11 FORWARDING
- If the ForwardX11 variable is set to ``yes'' (or see the description of
- the -X, -x, and -Y options above) and the user is using X11 (the DISPLAY
- environment variable is set), the connection to the X11 display is auto-
- matically forwarded to the remote side in such a way that any X11 pro-
- grams 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 DISPLAY. Forwarding of
- X11 connections can be configured on the command line or in configuration
- files.
-
- The DISPLAY value set by ssh will point to the server machine, but with a
- display number greater than zero. This is normal, and happens because
- ssh creates a ``proxy'' X server on the server machine for forwarding the
- connections over the encrypted channel.
-
- ssh 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).
-
- If the ForwardAgent variable is set to ``yes'' (or see the description of
- the -A and -a options above) and the user is using an authentication
- agent, the connection to the agent is automatically forwarded to the re-
- mote side.
-
-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
- StrictHostKeyChecking has been disabled). Fingerprints can be determined
- using ssh-keygen(1):
-
- $ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key
-
- 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.
-
- In this example, we are connecting a client to a server,
- ``host.example.com''. The SSHFP resource records should first be added
- to the zonefile for host.example.com:
-
- $ ssh-keygen -r host.example.com.
-
- The output lines will have to be added to the zonefile. To check that
- the zone is answering fingerprint queries:
-
- $ dig -t SSHFP host.example.com
-
- Finally the client connects:
-
- $ ssh -o "VerifyHostKeyDNS ask" host.example.com
- [...]
- Matching host key fingerprint found in DNS.
- Are you sure you want to continue connecting (yes/no)?
-
- See the VerifyHostKeyDNS option in ssh_config(5) for more information.
-
-SSH-BASED VIRTUAL PRIVATE NETWORKS
- ssh contains support for Virtual Private Network (VPN) tunnelling using
- the tun(4) network pseudo-device, allowing two networks to be joined se-
- curely. The sshd_config(5) configuration option PermitTunnel controls
- whether the server supports this, and at what level (layer 2 or 3 traf-
- fic).
-
- The following example would connect client network 10.0.50.0/24 with re-
- mote 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:
-
- # 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
-
- Client access may be more finely tuned via the /root/.ssh/authorized_keys
- file (see below) and the PermitRootLogin server option. The following
- entry would permit connections on tun(4) device 1 from user ``jane'' and
- on tun device 2 from user ``john'', if PermitRootLogin is set to
- ``forced-commands-only'':
-
- tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... jane
- tunnel="2",command="sh /etc/netstart tun2" ssh-rsa ... john
-
- Since a 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 ipsecctl(8) and isakmpd(8).
-
-ENVIRONMENT
- ssh will normally set the following environment variables:
-
- DISPLAY The DISPLAY variable indicates the location of the
- X11 server. It is automatically set by ssh to
- point to a value of the form ``hostname:n'', where
- ``hostname'' indicates the host where the shell
- runs, and `n' is an integer >= 1. ssh uses this
- special value to forward X11 connections over the
- secure channel. The user should normally not set
- DISPLAY explicitly, as that will render the X11
- connection insecure (and will require the user to
- manually copy any required authorization cookies).
-
- HOME Set to the path of the user's home directory.
-
- LOGNAME Synonym for USER; set for compatibility with sys-
- tems that use this variable.
-
- MAIL Set to the path of the user's mailbox.
-
- PATH Set to the default PATH, as specified when compil-
- ing ssh.
-
- SSH_ASKPASS If ssh needs a passphrase, it will read the
- passphrase from the current terminal if it was run
- from a terminal. If ssh does not have a terminal
- associated with it but DISPLAY and SSH_ASKPASS are
- set, it will execute the program specified by
- SSH_ASKPASS and open an X11 window to read the
- passphrase. This is particularly useful when call-
- ing ssh from a .xsession or related script. (Note
- that on some machines it may be necessary to redi-
- rect the input from /dev/null to make this work.)
-
- SSH_AUTH_SOCK Identifies the path of a UNIX-domain socket used to
- communicate with the agent.
-
- SSH_CONNECTION Identifies the client and server ends of the con-
- nection. The variable contains four space-separat-
- ed values: client IP address, client port number,
- server IP address, and server port number.
-
- 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.
-
- SSH_TTY This is set to the name of the tty (path to the de-
- vice) associated with the current shell or command.
- If the current session has no tty, this variable is
- not set.
-
- 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 connec-
- tions).
-
- USER Set to the name of the user logging in.
-
- Additionally, ssh reads ~/.ssh/environment, and adds lines of the format
- ``VARNAME=value'' to the environment if the file exists and users are al-
- lowed to change their environment. For more information, see the
- PermitUserEnvironment option in sshd_config(5).
-
-FILES
- ~/.rhosts
- This file is used for host-based authentication (see above). On
- some machines this file may need to be world-readable if the us-
- er's home directory is on an NFS partition, because 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 recom-
- mended permission for most machines is read/write for the user,
- and not accessible by others.
-
- ~/.shosts
- This file is used in exactly the same way as .rhosts, but allows
- host-based authentication without permitting login with
- rlogin/rsh.
-
- ~/.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
- sshd(8) manual page. This file is not highly sensitive, but the
- recommended permissions are read/write for the user, and not ac-
- cessible by others.
-
- ~/.ssh/config
- This is the per-user configuration file. The file format and
- configuration options are described in 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.
-
- ~/.ssh/environment
- Contains additional definitions for environment variables; see
- ENVIRONMENT, above.
-
- ~/.ssh/identity
- ~/.ssh/id_dsa
- ~/.ssh/id_rsa
- Contains the private key for authentication. These files contain
- sensitive data and should be readable by the user but not acces-
- sible by others (read/write/execute). ssh 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.
-
- ~/.ssh/identity.pub
- ~/.ssh/id_dsa.pub
- ~/.ssh/id_rsa.pub
- Contains the public key for authentication. These files are not
- sensitive and can (but need not) be readable by anyone.
-
- ~/.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 sshd(8) for further details of the format of this
- file.
-
- ~/.ssh/rc
- Commands in this file are executed by ssh when the user logs in,
- just before the user's shell (or command) is started. See the
- sshd(8) manual page for more information.
-
- /etc/hosts.equiv
- This file is for host-based authentication (see above). It
- should only be writable by root.
-
- /etc/shosts.equiv
- This file is used in exactly the same way as hosts.equiv, but al-
- lows host-based authentication without permitting login with
- rlogin/rsh.
-
- /etc/ssh/ssh_config
- Systemwide configuration file. The file format and configuration
- options are described in ssh_config(5).
-
- /etc/ssh/ssh_host_key
- /etc/ssh/ssh_host_dsa_key
- /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, ssh must be setuid root, since the host key is readable on-
- ly by root. For protocol version 2, ssh uses ssh-keysign(8) to
- access the host keys, eliminating the requirement that ssh be se-
- tuid root when host-based authentication is used. By default ssh
- is not setuid root.
-
- /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 sshd(8) for further details of the format of this file.
-
- /etc/ssh/sshrc
- Commands in this file are executed by ssh when the user logs in,
- just before the user's shell (or command) is started. See the
- sshd(8) manual page for more information.
-
-SEE ALSO
- scp(1), sftp(1), ssh-add(1), ssh-agent(1), ssh-keygen(1), ssh-keyscan(1),
- tun(4), hosts.equiv(5), ssh_config(5), ssh-keysign(8), sshd(8)
-
- The Secure Shell (SSH) Protocol Assigned Numbers, RFC 4250, 2006.
-
- The Secure Shell (SSH) Protocol Architecture, RFC 4251, 2006.
-
- The Secure Shell (SSH) Authentication Protocol, RFC 4252, 2006.
-
- The Secure Shell (SSH) Transport Layer Protocol, RFC 4253, 2006.
-
- The Secure Shell (SSH) Connection Protocol, RFC 4254, 2006.
-
- Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints, RFC
- 4255, 2006.
-
- Generic Message Exchange Authentication for the Secure Shell Protocol
- (SSH), RFC 4256, 2006.
-
- The Secure Shell (SSH) Session Channel Break Extension, RFC 4335, 2006.
-
- The Secure Shell (SSH) Transport Layer Encryption Modes, RFC 4344, 2006.
-
- Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer
- Protocol, RFC 4345, 2006.
-
- Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer
- Protocol, RFC 4419, 2006.
-
-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.
-
-OpenBSD 4.0 September 25, 1999 13
+++ /dev/null
-SSH_CONFIG(5) OpenBSD Programmer's Manual SSH_CONFIG(5)
-
-NAME
- ssh_config - OpenSSH SSH client configuration files
-
-SYNOPSIS
- ~/.ssh/config
- /etc/ssh/ssh_config
-
-DESCRIPTION
- ssh(1) obtains configuration data from the following sources in the fol-
- lowing order:
-
- 1. command-line options
- 2. user's configuration file (~/.ssh/config)
- 3. system-wide configuration file (/etc/ssh/ssh_config)
-
- For each parameter, the first obtained value will be used. The configu-
- ration files contain sections separated by ``Host'' specifications, and
- that section is only applied for hosts that match one of the patterns
- given in the specification. The matched host name is the one given on
- the command line.
-
- Since the first obtained value for each parameter is used, more host-spe-
- cific declarations should be given near the beginning of the file, and
- general defaults at the end.
-
- The configuration file has the following format:
-
- Empty lines and lines starting with `#' are comments. Otherwise a line
- is of the format ``keyword arguments''. Configuration options may be
- separated by whitespace or optional whitespace and exactly one `='; the
- latter format is useful to avoid the need to quote whitespace when speci-
- fying configuration options using the ssh, scp, and sftp -o option. Ar-
- guments may optionally be enclosed in double quotes (") in order to rep-
- resent arguments containing spaces.
-
- The possible keywords and their meanings are as follows (note that key-
- words are case-insensitive and arguments are case-sensitive):
-
- Host Restricts the following declarations (up to the next Host key-
- word) to be only for those hosts that match one of the patterns
- given after the keyword. A single `*' as a pattern can be used
- to provide global defaults for all hosts. The host is the
- hostname argument given on the command line (i.e. the name is not
- converted to a canonicalized host name before matching).
-
- See PATTERNS for more information on patterns.
-
- AddressFamily
- Specifies which address family to use when connecting. Valid ar-
- guments are ``any'', ``inet'' (use IPv4 only), or ``inet6'' (use
- IPv6 only).
-
- BatchMode
- If set to ``yes'', passphrase/password querying will be disabled.
- This option is useful in scripts and other batch jobs where no
- user is present to supply the password. The argument must be
- ``yes'' or ``no''. The default is ``no''.
-
- BindAddress
- Use the specified address on the local machine as the source ad-
- dress of the connection. Only useful on systems with more than
- one address. Note that this option does not work if
- UsePrivilegedPort is set to ``yes''.
-
- ChallengeResponseAuthentication
- Specifies whether to use challenge-response authentication. The
- argument to this keyword must be ``yes'' or ``no''. The default
- is ``yes''.
-
- CheckHostIP
- If this flag is set to ``yes'', ssh(1) will additionally check
- the host IP address in the known_hosts file. This allows ssh to
- detect if a host key changed due to DNS spoofing. If the option
- is set to ``no'', the check will not be executed. The default is
- ``yes''.
-
- Cipher Specifies the cipher to use for encrypting the session in proto-
- col version 1. Currently, ``blowfish'', ``3des'', and ``des''
- are supported. des is only supported in the ssh(1) client for
- interoperability with legacy protocol 1 implementations that do
- not support the 3des cipher. Its use is strongly discouraged due
- to cryptographic weaknesses. The default is ``3des''.
-
- Ciphers
- Specifies the ciphers allowed for protocol version 2 in order of
- preference. Multiple ciphers must be comma-separated. The sup-
- ported 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:
-
- aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,
- arcfour256,arcfour,aes192-cbc,aes256-cbc,aes128-ctr,
- aes192-ctr,aes256-ctr
-
- ClearAllForwardings
- Specifies that all local, remote, and dynamic port forwardings
- specified in the configuration files or on the command line be
- cleared. This option is primarily useful when used from the
- ssh(1) command line to clear port forwardings set in configura-
- tion files, and is automatically set by scp(1) and sftp(1). The
- argument must be ``yes'' or ``no''. The default is ``no''.
-
- Compression
- Specifies whether to use compression. The argument must be
- ``yes'' or ``no''. The default is ``no''.
-
- CompressionLevel
- Specifies the compression level to use if compression is enabled.
- The argument must be an integer from 1 (fast) to 9 (slow, best).
- The default level is 6, which is good for most applications. The
- meaning of the values is the same as in gzip(1). Note that this
- option applies to protocol version 1 only.
-
- ConnectionAttempts
- Specifies the number of tries (one per second) to make before ex-
- iting. The argument must be an integer. This may be useful in
- scripts if the connection sometimes fails. The default is 1.
-
- ConnectTimeout
- Specifies the timeout (in seconds) used when connecting to the
- SSH server, instead of using the default system TCP timeout.
- This value is used only when the target is down or really un-
- reachable, not when it refuses the connection.
-
- ControlMaster
- Enables the sharing of multiple sessions over a single network
- connection. When set to ``yes'', ssh(1) will listen for connec-
- tions on a control socket specified using the ControlPath argu-
- ment. Additional sessions can connect to this socket using the
- same ControlPath with ControlMaster set to ``no'' (the default).
- These sessions will try to reuse the master instance's network
- connection rather than initiating new ones, but will fall back to
- connecting normally if the control socket does not exist, or is
- not listening.
-
- Setting this to ``ask'' will cause ssh to listen for control con-
- nections, but require confirmation using the SSH_ASKPASS program
- before they are accepted (see ssh-add(1) for details). If the
- ControlPath cannot be opened, ssh will continue without connect-
- ing to a master instance.
-
- X11 and ssh-agent(1) forwarding is supported over these multi-
- plexed connections, however the display and agent forwarded will
- be the one belonging to the master connection i.e. it is not pos-
- sible to forward multiple displays or agents.
-
- Two additional options allow for opportunistic multiplexing: try
- to use a master connection but fall back to creating a new one if
- one does not already exist. These options are: ``auto'' and
- ``autoask''. The latter requires confirmation like the ``ask''
- option.
-
- ControlPath
- Specify the path to the control socket used for connection shar-
- ing as described in the ControlMaster section above or the string
- ``none'' to disable connection sharing. In the path, `%l' will
- be substituted by the local host name, `%h' will be substituted
- by the target host name, `%p' the port, and `%r' by the remote
- login username. It is recommended that any ControlPath used for
- opportunistic connection sharing include at least %h, %p, and %r.
- This ensures that shared connections are uniquely identified.
-
- DynamicForward
- Specifies that a TCP port on the local machine be forwarded over
- the secure channel, and the application protocol is then used to
- determine where to connect to from the remote machine.
-
- The argument must be [bind_address:]port. IPv6 addresses can be
- specified by enclosing addresses in square brackets or by using
- an alternative syntax: [bind_address/]port. By default, the lo-
- cal port is bound in accordance with the GatewayPorts setting.
- However, an explicit bind_address may be used to bind the connec-
- tion to a specific address. The bind_address of ``localhost''
- indicates that the listening port be bound for local use only,
- while an empty address or `*' indicates that the port should be
- available from all interfaces.
-
- Currently the SOCKS4 and SOCKS5 protocols are supported, and
- ssh(1) will act as a SOCKS server. Multiple forwardings may be
- specified, and additional forwardings can be given on the command
- line. Only the superuser can forward privileged ports.
-
- EnableSSHKeysign
- Setting this option to ``yes'' in the global client configuration
- file /etc/ssh/ssh_config enables the use of the helper program
- ssh-keysign(8) during HostbasedAuthentication. The argument must
- be ``yes'' or ``no''. The default is ``no''. This option should
- be placed in the non-hostspecific section. See ssh-keysign(8)
- for more information.
-
- EscapeChar
- Sets the escape character (default: `~'). The escape character
- can also be set on the command line. The argument should be a
- single character, `^' followed by a letter, or ``none'' to dis-
- able the escape character entirely (making the connection trans-
- parent for binary data).
-
- ExitOnForwardFailure
- Specifies whether ssh(1) should terminate the connection if it
- cannot set up all requested dynamic, local, and remote port for-
- wardings. The argument must be ``yes'' or ``no''. The default
- is ``no''.
-
- ForwardAgent
- Specifies whether the connection to the authentication agent (if
- any) will be forwarded to the remote machine. The argument must
- be ``yes'' or ``no''. The default is ``no''.
-
- 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.
-
- ForwardX11
- Specifies whether X11 connections will be automatically redirect-
- ed over the secure channel and DISPLAY set. The argument must be
- ``yes'' or ``no''. The default is ``no''.
-
- X11 forwarding should be enabled with caution. Users with the
- ability to bypass file permissions on the remote host (for the
- user's X11 authorization database) can access the local X11 dis-
- play through the forwarded connection. An attacker may then be
- able to perform activities such as keystroke monitoring if the
- ForwardX11Trusted option is also enabled.
-
- ForwardX11Trusted
- If this option is set to ``yes'', remote X11 clients will have
- full access to the original X11 display.
-
- If this option is set to ``no'', remote X11 clients will be con-
- sidered untrusted and prevented from stealing or tampering with
- data belonging to trusted X11 clients. Furthermore, the xauth(1)
- token used for the session will be set to expire after 20 min-
- utes. Remote clients will be refused access after this time.
-
- The default is ``no''.
-
- See the X11 SECURITY extension specification for full details on
- the restrictions imposed on untrusted clients.
-
- GatewayPorts
- Specifies whether remote hosts are allowed to connect to local
- forwarded ports. By default, ssh(1) binds local port forwardings
- to the loopback address. This prevents other remote hosts from
- connecting to forwarded ports. GatewayPorts can be used to spec-
- ify that ssh should bind local port forwardings to the wildcard
- address, thus allowing remote hosts to connect to forwarded
- ports. The argument must be ``yes'' or ``no''. The default is
- ``no''.
-
- GlobalKnownHostsFile
- Specifies a file to use for the global host key database instead
- of /etc/ssh/ssh_known_hosts.
-
- GSSAPIAuthentication
- Specifies whether user authentication based on GSSAPI is allowed.
- The default is ``no''. Note that this option applies to protocol
- version 2 only.
-
- GSSAPIDelegateCredentials
- Forward (delegate) credentials to the server. The default is
- ``no''. Note that this option applies to protocol version 2 on-
- ly.
-
- HashKnownHosts
- Indicates that ssh(1) should hash host names and addresses when
- they are added to ~/.ssh/known_hosts. These hashed names may be
- used normally by ssh(1) and sshd(8), but they do not reveal iden-
- tifying information should the file's contents be disclosed. The
- default is ``no''. Note that existing names and addresses in
- known hosts files will not be converted automatically, but may be
- manually hashed using ssh-keygen(1).
-
- HostbasedAuthentication
- Specifies whether to try rhosts based authentication with public
- key authentication. The argument must be ``yes'' or ``no''. The
- default is ``no''. This option applies to protocol version 2 on-
- ly and is similar to RhostsRSAAuthentication.
-
- HostKeyAlgorithms
- Specifies the protocol version 2 host key algorithms that the
- client wants to use in order of preference. The default for this
- option is: ``ssh-rsa,ssh-dss''.
-
- HostKeyAlias
- Specifies an alias that should be used instead of the real host
- name when looking up or saving the host key in the host key
- database files. This option is useful for tunneling SSH connec-
- tions or for multiple servers running on a single host.
-
- HostName
- Specifies the real host name to log into. This can be used to
- specify nicknames or abbreviations for hosts. The default is the
- name given on the command line. Numeric IP addresses are also
- permitted (both on the command line and in HostName specifica-
- tions).
-
- IdentitiesOnly
- Specifies that ssh(1) should only use the authentication identity
- files configured in the ssh_config files, even if ssh-agent(1)
- offers more identities. The argument to this keyword must be
- ``yes'' or ``no''. This option is intended for situations where
- ssh-agent offers many different identities. The default is
- ``no''.
-
- IdentityFile
- Specifies a file from which the user's RSA or DSA authentication
- identity is read. The default is ~/.ssh/identity for protocol
- version 1, and ~/.ssh/id_rsa and ~/.ssh/id_dsa for protocol ver-
- sion 2. Additionally, any identities represented by the authen-
- tication agent will be used for authentication.
-
- The file name may use the tilde syntax to refer to a user's home
- directory or one of the following escape characters: `%d' (local
- user's home directory), `%u' (local user name), `%l' (local host
- name), `%h' (remote host name) or `%r' (remote user name).
-
- It is possible to have multiple identity files specified in con-
- figuration files; all these identities will be tried in sequence.
-
- KbdInteractiveDevices
- Specifies the list of methods to use in keyboard-interactive au-
- thentication. Multiple method names must be comma-separated.
- The default is to use the server specified list. The methods
- available vary depending on what the server supports. For an
- OpenSSH server, it may be zero or more of: ``bsdauth'', ``pam'',
- and ``skey''.
-
- LocalCommand
- Specifies a command to execute on the local machine after suc-
- cessfully connecting to the server. The command string extends
- to the end of the line, and is executed with /bin/sh. This di-
- rective is ignored unless PermitLocalCommand has been enabled.
-
- LocalForward
- Specifies that a TCP port on the local machine be forwarded over
- the secure channel to the specified host and port from the remote
- machine. The first argument must be [bind_address:]port and the
- second argument must be host:hostport. IPv6 addresses can be
- specified by enclosing addresses in square brackets or by using
- an alternative syntax: [bind_address/]port and host/hostport.
- Multiple forwardings may be specified, and additional forwardings
- can be given on the command line. Only the superuser can forward
- privileged ports. By default, the local port is bound in accor-
- dance with the GatewayPorts setting. However, an explicit
- bind_address may be used to bind the connection to a specific ad-
- dress. The bind_address of ``localhost'' indicates that the lis-
- tening port be bound for local use only, while an empty address
- or `*' indicates that the port should be available from all in-
- terfaces.
-
- LogLevel
- Gives the verbosity level that is used when logging messages from
- ssh(1). The possible values are: QUIET, FATAL, ERROR, INFO, VER-
- BOSE, DEBUG, DEBUG1, DEBUG2, and DEBUG3. The default is INFO.
- DEBUG and DEBUG1 are equivalent. DEBUG2 and DEBUG3 each specify
- higher levels of verbose output.
-
- MACs Specifies the MAC (message authentication code) algorithms in or-
- der of preference. The MAC algorithm is used in protocol version
- 2 for data integrity protection. Multiple algorithms must be
- comma-separated. The default is: ``hmac-md5,hmac-sha1,hmac-
- ripemd160,hmac-sha1-96,hmac-md5-96''.
-
- NoHostAuthenticationForLocalhost
- This option can be used if the home directory is shared across
- machines. In this case localhost will refer to a different ma-
- chine on each of the machines and the user will get many warnings
- about changed host keys. However, this option disables host au-
- thentication for localhost. The argument to this keyword must be
- ``yes'' or ``no''. The default is to check the host key for lo-
- calhost.
-
- NumberOfPasswordPrompts
- Specifies the number of password prompts before giving up. The
- argument to this keyword must be an integer. The default is 3.
-
- PasswordAuthentication
- Specifies whether to use password authentication. The argument
- to this keyword must be ``yes'' or ``no''. The default is
- ``yes''.
-
- PermitLocalCommand
- Allow local command execution via the LocalCommand option or us-
- ing the !command escape sequence in ssh(1). The argument must be
- ``yes'' or ``no''. The default is ``no''.
-
- Port Specifies the port number to connect on the remote host. The de-
- fault is 22.
-
- PreferredAuthentications
- Specifies the order in which the client should try protocol 2 au-
- thentication methods. This allows a client to prefer one method
- (e.g. keyboard-interactive) over another method (e.g. password)
- The default for this option is: ``gssapi-with-mic,hostbased,
- publickey, keyboard-interactive, password''.
-
- Protocol
- Specifies the protocol versions ssh(1) should support in order of
- preference. The possible values are `1' and `2'. Multiple ver-
- sions must be comma-separated. The default is ``2,1''. This
- means that ssh tries version 2 and falls back to version 1 if
- version 2 is not available.
-
- ProxyCommand
- Specifies the command to use to connect to the server. The com-
- mand string extends to the end of the line, and is executed with
- /bin/sh. In the command string, `%h' will be substituted by the
- host name to connect and `%p' by the port. The command can be
- basically anything, and should read from its standard input and
- write to its standard output. It should eventually connect an
- sshd(8) server running on some machine, or execute sshd -i some-
- where. Host key management will be done using the HostName of
- the host being connected (defaulting to the name typed by the us-
- er). Setting the command to ``none'' disables this option en-
- tirely. Note that CheckHostIP is not available for connects with
- a proxy command.
-
- This directive is useful in conjunction with nc(1) and its proxy
- support. For example, the following directive would connect via
- an HTTP proxy at 192.0.2.0:
-
- ProxyCommand /usr/bin/nc -X connect -x 192.0.2.0:8080 %h %p
-
- PubkeyAuthentication
- Specifies whether to try public key authentication. The argument
- to this keyword must be ``yes'' or ``no''. The default is
- ``yes''. This option applies to protocol version 2 only.
-
- RekeyLimit
- Specifies the maximum amount of data that may be transmitted be-
- fore the session key is renegotiated. The argument is the number
- of bytes, with an optional suffix of `K', `M', or `G' to indicate
- Kilobytes, Megabytes, or Gigabytes, respectively. The default is
- between `1G' and `4G', depending on the cipher. This option ap-
- plies to protocol version 2 only.
-
- RemoteForward
- Specifies that a TCP port on the remote machine be forwarded over
- the secure channel to the specified host and port from the local
- machine. The first argument must be [bind_address:]port and the
- second argument must be host:hostport. IPv6 addresses can be
- specified by enclosing addresses in square brackets or by using
- an alternative syntax: [bind_address/]port and host/hostport.
- Multiple forwardings may be specified, and additional forwardings
- can be given on the command line. Only the superuser can forward
- privileged ports.
-
- If the bind_address is not specified, the default is to only bind
- to loopback addresses. If the bind_address is `*' or an empty
- string, then the forwarding is requested to listen on all inter-
- faces. Specifying a remote bind_address will only succeed if the
- server's GatewayPorts option is enabled (see sshd_config(5)).
-
- RhostsRSAAuthentication
- Specifies whether to try rhosts based authentication with RSA
- host authentication. The argument must be ``yes'' or ``no''.
- The default is ``no''. This option applies to protocol version 1
- only and requires ssh(1) to be setuid root.
-
- RSAAuthentication
- Specifies whether to try RSA authentication. The argument to
- this keyword must be ``yes'' or ``no''. RSA authentication will
- only be attempted if the identity file exists, or an authentica-
- tion agent is running. The default is ``yes''. Note that this
- option applies to protocol version 1 only.
-
- SendEnv
- Specifies what variables from the local environ(7) should be sent
- to the server. Note that environment passing is only supported
- for protocol 2. The server must also support it, and the server
- must be configured to accept these environment variables. Refer
- to AcceptEnv in sshd_config(5) for how to configure the server.
- Variables are specified by name, which may contain wildcard char-
- acters. Multiple environment variables may be separated by
- whitespace or spread across multiple SendEnv directives. The de-
- fault is not to send any environment variables.
-
- See PATTERNS for more information on patterns.
-
- ServerAliveCountMax
- Sets the number of server alive messages (see below) which may be
- sent without ssh(1) receiving any messages back from the server.
- If this threshold is reached while server alive messages are be-
- ing sent, ssh will disconnect from the server, terminating the
- session. It is important to note that the use of server alive
- messages is very different from TCPKeepAlive (below). The server
- alive messages are sent through the encrypted channel and there-
- fore will not be spoofable. The TCP keepalive option enabled by
- TCPKeepAlive is spoofable. The server alive mechanism is valu-
- able when the client or server depend on knowing when a connec-
- tion has become inactive.
-
- The default value is 3. If, for example, ServerAliveInterval
- (see below) is set to 15 and ServerAliveCountMax is left at the
- default, if the server becomes unresponsive, ssh will disconnect
- after approximately 45 seconds. This option applies to protocol
- version 2 only.
-
- ServerAliveInterval
- Sets a timeout interval in seconds after which if no data has
- been received from the server, ssh(1) will send a message through
- the encrypted channel to request a response from the server. The
- default is 0, indicating that these messages will not be sent to
- the server. This option applies to protocol version 2 only.
-
- SmartcardDevice
- Specifies which smartcard device to use. The argument to this
- keyword is the device ssh(1) should use to communicate with a
- smartcard used for storing the user's private RSA key. By de-
- fault, no device is specified and smartcard support is not acti-
- vated.
-
- StrictHostKeyChecking
- If this flag is set to ``yes'', ssh(1) will never automatically
- add host keys to the ~/.ssh/known_hosts file, and refuses to con-
- nect to hosts whose host key has changed. This provides maximum
- protection against trojan horse attacks, though it can be annoy-
- ing when the /etc/ssh/ssh_known_hosts file is poorly maintained
- or when connections to new hosts are frequently made. This op-
- tion forces the user to manually add all new hosts. If this flag
- is set to ``no'', ssh will automatically add new host keys to the
- user known hosts files. If this flag is set to ``ask'', new host
- keys will be added to the user known host files only after the
- user has confirmed that is what they really want to do, and ssh
- will refuse to connect to hosts whose host key has changed. The
- host keys of known hosts will be verified automatically in all
- cases. The argument must be ``yes'', ``no'', or ``ask''. The
- default is ``ask''.
-
- TCPKeepAlive
- Specifies whether the system should send TCP keepalive messages
- to the other side. If they are sent, death of the connection or
- crash of one of the machines will be properly noticed. However,
- this means that connections will die if the route is down tem-
- porarily, and some people find it annoying.
-
- The default is ``yes'' (to send TCP keepalive messages), and the
- client will notice if the network goes down or the remote host
- dies. This is important in scripts, and many users want it too.
-
- To disable TCP keepalive messages, the value should be set to
- ``no''.
-
- Tunnel Request tun(4) device forwarding between the client and the serv-
- er. The argument must be ``yes'', ``point-to-point'' (layer 3),
- ``ethernet'' (layer 2), or ``no''. Specifying ``yes'' requests
- the default tunnel mode, which is ``point-to-point''. The de-
- fault is ``no''.
-
- TunnelDevice
- Specifies the tun(4) devices to open on the client (local_tun)
- and the server (remote_tun).
-
- The argument must be local_tun[:remote_tun]. The devices may be
- specified by numerical ID or the keyword ``any'', which uses the
- next available tunnel device. If remote_tun is not specified, it
- defaults to ``any''. The default is ``any:any''.
-
- UsePrivilegedPort
- Specifies whether to use a privileged port for outgoing connec-
- tions. The argument must be ``yes'' or ``no''. The default is
- ``no''. If set to ``yes'', ssh(1) must be setuid root. Note
- that this option must be set to ``yes'' for
- RhostsRSAAuthentication with older servers.
-
- User Specifies the user to log in as. This can be useful when a dif-
- ferent user name is used on different machines. This saves the
- trouble of having to remember to give the user name on the com-
- mand line.
-
- UserKnownHostsFile
- Specifies a file to use for the user host key database instead of
- ~/.ssh/known_hosts.
-
- VerifyHostKeyDNS
- Specifies whether to verify the remote key using DNS and SSHFP
- resource records. If this option is set to ``yes'', the client
- will implicitly trust keys that match a secure fingerprint from
- DNS. Insecure fingerprints will be handled as if this option was
- set to ``ask''. If this option is set to ``ask'', information on
- fingerprint match will be displayed, but the user will still need
- to confirm new host keys according to the StrictHostKeyChecking
- option. The argument must be ``yes'', ``no'', or ``ask''. The
- default is ``no''. Note that this option applies to protocol
- version 2 only.
-
- See also VERIFYING HOST KEYS in ssh(1).
-
- XAuthLocation
- Specifies the full pathname of the xauth(1) program. The default
- is /usr/X11R6/bin/xauth.
-
-PATTERNS
- A pattern consists of zero or more non-whitespace characters, `*' (a
- wildcard that matches zero or more characters), or `?' (a wildcard that
- matches exactly one character). For example, to specify a set of decla-
- rations for any host in the ``.co.uk'' set of domains, the following pat-
- tern could be used:
-
- Host *.co.uk
-
- The following pattern would match any host in the 192.168.0.[0-9] network
- range:
-
- Host 192.168.0.?
-
- A pattern-list is a comma-separated list of patterns. Patterns within
- pattern-lists may be negated by preceding them with an exclamation mark
- (`!'). For example, to allow a key to be used from anywhere within an
- organisation except from the ``dialup'' pool, the following entry (in au-
- thorized_keys) could be used:
-
- from="!*.dialup.example.com,*.example.com"
-
-FILES
- ~/.ssh/config
- This is the per-user configuration file. The format of this file
- is described above. This file is used by the SSH client. Be-
- cause of the potential for abuse, this file must have strict per-
- missions: read/write for the user, and not accessible by others.
-
- /etc/ssh/ssh_config
- Systemwide configuration file. This file provides defaults for
- those values that are not specified in the user's configuration
- file, and for those users who do not have a configuration file.
- This file must be world-readable.
-
-SEE ALSO
- ssh(1)
-
-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 cre-
- ated OpenSSH. Markus Friedl contributed the support for SSH protocol
- versions 1.5 and 2.0.
-
-OpenBSD 4.0 September 25, 1999 10
+++ /dev/null
-SSHD(8) OpenBSD System Manager's Manual SSHD(8)
-
-NAME
- sshd - OpenSSH SSH daemon
-
-SYNOPSIS
- sshd [-46Ddeiqt] [-b bits] [-f config_file] [-g login_grace_time]
- [-h host_key_file] [-k key_gen_time] [-o option] [-p port] [-u len]
-
-DESCRIPTION
- sshd (OpenSSH Daemon) is the daemon program for ssh(1). Together these
- programs replace rlogin and rsh, and provide secure encrypted communica-
- tions between two untrusted hosts over an insecure network.
-
- sshd listens for connections from clients. It is normally started at
- boot from /etc/rc. It forks a new daemon for each incoming connection.
- The forked daemons handle key exchange, encryption, authentication, com-
- mand execution, and data exchange.
-
- sshd can be configured using command-line options or a configuration file
- (by default sshd_config(5)); command-line options override values speci-
- fied in the configuration file. sshd rereads its configuration file when
- it receives a hangup signal, SIGHUP, by executing itself with the name
- and options it was started with, e.g. /usr/sbin/sshd.
-
- The options are as follows:
-
- -4 Forces sshd to use IPv4 addresses only.
-
- -6 Forces sshd to use IPv6 addresses only.
-
- -b bits
- Specifies the number of bits in the ephemeral protocol version 1
- server key (default 768).
-
- -D When this option is specified, sshd will not detach and does not
- become a daemon. This allows easy monitoring of sshd.
-
- -d Debug mode. The server sends verbose debug output to the system
- log, and does not put itself in the background. The server also
- will not fork and will only process one connection. This option
- is only intended for debugging for the server. Multiple -d op-
- tions increase the debugging level. Maximum is 3.
-
- -e When this option is specified, sshd will send the output to the
- standard error instead of the system log.
-
- -f configuration_file
- Specifies the name of the configuration file. The default is
- /etc/ssh/sshd_config. sshd refuses to start if there is no con-
- figuration file.
-
- -g login_grace_time
- Gives the grace time for clients to authenticate themselves (de-
- fault 120 seconds). If the client fails to authenticate the user
- within this many seconds, the server disconnects and exits. A
- value of zero indicates no limit.
-
- -h host_key_file
- Specifies a file from which a host key is read. This option must
- be given if sshd is not run as root (as the normal host key files
- are normally not readable by anyone but root). The default is
- /etc/ssh/ssh_host_key for protocol version 1, and
- /etc/ssh/ssh_host_rsa_key and /etc/ssh/ssh_host_dsa_key for pro-
- tocol version 2. It is possible to have multiple host key files
- for the different protocol versions and host key algorithms.
-
- -i Specifies that sshd is being run from inetd(8). sshd is normally
- not run from inetd because it needs to generate the server key
- before it can respond to the client, and this may take tens of
- seconds. Clients would have to wait too long if the key was re-
- generated every time. However, with small key sizes (e.g. 512)
- using sshd from inetd may be feasible.
-
- -k key_gen_time
- Specifies how often the ephemeral protocol version 1 server key
- is regenerated (default 3600 seconds, or one hour). The motiva-
- tion for regenerating the key fairly often is that the key is not
- stored anywhere, and after about an hour it becomes impossible to
- recover the key for decrypting intercepted communications even if
- the machine is cracked into or physically seized. A value of ze-
- ro indicates that the key will never be regenerated.
-
- -o option
- Can be used to give options in the format used in the configura-
- tion file. This is useful for specifying options for which there
- is no separate command-line flag. For full details of the op-
- tions, and their values, see sshd_config(5).
-
- -p port
- Specifies the port on which the server listens for connections
- (default 22). Multiple port options are permitted. Ports speci-
- fied in the configuration file with the Port option are ignored
- when a command-line port is specified. Ports specified using the
- ListenAddress option override command-line ports.
-
- -q Quiet mode. Nothing is sent to the system log. Normally the be-
- ginning, authentication, and termination of each connection is
- logged.
-
- -t Test mode. Only check the validity of the configuration file and
- sanity of the keys. This is useful for updating sshd reliably as
- configuration options may change.
-
- -u len This option is used to specify the size of the field in the utmp
- structure that holds the remote host name. If the resolved host
- name is longer than len, the dotted decimal value will be used
- instead. This allows hosts with very long host names that over-
- flow this field to still be uniquely identified. Specifying -u0
- indicates that only dotted decimal addresses should be put into
- the utmp file. -u0 may also be used to prevent sshd from making
- DNS requests unless the authentication mechanism or configuration
- requires it. Authentication mechanisms that may require DNS in-
- clude RhostsRSAAuthentication, HostbasedAuthentication, and using
- a from="pattern-list" option in a key file. Configuration op-
- tions that require DNS include using a USER@HOST pattern in
- AllowUsers or DenyUsers.
-
-AUTHENTICATION
- The OpenSSH SSH daemon supports SSH protocols 1 and 2. Both protocols
- are supported by default, though this can be changed via the Protocol op-
- tion in sshd_config(5). Protocol 2 supports both RSA and DSA keys; pro-
- tocol 1 only supports RSA keys. For both protocols, each host has a
- host-specific key, normally 2048 bits, used to identify the host.
-
- Forward security for protocol 1 is provided through an additional server
- key, normally 768 bits, generated when the server starts. This key is
- normally regenerated every hour if it has been used, and is never stored
- on disk. Whenever a client connects, the daemon responds with its public
- host and server keys. The client compares the RSA host key against its
- own database to verify that it has not changed. The client then gener-
- ates a 256-bit random number. It encrypts this random number using both
- the host key and the server key, and sends the encrypted number to the
- server. Both sides then use this random number as a session key which is
- used to encrypt all further communications in the session. The rest of
- the session is encrypted using a conventional cipher, currently Blowfish
- or 3DES, with 3DES being used by default. The client selects the encryp-
- tion algorithm to use from those offered by the server.
-
- For protocol 2, forward security is provided through a Diffie-Hellman key
- agreement. This key agreement results in a shared session key. The rest
- of the session is encrypted using a symmetric cipher, currently 128-bit
- AES, Blowfish, 3DES, CAST128, Arcfour, 192-bit AES, or 256-bit AES. The
- client selects the encryption algorithm to use from those offered by the
- server. Additionally, session integrity is provided through a crypto-
- graphic message authentication code (hmac-sha1 or hmac-md5).
-
- Finally, the server and the client enter an authentication dialog. The
- client tries to authenticate itself using host-based authentication, pub-
- lic key authentication, challenge-response authentication, or password
- authentication.
-
- Regardless of the authentication type, the account is checked to ensure
- that it is accessible. An account is not accessible if it is locked,
- listed in DenyUsers or its group is listed in DenyGroups . The defini-
- tion of a locked account is system dependant. Some platforms have their
- own account database (eg AIX) and some modify the passwd field ( `*LK*'
- on Solaris and UnixWare, `*' on HP-UX, containing `Nologin' on Tru64, a
- leading `*LOCKED*' on FreeBSD and a leading `!!' on Linux). If there is
- a requirement to disable password authentication for the account while
- allowing still public-key, then the passwd field should be set to some-
- thing other than these values (eg `NP' or `*NP*' ).
-
- If the client successfully authenticates itself, a dialog for preparing
- the session is entered. At this time the client may request things like
- allocating a pseudo-tty, forwarding X11 connections, forwarding TCP con-
- nections, or forwarding the authentication agent connection over the se-
- cure channel.
-
- After this, the client either requests a shell or execution of a command.
- The sides then enter session mode. In this mode, either side may send
- data at any time, and such data is forwarded to/from the shell or command
- on the server side, and the user terminal in the client side.
-
- When the user program terminates and all forwarded X11 and other connec-
- tions have been closed, the server sends command exit status to the
- client, and both sides exit.
-
-LOGIN PROCESS
- When a user successfully logs in, sshd does the following:
-
- 1. If the login is on a tty, and no command has been specified,
- prints last login time and /etc/motd (unless prevented in the
- configuration file or by ~/.hushlogin; see the FILES section).
-
- 2. If the login is on a tty, records login time.
-
- 3. Checks /etc/nologin; if it exists, prints contents and quits
- (unless root).
-
- 4. Changes to run with normal user privileges.
-
- 5. Sets up basic environment.
-
- 6. Reads the file ~/.ssh/environment, if it exists, and users are
- allowed to change their environment. See the
- PermitUserEnvironment option in sshd_config(5).
-
- 7. Changes to user's home directory.
-
- 8. If ~/.ssh/rc exists, runs it; else if /etc/ssh/sshrc exists,
- runs it; otherwise runs xauth. The ``rc'' files are given the
- X11 authentication protocol and cookie in standard input. See
- SSHRC, below.
-
- 9. Runs user's shell or command.
-
-SSHRC
- If the file ~/.ssh/rc exists, sh(1) runs it after reading the environment
- files but before starting the user's shell or command. It must not pro-
- duce any output on stdout; stderr must be used instead. If X11 forward-
- ing is in use, it will receive the "proto cookie" pair in its standard
- input (and DISPLAY in its environment). The script must call xauth(1)
- because sshd will not run xauth automatically to add X11 cookies.
-
- The primary purpose of this file is to run any initialization routines
- which may be needed before the user's home directory becomes accessible;
- AFS is a particular example of such an environment.
-
- This file will probably contain some initialization code followed by
- something similar to:
-
- if read proto cookie && [ -n "$DISPLAY" ]; then
- if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
- # X11UseLocalhost=yes
- echo add unix:`echo $DISPLAY |
- cut -c11-` $proto $cookie
- else
- # X11UseLocalhost=no
- echo add $DISPLAY $proto $cookie
- fi | xauth -q -
- fi
-
- If this file does not exist, /etc/ssh/sshrc is run, and if that does not
- exist either, xauth is used to add the cookie.
-
-AUTHORIZED_KEYS FILE FORMAT
- AuthorizedKeysFile specifies the file containing public keys for public
- key authentication; if none is specified, the default is
- ~/.ssh/authorized_keys. Each line of the file contains one key (empty
- lines and lines starting with a `#' are ignored as comments). Protocol 1
- public keys consist of the following space-separated fields: options,
- bits, exponent, modulus, comment. Protocol 2 public key consist of: op-
- tions, keytype, base64-encoded key, comment. The options field is op-
- tional; its presence is determined by whether the line starts with a num-
- ber or not (the options field never starts with a number). The bits, ex-
- ponent, modulus, and comment fields give the RSA key for protocol version
- 1; the comment field is not used for anything (but may be convenient for
- the user to identify the key). For protocol version 2 the keytype is
- ``ssh-dss'' or ``ssh-rsa''.
-
- Note that lines in this file are usually several hundred bytes long (be-
- cause of the size of the public key encoding) up to a limit of 8 kilo-
- bytes, which permits DSA keys up to 8 kilobits and RSA keys up to 16
- kilobits. You don't want to type them in; instead, copy the
- identity.pub, id_dsa.pub, or the id_rsa.pub file and edit it.
-
- sshd enforces a minimum RSA key modulus size for protocol 1 and protocol
- 2 keys of 768 bits.
-
- The options (if present) consist of comma-separated option specifica-
- tions. No spaces are permitted, except within double quotes. The fol-
- lowing option specifications are supported (note that option keywords are
- case-insensitive):
-
- command="command"
- Specifies that the command is executed whenever this key is used
- for authentication. The command supplied by the user (if any) is
- ignored. The command is run on a pty if the client requests a
- pty; otherwise it is run without a tty. If an 8-bit clean chan-
- nel is required, one must not request a pty or should specify no-
- pty. A quote may be included in the command by quoting it with a
- backslash. This option might be useful to restrict certain pub-
- lic keys to perform just a specific operation. An example might
- be a key that permits remote backups but nothing else. Note that
- the client may specify TCP and/or X11 forwarding unless they are
- explicitly prohibited. The command originally supplied by the
- client is available in the SSH_ORIGINAL_COMMAND environment vari-
- able. Note that this option applies to shell, command or subsys-
- tem execution.
-
- environment="NAME=value"
- Specifies that the string is to be added to the environment when
- logging in using this key. Environment variables set this way
- override other default environment values. Multiple options of
- this type are permitted. Environment processing is disabled by
- default and is controlled via the PermitUserEnvironment option.
- This option is automatically disabled if UseLogin is enabled.
-
- from="pattern-list"
- Specifies that in addition to public key authentication, the
- canonical name of the remote host must be present in the comma-
- separated list of patterns. The purpose of this option is to op-
- tionally increase security: public key authentication by itself
- does not trust the network or name servers or anything (but the
- key); however, if somebody somehow steals the key, the key per-
- mits an intruder to log in from anywhere in the world. This ad-
- ditional option makes using a stolen key more difficult (name
- servers and/or routers would have to be compromised in addition
- to just the key).
-
- See PATTERNS in ssh_config(5) for more information on patterns.
-
- no-agent-forwarding
- Forbids authentication agent forwarding when this key is used for
- authentication.
-
- no-port-forwarding
- Forbids TCP forwarding when this key is used for authentication.
- Any port forward requests by the client will return an error.
- This might be used, e.g. in connection with the command option.
-
- no-pty Prevents tty allocation (a request to allocate a pty will fail).
-
- no-X11-forwarding
- Forbids X11 forwarding when this key is used for authentication.
- Any X11 forward requests by the client will return an error.
-
- permitopen="host:port"
- Limit local ``ssh -L'' port forwarding such that it may only con-
- nect to the specified host and port. IPv6 addresses can be spec-
- ified with an alternative syntax: host/port. Multiple permitopen
- options may be applied separated by commas. No pattern matching
- is performed on the specified hostnames, they must be literal do-
- mains or addresses.
-
- tunnel="n"
- Force a tun(4) device on the server. Without this option, the
- next available device will be used if the client requests a tun-
- nel.
-
- An example authorized_keys file:
-
- # Comments allowed at start of line
- ssh-rsa AAAAB3Nza...LiPk== user@example.net
- from="*.sales.example.net,!pc.sales.example.net" ssh-rsa
- AAAAB2...19Q== john@example.net
- command="dump /home",no-pty,no-port-forwarding ssh-dss
- AAAAC3...51R== example.net
- permitopen="192.0.2.1:80",permitopen="192.0.2.2:25" ssh-dss
- AAAAB5...21S==
- tunnel="0",command="sh /etc/netstart tun0" ssh-rsa AAAA...==
- jane@example.net
-
-SSH_KNOWN_HOSTS FILE FORMAT
- The /etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts files contain host
- public keys for all known hosts. The global file should be prepared by
- the administrator (optional), and the per-user file is maintained auto-
- matically: whenever the user connects from an unknown host, its key is
- added to the per-user file.
-
- Each line in these files contains the following fields: hostnames, bits,
- exponent, modulus, comment. The fields are separated by spaces.
-
- Hostnames is a comma-separated list of patterns (`*' and `?' act as wild-
- cards); each pattern in turn is matched against the canonical host name
- (when authenticating a client) or against the user-supplied name (when
- authenticating a server). A pattern may also be preceded by `!' to indi-
- cate negation: if the host name matches a negated pattern, it is not ac-
- cepted (by that line) even if it matched another pattern on the line. A
- hostname or address may optionally be enclosed within `[' and `]' brack-
- ets then followed by `:' and a non-standard port number.
-
- Alternately, hostnames may be stored in a hashed form which hides host
- names and addresses should the file's contents be disclosed. Hashed
- hostnames start with a `|' character. Only one hashed hostname may ap-
- pear on a single line and none of the above negation or wildcard opera-
- tors may be applied.
-
- Bits, exponent, and modulus are taken directly from the RSA host key;
- they can be obtained, for example, from /etc/ssh/ssh_host_key.pub. The
- optional comment field continues to the end of the line, and is not used.
-
- Lines starting with `#' and empty lines are ignored as comments.
-
- When performing host authentication, authentication is accepted if any
- matching line has the proper key. It is thus permissible (but not recom-
- mended) to have several lines or different host keys for the same names.
- This will inevitably happen when short forms of host names from different
- domains are put in the file. It is possible that the files contain con-
- flicting information; authentication is accepted if valid information can
- be found from either file.
-
- Note that the lines in these files are typically hundreds of characters
- long, and you definitely don't want to type in the host keys by hand.
- Rather, generate them by a script or by taking /etc/ssh/ssh_host_key.pub
- and adding the host names at the front.
-
- An example ssh_known_hosts file:
-
- # Comments allowed at start of line
- closenet,...,192.0.2.53 1024 37 159...93 closenet.example.net
- cvs.example.net,192.0.2.10 ssh-rsa AAAA1234.....=
- # A hashed hostname
- |1|JfKTdBh7rNbXkVAQCRp4OQoPfmI=|USECr3SWf1JUPsms5AqfD5QfxkM= ssh-rsa
- AAAA1234.....=
-
-FILES
- ~/.hushlogin
- This file is used to suppress printing the last login time and
- /etc/motd, if PrintLastLog and PrintMotd, respectively, are en-
- abled. It does not suppress printing of the banner specified by
- Banner.
-
- ~/.rhosts
- This file is used for host-based authentication (see ssh(1) for
- more information). On some machines this file may need to be
- world-readable if the user's home directory is on an NFS parti-
- tion, because sshd 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.
-
- ~/.shosts
- This file is used in exactly the same way as .rhosts, but allows
- host-based authentication without permitting login with
- rlogin/rsh.
-
- ~/.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 above. The
- content of the file is not highly sensitive, but the recommended
- permissions are read/write for the user, and not accessible by
- others.
-
- If this file, the ~/.ssh directory, or the user's home directory
- are writable by other users, then the file could be modified or
- replaced by unauthorized users. In this case, sshd will not al-
- low it to be used unless the StrictModes option has been set to
- ``no''. The recommended permissions can be set by executing
- ``chmod go-w ~/ ~/.ssh ~/.ssh/authorized_keys''.
-
- ~/.ssh/environment
- This file is read into the environment at login (if it exists).
- It can only contain empty lines, comment lines (that start with
- `#'), and assignment lines of the form name=value. The file
- should be writable only by the user; it need not be readable by
- anyone else. Environment processing is disabled by default and
- is controlled via the PermitUserEnvironment option.
-
- ~/.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. The format of this file is described above. This file
- should be writable only by root/the owner and can, but need not
- be, world-readable.
-
- ~/.ssh/rc
- Contains initialization routines to be run before the user's home
- directory becomes accessible. This file should be writable only
- by the user, and need not be readable by anyone else.
-
- /etc/hosts.allow
- /etc/hosts.deny
- Access controls that should be enforced by tcp-wrappers are de-
- fined here. Further details are described in hosts_access(5).
-
- /etc/hosts.equiv
- This file is for host-based authentication (see ssh(1)). It
- should only be writable by root.
-
- /etc/moduli
- Contains Diffie-Hellman groups used for the "Diffie-Hellman Group
- Exchange". The file format is described in moduli(5).
-
- /etc/motd
- See motd(5).
-
- /etc/nologin
- If this file exists, sshd refuses to let anyone except root log
- in. The contents of the file are displayed to anyone trying to
- log in, and non-root connections are refused. The file should be
- world-readable.
-
- /etc/shosts.equiv
- This file is used in exactly the same way as hosts.equiv, but al-
- lows host-based authentication without permitting login with
- rlogin/rsh.
-
- /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. The format of this file is de-
- scribed above. This file should be writable only by root/the
- owner and should be world-readable.
-
- /etc/ssh/ssh_host_key
- /etc/ssh/ssh_host_dsa_key
- /etc/ssh/ssh_host_rsa_key
- These three files contain the private parts of the host keys.
- These files should only be owned by root, readable only by root,
- and not accessible to others. Note that sshd does not start if
- these files are group/world-accessible.
-
- /etc/ssh/ssh_host_key.pub
- /etc/ssh/ssh_host_dsa_key.pub
- /etc/ssh/ssh_host_rsa_key.pub
- These three files contain the public parts of the host keys.
- These files should be world-readable but writable only by root.
- Their contents should match the respective private parts. These
- files are not really used for anything; they are provided for the
- convenience of the user so their contents can be copied to known
- hosts files. These files are created using ssh-keygen(1).
-
- /etc/ssh/sshd_config
- Contains configuration data for sshd. The file format and con-
- figuration options are described in sshd_config(5).
-
- /etc/ssh/sshrc
- Similar to ~/.ssh/rc, it can be used to specify machine-specific
- login-time initializations globally. This file should be
- writable only by root, and should be world-readable.
-
- /var/empty
- chroot(2) directory used by sshd during privilege separation in
- the pre-authentication phase. The directory should not contain
- any files and must be owned by root and not group or world-
- writable.
-
- /var/run/sshd.pid
- Contains the process ID of the sshd listening for connections (if
- there are several daemons running concurrently for different
- ports, this contains the process ID of the one started last).
- The content of this file is not sensitive; it can be world-read-
- able.
-
-SEE ALSO
- scp(1), sftp(1), ssh(1), ssh-add(1), ssh-agent(1), ssh-keygen(1),
- chroot(2), hosts_access(5), login.conf(5), moduli(5), sshd_config(5),
- inetd(8), sftp-server(8)
-
-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 cre-
- ated OpenSSH. Markus Friedl contributed the support for SSH protocol
- versions 1.5 and 2.0. Niels Provos and Markus Friedl contributed support
- for privilege separation.
-
-CAVEATS
- System security is not improved unless rshd, rlogind, and rexecd are dis-
- abled (thus completely disabling rlogin and rsh into the machine).
-
-OpenBSD 4.0 September 25, 1999 9
+++ /dev/null
-SSHD_CONFIG(5) OpenBSD Programmer's Manual SSHD_CONFIG(5)
-
-NAME
- sshd_config - OpenSSH SSH daemon configuration file
-
-SYNOPSIS
- /etc/ssh/sshd_config
-
-DESCRIPTION
- sshd(8) reads configuration data from /etc/ssh/sshd_config (or the file
- specified with -f on the command line). The file contains keyword-argu-
- ment pairs, one per line. Lines starting with `#' and empty lines are
- interpreted as comments. Arguments may optionally be enclosed in double
- quotes (") in order to represent arguments containing spaces.
-
- The possible keywords and their meanings are as follows (note that key-
- words are case-insensitive and arguments are case-sensitive):
-
- AcceptEnv
- Specifies what environment variables sent by the client will be
- copied into the session's environ(7). See SendEnv in
- ssh_config(5) for how to configure the client. Note that envi-
- ronment passing is only supported for protocol 2. Variables are
- specified by name, which may contain the wildcard characters `*'
- and `?'. Multiple environment variables may be separated by
- whitespace or spread across multiple AcceptEnv directives. Be
- warned that some environment variables could be used to bypass
- restricted user environments. For this reason, care should be
- taken in the use of this directive. The default is not to accept
- any environment variables.
-
- AddressFamily
- Specifies which address family should be used by sshd(8). Valid
- arguments are ``any'', ``inet'' (use IPv4 only), or ``inet6''
- (use IPv6 only). The default is ``any''.
-
- AllowGroups
- This keyword can be followed by a list of group name patterns,
- separated by spaces. If specified, login is allowed only for
- users whose primary group or supplementary group list matches one
- of the patterns. Only group names are valid; a numerical group
- ID is not recognized. By default, login is allowed for all
- groups. The allow/deny directives are processed in the following
- order: DenyUsers, AllowUsers, DenyGroups, and finally
- AllowGroups.
-
- See PATTERNS in ssh_config(5) for more information on patterns.
-
- AllowTcpForwarding
- Specifies whether TCP forwarding is permitted. The default is
- ``yes''. Note that disabling TCP forwarding does not improve se-
- curity unless users are also denied shell access, as they can al-
- ways install their own forwarders.
-
- AllowUsers
- This keyword can be followed by a list of user name patterns,
- separated by spaces. If specified, login is allowed only for us-
- er names that match one of the patterns. Only user names are
- valid; a numerical user ID is not recognized. By default, login
- is allowed for all users. If the pattern takes the form US-
- ER@HOST then USER and HOST are separately checked, restricting
- logins to particular users from particular hosts. The allow/deny
- directives are processed in the following order: DenyUsers,
- AllowUsers, DenyGroups, and finally AllowGroups.
-
- See PATTERNS in ssh_config(5) for more information on patterns.
-
- AuthorizedKeysFile
- Specifies the file that contains the public keys that can be used
- for user authentication. AuthorizedKeysFile may contain tokens
- of the form %T which are substituted during connection setup.
- The following tokens are defined: %% is replaced by a literal
- '%', %h is replaced by the home directory of the user being au-
- thenticated, and %u is replaced by the username of that user.
- After expansion, AuthorizedKeysFile is taken to be an absolute
- path or one relative to the user's home directory. The default
- is ``.ssh/authorized_keys''.
-
- Banner In some jurisdictions, sending a warning message before authenti-
- cation may be relevant for getting legal protection. The con-
- tents of the specified file are sent to the remote user before
- authentication is allowed. This option is only available for
- protocol version 2. By default, no banner is displayed.
-
- ChallengeResponseAuthentication
- Specifies whether challenge-response authentication is allowed.
- All authentication styles from login.conf(5) are supported. The
- default is ``yes''.
-
- Ciphers
- Specifies the ciphers allowed for protocol version 2. Multiple
- ciphers must be comma-separated. 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:
-
- aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,
- arcfour256,arcfour,aes192-cbc,aes256-cbc,aes128-ctr,
- aes192-ctr,aes256-ctr
-
- ClientAliveCountMax
- Sets the number of client alive messages (see below) which may be
- sent without sshd(8) receiving any messages back from the client.
- If this threshold is reached while client alive messages are be-
- ing sent, sshd will disconnect the client, terminating the ses-
- sion. It is important to note that the use of client alive mes-
- sages is very different from TCPKeepAlive (below). The client
- alive messages are sent through the encrypted channel and there-
- fore will not be spoofable. The TCP keepalive option enabled by
- TCPKeepAlive is spoofable. The client alive mechanism is valu-
- able when the client or server depend on knowing when a connec-
- tion has become inactive.
-
- The default value is 3. If ClientAliveInterval (see below) is
- set to 15, and ClientAliveCountMax is left at the default, unre-
- sponsive SSH clients will be disconnected after approximately 45
- seconds. This option applies to protocol version 2 only.
-
- ClientAliveInterval
- Sets a timeout interval in seconds after which if no data has
- been received from the client, sshd(8) will send a message
- through the encrypted channel to request a response from the
- client. The default is 0, indicating that these messages will
- not be sent to the client. This option applies to protocol ver-
- sion 2 only.
-
- Compression
- Specifies whether compression is allowed, or delayed until the
- user has authenticated successfully. The argument must be
- ``yes'', ``delayed'', or ``no''. The default is ``delayed''.
-
- DenyGroups
- This keyword can be followed by a list of group name patterns,
- separated by spaces. Login is disallowed for users whose primary
- group or supplementary group list matches one of the patterns.
- Only group names are valid; a numerical group ID is not recog-
- nized. By default, login is allowed for all groups. The al-
- low/deny directives are processed in the following order:
- DenyUsers, AllowUsers, DenyGroups, and finally AllowGroups.
-
- See PATTERNS in ssh_config(5) for more information on patterns.
-
- DenyUsers
- This keyword can be followed by a list of user name patterns,
- separated by spaces. Login is disallowed for user names that
- match one of the patterns. Only user names are valid; a numeri-
- cal user ID is not recognized. By default, login is allowed for
- all users. If the pattern takes the form USER@HOST then USER and
- HOST are separately checked, restricting logins to particular
- users from particular hosts. The allow/deny directives are pro-
- cessed in the following order: DenyUsers, AllowUsers, DenyGroups,
- and finally AllowGroups.
-
- See PATTERNS in ssh_config(5) for more information on patterns.
-
- ForceCommand
- Forces the execution of the command specified by ForceCommand,
- ignoring any command supplied by the client. The command is in-
- voked by using the user's login shell with the -c option. This
- applies to shell, command, or subsystem execution. It is most
- useful inside a Match block. The command originally supplied by
- the client is available in the SSH_ORIGINAL_COMMAND environment
- variable.
-
- GatewayPorts
- Specifies whether remote hosts are allowed to connect to ports
- forwarded for the client. By default, sshd(8) binds remote port
- forwardings to the loopback address. This prevents other remote
- hosts from connecting to forwarded ports. GatewayPorts can be
- used to specify that sshd should allow remote port forwardings to
- bind to non-loopback addresses, thus allowing other hosts to con-
- nect. The argument may be ``no'' to force remote port forward-
- ings to be available to the local host only, ``yes'' to force re-
- mote port forwardings to bind to the wildcard address, or
- ``clientspecified'' to allow the client to select the address to
- which the forwarding is bound. The default is ``no''.
-
- GSSAPIAuthentication
- Specifies whether user authentication based on GSSAPI is allowed.
- The default is ``no''. Note that this option applies to protocol
- version 2 only.
-
- GSSAPICleanupCredentials
- Specifies whether to automatically destroy the user's credentials
- cache on logout. The default is ``yes''. Note that this option
- applies to protocol version 2 only.
-
- HostbasedAuthentication
- Specifies whether rhosts or /etc/hosts.equiv authentication to-
- gether with successful public key client host authentication is
- allowed (host-based authentication). This option is similar to
- RhostsRSAAuthentication and applies to protocol version 2 only.
- The default is ``no''.
-
- HostbasedUsesNameFromPacketOnly
- Specifies whether or not the server will attempt to perform a re-
- verse name lookup when matching the name in the ~/.shosts,
- ~/.rhosts, and /etc/hosts.equiv files during
- HostbasedAuthentication. A setting of ``yes'' means that sshd(8)
- uses the name supplied by the client rather than attempting to
- resolve the name from the TCP connection itself. The default is
- ``no''.
-
- HostKey
- Specifies a file containing a private host key used by SSH. The
- default is /etc/ssh/ssh_host_key for protocol version 1, and
- /etc/ssh/ssh_host_rsa_key and /etc/ssh/ssh_host_dsa_key for pro-
- tocol version 2. Note that sshd(8) will refuse to use a file if
- it is group/world-accessible. It is possible to have multiple
- host key files. ``rsa1'' keys are used for version 1 and ``dsa''
- or ``rsa'' are used for version 2 of the SSH protocol.
-
- IgnoreRhosts
- Specifies that .rhosts and .shosts files will not be used in
- RhostsRSAAuthentication or HostbasedAuthentication.
-
- /etc/hosts.equiv and /etc/shosts.equiv are still used. The de-
- fault is ``yes''.
-
- IgnoreUserKnownHosts
- Specifies whether sshd(8) should ignore the user's
- ~/.ssh/known_hosts during RhostsRSAAuthentication or
- HostbasedAuthentication. The default is ``no''.
-
- KerberosAuthentication
- Specifies whether the password provided by the user for
- PasswordAuthentication will be validated through the Kerberos
- KDC. To use this option, the server needs a Kerberos servtab
- which allows the verification of the KDC's identity. The default
- is ``no''.
-
- KerberosGetAFSToken
- If AFS is active and the user has a Kerberos 5 TGT, attempt to
- acquire an AFS token before accessing the user's home directory.
- The default is ``no''.
-
- KerberosOrLocalPasswd
- If password authentication through Kerberos fails then the pass-
- word will be validated via any additional local mechanism such as
- /etc/passwd. The default is ``yes''.
-
- KerberosTicketCleanup
- Specifies whether to automatically destroy the user's ticket
- cache file on logout. The default is ``yes''.
-
- KeyRegenerationInterval
- In protocol version 1, the ephemeral server key is automatically
- regenerated after this many seconds (if it has been used). The
- purpose of regeneration is to prevent decrypting captured ses-
- sions by later breaking into the machine and stealing the keys.
- The key is never stored anywhere. If the value is 0, the key is
- never regenerated. The default is 3600 (seconds).
-
- ListenAddress
- Specifies the local addresses sshd(8) should listen on. The fol-
- lowing forms may be used:
-
- ListenAddress host|IPv4_addr|IPv6_addr
- ListenAddress host|IPv4_addr:port
- ListenAddress [host|IPv6_addr]:port
-
- If port is not specified, sshd will listen on the address and all
- prior Port options specified. The default is to listen on all
- local addresses. Multiple ListenAddress options are permitted.
- Additionally, any Port options must precede this option for non-
- port qualified addresses.
-
- LoginGraceTime
- The server disconnects after this time if the user has not suc-
- cessfully logged in. If the value is 0, there is no time limit.
- The default is 120 seconds.
-
- LogLevel
- Gives the verbosity level that is used when logging messages from
- sshd(8). The possible values are: QUIET, FATAL, ERROR, INFO,
- VERBOSE, DEBUG, DEBUG1, DEBUG2, and DEBUG3. The default is INFO.
- DEBUG and DEBUG1 are equivalent. DEBUG2 and DEBUG3 each specify
- higher levels of debugging output. Logging with a DEBUG level
- violates the privacy of users and is not recommended.
-
- MACs Specifies the available MAC (message authentication code) algo-
- rithms. The MAC algorithm is used in protocol version 2 for data
- integrity protection. Multiple algorithms must be comma-separat-
- ed. The default is: ``hmac-md5,hmac-sha1,hmac-ripemd160,hmac-
- sha1-96,hmac-md5-96''.
-
- Match Introduces a conditional block. If all of the criteria on the
- Match line are satisfied, the keywords on the following lines
- override those set in the global section of the config file, un-
- til either another Match line or the end of the file. The argu-
- ments to Match are one or more criteria-pattern pairs. The
- available criteria are User, Group, Host, and Address. Only a
- subset of keywords may be used on the lines following a Match
- keyword. Available keywords are AllowTcpForwarding,
- ForceCommand, GatewayPorts, PermitOpen, X11DisplayOffset,
- X11Forwarding, and X11UseLocalHost.
-
- MaxAuthTries
- Specifies the maximum number of authentication attempts permitted
- per connection. Once the number of failures reaches half this
- value, additional failures are logged. The default is 6.
-
- MaxStartups
- Specifies the maximum number of concurrent unauthenticated con-
- nections to the SSH daemon. Additional connections will be
- dropped until authentication succeeds or the LoginGraceTime ex-
- pires for a connection. The default is 10.
-
- Alternatively, random early drop can be enabled by specifying the
- three colon separated values ``start:rate:full'' (e.g.
- "10:30:60"). sshd(8) will refuse connection attempts with a
- probability of ``rate/100'' (30%) if there are currently
- ``start'' (10) unauthenticated connections. The probability in-
- creases linearly and all connection attempts are refused if the
- number of unauthenticated connections reaches ``full'' (60).
-
- PasswordAuthentication
- Specifies whether password authentication is allowed. The de-
- fault is ``yes''.
-
- PermitEmptyPasswords
- When password authentication is allowed, it specifies whether the
- server allows login to accounts with empty password strings. The
- default is ``no''.
-
- PermitOpen
- Specifies the destinations to which TCP port forwarding is per-
- mitted. The forwarding specification must be one of the follow-
- ing forms:
-
- PermitOpen host:port
- PermitOpen IPv4_addr:port
- PermitOpen [IPv6_addr]:port
-
- Multiple forwards may be specified by separating them with
- whitespace. An argument of ``any'' can be used to remove all re-
- strictions and permit any forwarding requests. By default all
- port forwarding requests are permitted.
-
- PermitRootLogin
- Specifies whether root can log in using ssh(1). The argument
- must be ``yes'', ``without-password'', ``forced-commands-only'',
- or ``no''. The default is ``yes''.
-
- If this option is set to ``without-password'', password authenti-
- cation is disabled for root.
-
- If this option is set to ``forced-commands-only'', root login
- with public key authentication will be allowed, but only if the
- command option has been specified (which may be useful for taking
- remote backups even if root login is normally not allowed). All
- other authentication methods are disabled for root.
-
- If this option is set to ``no'', root is not allowed to log in.
-
- PermitTunnel
- Specifies whether tun(4) device forwarding is allowed. The argu-
- ment must be ``yes'', ``point-to-point'' (layer 3), ``ethernet''
- (layer 2), or ``no''. Specifying ``yes'' permits both ``point-
- to-point'' and ``ethernet''. The default is ``no''.
-
- PermitUserEnvironment
- Specifies whether ~/.ssh/environment and environment= options in
- ~/.ssh/authorized_keys are processed by sshd(8). The default is
- ``no''. Enabling environment processing may enable users to by-
- pass access restrictions in some configurations using mechanisms
- such as LD_PRELOAD.
-
- PidFile
- Specifies the file that contains the process ID of the SSH dae-
- mon. The default is /var/run/sshd.pid.
-
- Port Specifies the port number that sshd(8) listens on. The default
- is 22. Multiple options of this type are permitted. See also
- ListenAddress.
-
- PrintLastLog
- Specifies whether sshd(8) should print the date and time of the
- last user login when a user logs in interactively. The default
- is ``yes''.
-
- PrintMotd
- Specifies whether sshd(8) should print /etc/motd when a user logs
- in interactively. (On some systems it is also printed by the
- shell, /etc/profile, or equivalent.) The default is ``yes''.
-
- Protocol
- Specifies the protocol versions sshd(8) supports. The possible
- values are `1' and `2'. Multiple versions must be comma-separat-
- ed. The default is ``2,1''. Note that the order of the protocol
- list does not indicate preference, because the client selects
- among multiple protocol versions offered by the server. Specify-
- ing ``2,1'' is identical to ``1,2''.
-
- PubkeyAuthentication
- Specifies whether public key authentication is allowed. The de-
- fault is ``yes''. Note that this option applies to protocol ver-
- sion 2 only.
-
- RhostsRSAAuthentication
- Specifies whether rhosts or /etc/hosts.equiv authentication to-
- gether with successful RSA host authentication is allowed. The
- default is ``no''. This option applies to protocol version 1 on-
- ly.
-
- RSAAuthentication
- Specifies whether pure RSA authentication is allowed. The de-
- fault is ``yes''. This option applies to protocol version 1 on-
- ly.
-
- ServerKeyBits
- Defines the number of bits in the ephemeral protocol version 1
- server key. The minimum value is 512, and the default is 768.
-
- StrictModes
- Specifies whether sshd(8) should check file modes and ownership
- of the user's files and home directory before accepting login.
- This is normally desirable because novices sometimes accidentally
- leave their directory or files world-writable. The default is
- ``yes''.
-
- Subsystem
- Configures an external subsystem (e.g. file transfer daemon).
- Arguments should be a subsystem name and a command (with optional
- arguments) to execute upon subsystem request. The command
- sftp-server(8) implements the ``sftp'' file transfer subsystem.
- By default no subsystems are defined. Note that this option ap-
- plies to protocol version 2 only.
-
- SyslogFacility
- Gives the facility code that is used when logging messages from
- sshd(8). The possible values are: DAEMON, USER, AUTH, LOCAL0,
- LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7. The de-
- fault is AUTH.
-
- TCPKeepAlive
- Specifies whether the system should send TCP keepalive messages
- to the other side. If they are sent, death of the connection or
- crash of one of the machines will be properly noticed. However,
- this means that connections will die if the route is down tem-
- porarily, and some people find it annoying. On the other hand,
- if TCP keepalives are not sent, sessions may hang indefinitely on
- the server, leaving ``ghost'' users and consuming server re-
- sources.
-
- The default is ``yes'' (to send TCP keepalive messages), and the
- server will notice if the network goes down or the client host
- crashes. This avoids infinitely hanging sessions.
-
- To disable TCP keepalive messages, the value should be set to
- ``no''.
-
- UseDNS Specifies whether sshd(8) should look up the remote host name and
- check that the resolved host name for the remote IP address maps
- back to the very same IP address. The default is ``yes''.
-
- UseLogin
- Specifies whether login(1) is used for interactive login ses-
- sions. The default is ``no''. Note that login(1) is never used
- for remote command execution. Note also, that if this is en-
- abled, X11Forwarding will be disabled because login(1) does not
- know how to handle xauth(1) cookies. If UsePrivilegeSeparation
- is specified, it will be disabled after authentication.
-
- UsePAM Enables the Pluggable Authentication Module interface. If set to
- ``yes'' this will enable PAM authentication using
- ChallengeResponseAuthentication and PasswordAuthentication in ad-
- dition to PAM account and session module processing for all au-
- thentication types.
-
- Because PAM challenge-response authentication usually serves an
- equivalent role to password authentication, you should disable
- either PasswordAuthentication or ChallengeResponseAuthentication.
-
- If UsePAM is enabled, you will not be able to run sshd(8) as a
- non-root user. The default is ``no''.
-
- UsePrivilegeSeparation
- Specifies whether sshd(8) separates privileges by creating an un-
- privileged child process to deal with incoming network traffic.
- After successful authentication, another process will be created
- that has the privilege of the authenticated user. The goal of
- privilege separation is to prevent privilege escalation by con-
- taining any corruption within the unprivileged processes. The
- default is ``yes''.
-
- X11DisplayOffset
- Specifies the first display number available for sshd(8)'s X11
- forwarding. This prevents sshd from interfering with real X11
- servers. The default is 10.
-
- X11Forwarding
- Specifies whether X11 forwarding is permitted. The argument must
- be ``yes'' or ``no''. The default is ``no''.
-
- When X11 forwarding is enabled, there may be additional exposure
- to the server and to client displays if the sshd(8) proxy display
- is configured to listen on the wildcard address (see
- X11UseLocalhost below), though this is not the default. Addi-
- tionally, the authentication spoofing and authentication data
- verification and substitution occur on the client side. The se-
- curity risk of using X11 forwarding is that the client's X11 dis-
- play server may be exposed to attack when the SSH client requests
- forwarding (see the warnings for ForwardX11 in ssh_config(5)). A
- system administrator may have a stance in which they want to pro-
- tect clients that may expose themselves to attack by unwittingly
- requesting X11 forwarding, which can warrant a ``no'' setting.
-
- Note that disabling X11 forwarding does not prevent users from
- forwarding X11 traffic, as users can always install their own
- forwarders. X11 forwarding is automatically disabled if UseLogin
- is enabled.
-
- X11UseLocalhost
- Specifies whether sshd(8) should bind the X11 forwarding server
- to the loopback address or to the wildcard address. By default,
- sshd binds the forwarding server to the loopback address and sets
- the hostname part of the DISPLAY environment variable to
- ``localhost''. This prevents remote hosts from connecting to the
- proxy display. However, some older X11 clients may not function
- with this configuration. X11UseLocalhost may be set to ``no'' to
- specify that the forwarding server should be bound to the wild-
- card address. The argument must be ``yes'' or ``no''. The de-
- fault is ``yes''.
-
- XAuthLocation
- Specifies the full pathname of the xauth(1) program. The default
- is /usr/X11R6/bin/xauth.
-
-TIME FORMATS
- sshd(8) command-line arguments and configuration file options that speci-
- fy time may be expressed using a sequence of the form: time[qualifier],
- where time is a positive integer value and qualifier is one of the fol-
- lowing:
-
- <none> seconds
- s | S seconds
- m | M minutes
- h | H hours
- d | D days
- w | W weeks
-
- Each member of the sequence is added together to calculate the total time
- value.
-
- Time format examples:
-
- 600 600 seconds (10 minutes)
- 10m 10 minutes
- 1h30m 1 hour 30 minutes (90 minutes)
-
-FILES
- /etc/ssh/sshd_config
- Contains configuration data for sshd(8). This file should be
- writable by root only, but it is recommended (though not neces-
- sary) that it be world-readable.
-
-SEE ALSO
- sshd(8)
-
-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 cre-
- ated OpenSSH. Markus Friedl contributed the support for SSH protocol
- versions 1.5 and 2.0. Niels Provos and Markus Friedl contributed support
- for privilege separation.
-
-OpenBSD 4.0 September 25, 1999 9
andersk / gssapi-openssh.git / commitdiff
