From: jbasney Date: Fri, 10 Nov 2006 22:12:10 +0000 (+0000) Subject: remove derived files from cvs X-Git-Tag: OPENSSH_4_5p1_GSSAPI_NCSA_GSSAPI_20061110~1 X-Git-Url: http://andersk.mit.edu/gitweb/gssapi-openssh.git/commitdiff_plain/f9b9cace56c3037e5bfd034d59aff01e72d92ba6 remove derived files from cvs --- diff --git a/openssh/scp.0 b/openssh/scp.0 deleted file mode 100644 index aac1628..0000000 --- a/openssh/scp.0 +++ /dev/null @@ -1,144 +0,0 @@ -SCP(1) BSD General Commands 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 - passphrases). - - -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 - Tatu Ylonen - -BSD September 25, 1999 BSD diff --git a/openssh/sftp-server.0 b/openssh/sftp-server.0 deleted file mode 100644 index b30e1af..0000000 --- a/openssh/sftp-server.0 +++ /dev/null @@ -1,46 +0,0 @@ -SFTP-SERVER(8) BSD 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 - intended to be called directly, but from sshd(8) using the Subsystem - option. - - 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, - DEBUG1, 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 - -BSD August 30, 2000 BSD diff --git a/openssh/sftp.0 b/openssh/sftp.0 deleted file mode 100644 index d5947c0..0000000 --- a/openssh/sftp.0 +++ /dev/null @@ -1,266 +0,0 @@ -SFTP(1) BSD General Commands 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 - interactive 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 - instead 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 direc- - tory. 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 - remote path name is not specified, it is given the same name it - has on the local machine. local-path may contain glob(3) charac- - ters 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. - -BSD February 4, 2001 BSD diff --git a/openssh/ssh-add.0 b/openssh/ssh-add.0 deleted file mode 100644 index 9dbb5bd..0000000 --- a/openssh/ssh-add.0 +++ /dev/null @@ -1,102 +0,0 @@ -SSH-ADD(1) BSD General Commands 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. - -BSD September 25, 1999 BSD diff --git a/openssh/ssh-agent.0 b/openssh/ssh-agent.0 deleted file mode 100644 index f446396..0000000 --- a/openssh/ssh-agent.0 +++ /dev/null @@ -1,117 +0,0 @@ -SSH-AGENT(1) BSD General Commands 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 - default is /tmp/ssh-XXXXXXXXXX/agent.. - - -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. - Instead, 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 - another 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. - 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. - -BSD September 25, 1999 BSD diff --git a/openssh/ssh-keygen.0 b/openssh/ssh-keygen.0 deleted file mode 100644 index a0eeb23..0000000 --- a/openssh/ssh-keygen.0 +++ /dev/null @@ -1,288 +0,0 @@ -SSH-KEYGEN(1) BSD General Commands 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 - series of words, punctuation, numbers, whitespace, or any string of char- - acters you want. Good passphrases are 10-30 characters long, are not - simple 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- - alphanumeric 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 - exactly 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 - addresses 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 - intensive process. These candidate primes are then tested for suitabil- - ity (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 - user. 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 - user. 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 - user. 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 cre- - ated OpenSSH. Markus Friedl contributed the support for SSH protocol - versions 1.5 and 2.0. - -BSD September 25, 1999 BSD diff --git a/openssh/ssh-keyscan.0 b/openssh/ssh-keyscan.0 deleted file mode 100644 index 3725c89..0000000 --- a/openssh/ssh-keyscan.0 +++ /dev/null @@ -1,107 +0,0 @@ -SSH-KEYSCAN(1) BSD General Commands 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. - Default 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 - attacks 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 wrote the initial version, and Wayne - Davison 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. - -BSD January 1, 1996 BSD diff --git a/openssh/ssh-keysign.0 b/openssh/ssh-keysign.0 deleted file mode 100644 index 43045ba..0000000 --- a/openssh/ssh-keysign.0 +++ /dev/null @@ -1,42 +0,0 @@ -SSH-KEYSIGN(8) BSD 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 - -BSD May 24, 2002 BSD diff --git a/openssh/ssh-rand-helper.0 b/openssh/ssh-rand-helper.0 deleted file mode 100644 index 983e5be..0000000 --- a/openssh/ssh-rand-helper.0 +++ /dev/null @@ -1,49 +0,0 @@ -SSH-RAND-HELPER(8) BSD 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 - -SEE ALSO - ssh(1), ssh-add(1), ssh-keygen(1), sshd(8) - -BSD April 14, 2002 BSD diff --git a/openssh/ssh.0 b/openssh/ssh.0 deleted file mode 100644 index 3d2c669..0000000 --- a/openssh/ssh.0 +++ /dev/null @@ -1,824 +0,0 @@ -SSH(1) BSD General Commands 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 - untrusted 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 - below). - - 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 - address. - - -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. - Dynamic port forwardings can also be specified in the configura- - tion 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 - default, 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 - passphrases, 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 - (default 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/hostport 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. 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. - - -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. - Refer to the description of ControlMaster in ssh_config(5) for - details. - - -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 - machine. For example, ssh -n shadows.cs.hut.fi emacs & will - start an emacs on shadows.cs.hut.fi, and the X11 connection will - be automatically forwarded over an encrypted channel. The 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 - options 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 - server'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 - facilitate the use of SSH as a secure transport for other appli- - cations (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) - devices 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 - extension restrictions by default. Please refer to the ssh -Y - option 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- - response authentication, and password authentication. Authentication - methods are tried in the order specified above, though protocol 2 has a - configuration option to change the default order: - 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 - security 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 - user 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 - allows multiple challenges and responses; protocol 1 is restricted to - just one challenge/response. Examples of challenge-response authentica- - tion 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 - authentication 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 - either executes the given command, or logs into the machine and gives the - user a normal shell on the remote machine. All communication with the - remote command or shell will be automatically encrypted. - - 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 - allows 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 - remote 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 - securely. 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 - remote network 10.0.99.0/24, provided that the SSH server running on the - gateway to the remote network, at 192.168.1.15, allows it: - - # 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-sepa- - rated values: client IP address, client port num- - ber, 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 - device) associated with the current shell or com- - mand. 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 - allowed 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 - user'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 - 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 in the - sshd(8) manual page. This file is not highly sensitive, but the - recommended permissions are read/write for the user, and not - accessible by others. - - ~/.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 - allows 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 - only by root. For protocol version 2, ssh uses ssh-keysign(8) to - access the host keys, eliminating the requirement that ssh be - setuid 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 cre- - ated OpenSSH. Markus Friedl contributed the support for SSH protocol - versions 1.5 and 2.0. - -BSD September 25, 1999 BSD diff --git a/openssh/ssh_config.0 b/openssh/ssh_config.0 deleted file mode 100644 index c027d49..0000000 --- a/openssh/ssh_config.0 +++ /dev/null @@ -1,662 +0,0 @@ -SSH_CONFIG(5) BSD File Formats 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. GSSAPI configuration file ($HOME/.ssh/config.gssapi) - 4. Kerberos configuration file ($HOME/.ssh/config.krb) - 5. 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. - 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): - - 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 - arguments 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 - address 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 - exiting. 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 - unreachable, 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 - local 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 redi- - rected 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 ``yes''. Note that this option applies to proto- - col version 2 only. - - GSSAPIKeyExchange - Specifies whether key exchange based on GSSAPI may be used. When - using GSSAPI key exchange the server need not have a host key. - The default is ``yes''. Note that this option applies to proto- - col version 2 only. - - GSSAPIDelegateCredentials - Forward (delegate) credentials to the server. The default is - ``yes''. Note that this option applies to protocol version 2 - only. - - GSSAPITrustDns - Set to ``yes'' to indicate that the DNS is trusted to securely - canonicalize the name of the host being connected to. If ``no,'' - the hostname entered on the command line will be passed untouched - to the GSSAPI library. The default is ``yes''. This option only - applies to protocol version 2 connections using GSSAPI. - - 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 - only 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 - authentication. 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 - directive 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 - 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. - - 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 - order of preference. The MAC algorithm is used in protocol ver- - sion 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 - machine on each of the machines and the user will get many warn- - ings about changed host keys. However, this option disables host - authentication for localhost. The argument to this keyword must - be ``yes'' or ``no''. The default is to check the host key for - localhost. - - 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 - using 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 - default is 22. - - PreferredAuthentications - Specifies the order in which the client should try protocol 2 - authentication 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-keyex, - external-keyx, 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 - user). Setting the command to ``none'' disables this option - entirely. 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 - before the session key is renegotiated. The argument is the num- - ber 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 applies 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 - default 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 - being 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 - default, no device is specified and smartcard support is not - activated. - - 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 - option 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 automati- - cally 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 - server. 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 default 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 - authorized_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. - Because of the potential for abuse, this file must have strict - permissions: read/write for the user, and not accessible by oth- - ers. - - /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. - -BSD September 25, 1999 BSD diff --git a/openssh/sshd.0 b/openssh/sshd.0 deleted file mode 100644 index b6292c9..0000000 --- a/openssh/sshd.0 +++ /dev/null @@ -1,544 +0,0 @@ -SSHD(8) BSD 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 - options 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 - (default 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 - regenerated 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 - zero 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 - options, 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 - beginning, 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 - include RhostsRSAAuthentication, HostbasedAuthentication, and - using a from="pattern-list" option in a key file. Configuration - options 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 - option in sshd_config(5). Protocol 2 supports both RSA and DSA keys; - protocol 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 - secure 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: - options, keytype, base64-encoded key, comment. The options field is - optional; its presence is determined by whether the line starts with a - number or not (the options field never starts with a number). The bits, - exponent, modulus, and comment fields give the RSA key for protocol ver- - sion 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 - (because 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 cer- - tain public keys to perform just a specific operation. An exam- - ple 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 environ- - ment variable. Note that this option applies to shell, command - or subsystem 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 - optionally 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 - additional 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 - domains 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 - accepted (by that line) even if it matched another pattern on the line. - A hostname or address may optionally be enclosed within '[' and ']' - brackets 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 - appear 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 - enabled. 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 - allow 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 - defined 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 - allows 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 - described 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). - -BSD September 25, 1999 BSD diff --git a/openssh/sshd_config.0 b/openssh/sshd_config.0 deleted file mode 100644 index 72a4139..0000000 --- a/openssh/sshd_config.0 +++ /dev/null @@ -1,592 +0,0 @@ -SSHD_CONFIG(5) BSD File Formats 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 - security unless users are also denied shell access, as they can - always 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 - user 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 - USER@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 - authenticated, 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 - being 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 - 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. - - 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 - invoked 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 - remote 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 ``yes''. Note that this option applies to proto- - col version 2 only. - - GSSAPIKeyExchange - Specifies whether key exchange based on GSSAPI is allowed. GSSAPI - key exchange doesn't rely on ssh keys to verify host identity. - The default is ``yes''. Note that this option applies to proto- - col 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. - - GSSAPIStrictAcceptorCheck - Determines whether to be strict about the identity of the GSSAPI - acceptor a client authenticates against. If ``yes'' then the - client must authenticate against the host service on the current - hostname. If ``no'' then the client may authenticate against any - service key stored in the machine's default store. This facility - is provided to assist with operation on multi homed machines. - The default is ``yes''. Note that this option applies only to - protocol version 2 GSSAPI connections, and setting it to ``no'' - may only work with recent Kerberos GSSAPI libraries. - - GSIAllowLimitedProxy - Specifies whether to accept limited proxy credentials for authen- - tication. The default is ``no''. - - HostbasedAuthentication - Specifies whether rhosts or /etc/hosts.equiv authentication - together 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 - reverse 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 - default 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-sepa- - rated. 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, - until either another Match line or the end of the file. The - arguments 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 - expires 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 - increases linearly and all connection attempts are refused if the - number of unauthenticated connections reaches ``full'' (60). - - PasswordAuthentication - Specifies whether password authentication is allowed. The - default 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 - restrictions 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 - bypass access restrictions in some configurations using mecha- - nisms 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-sepa- - rated. The default is ``2,1''. Note that the order of the pro- - tocol list does not indicate preference, because the client - selects among multiple protocol versions offered by the server. - Specifying ``2,1'' is identical to ``1,2''. - - PubkeyAuthentication - Specifies whether public key authentication is allowed. The - default is ``yes''. Note that this option applies to protocol - version 2 only. - - RhostsRSAAuthentication - Specifies whether rhosts or /etc/hosts.equiv authentication - together with successful RSA host authentication is allowed. The - default is ``no''. This option applies to protocol version 1 - only. - - RSAAuthentication - Specifies whether pure RSA authentication is allowed. The - default is ``yes''. This option applies to protocol version 1 - only. - - 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 - applies 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 - default 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 - resources. - - 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 - enabled, 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 - addition to PAM account and session module processing for all - authentication 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 - unprivileged 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 - security risk of using X11 forwarding is that the client's X11 - display 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 protect clients that may expose themselves to - attack by unwittingly requesting X11 forwarding, which can war- - rant 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 - default 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 spec- - ify 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: - - 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. - -BSD September 25, 1999 BSD