| SSHD(8) OpenBSD System Manager's Manual SSHD(8) |
| |
| NAME |
| sshd - OpenSSH SSH daemon |
| |
| SYNOPSIS |
| sshd [-46DdeiqTt] [-b bits] [-C connection_spec] |
| [-c host_certificate_file] [-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(1) and rsh(1), and provide secure encrypted |
| communications 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, |
| command 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 |
| specified 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 1024). |
| |
| -C connection_spec |
| Specify the connection parameters to use for the -T extended test |
| mode. If provided, any Match directives in the configuration |
| file that would apply to the specified user, host, and address |
| will be set before the configuration is written to standard |
| output. The connection parameters are supplied as keyword=value |
| pairs. The keywords are ``user'', ``host'', and ``addr''. All |
| are required and may be supplied in any order, either with |
| multiple -C options or as a comma-separated list. |
| |
| -c host_certificate_file |
| Specifies a path to a certificate file to identify sshd during |
| key exchange. The certificate file must match a host key file |
| specified using the -h option or the HostKey configuration |
| directive. |
| |
| -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 standard |
| error, 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 config_file |
| Specifies the name of the configuration file. The default is |
| /etc/ssh/sshd_config. sshd refuses to start if there is no |
| configuration 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_dsa_key, /etc/ssh/ssh_host_ecdsa_key and |
| /etc/ssh/ssh_host_rsa_key for protocol 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 |
| motivation 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 |
| configuration 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 |
| specified 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 Extended test mode. Check the validity of the configuration |
| file, output the effective configuration to stdout and then exit. |
| Optionally, Match rules may be applied by specifying the |
| connection parameters using one or more -C options. |
| |
| -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 |
| overflow 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. The default is to |
| use protocol 2 only, though this can be changed via the Protocol option |
| in sshd_config(5). Protocol 2 supports DSA, ECDSA and RSA 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 |
| generates 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 encryption 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 |
| cryptographic message authentication code (hmac-md5, hmac-sha1, umac-64, |
| hmac-ripemd160, hmac-sha2-256 or hmac-sha2-512). |
| |
| Finally, the server and the client enter an authentication dialog. The |
| client tries to authenticate itself using host-based authentication, |
| public 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 |
| definition 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 most |
| Linuxes). 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 something 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 |
| connections, 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 |
| connections 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 |
| produce any output on stdout; stderr must be used instead. If X11 |
| forwarding 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 files containing public keys for public |
| key authentication; if none is specified, the default is |
| ~/.ssh/authorized_keys and ~/.ssh/authorized_keys2. 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 version 1; the comment field is not used |
| for anything (but may be convenient for the user to identify the key). |
| For protocol version 2 the keytype is ``ecdsa-sha2-nistp256'', |
| ``ecdsa-sha2-nistp384'', ``ecdsa-sha2-nistp521'', ``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 |
| kilobytes, 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, id_ecdsa.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 |
| specifications. No spaces are permitted, except within double quotes. |
| The following option specifications are supported (note that option |
| keywords are case-insensitive): |
| |
| cert-authority |
| Specifies that the listed key is a certification authority (CA) |
| that is trusted to validate signed certificates for user |
| authentication. |
| |
| Certificates may encode access restrictions similar to these key |
| options. If both certificate restrictions and key options are |
| present, the most restrictive union of the two is applied. |
| |
| 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 |
| channel is required, one must not request a pty or should specify |
| no-pty. A quote may be included in the command by quoting it |
| with a backslash. This option might be useful to restrict |
| certain public keys to perform just a specific operation. An |
| example might be a key that permits remote backups but nothing |
| else. Note that the client may specify TCP and/or X11 forwarding |
| unless they are explicitly prohibited. The command originally |
| supplied by the client is available in the SSH_ORIGINAL_COMMAND |
| environment variable. Note that this option applies to shell, |
| command or subsystem execution. Also note that this command may |
| be superseded by either a sshd_config(5) ForceCommand directive |
| or a command embedded in a certificate. |
| |
| 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, either |
| the canonical name of the remote host or its IP address must be |
| present in the comma-separated list of patterns. See PATTERNS in |
| ssh_config(5) for more information on patterns. |
| |
| In addition to the wildcard matching that may be applied to |
| hostnames or addresses, a from stanza may match IP addresses |
| using CIDR address/masklen notation. |
| |
| 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 permits 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). |
| |
| 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-user-rc |
| Disables execution of ~/.ssh/rc. |
| |
| 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 |
| connect to the specified host and port. IPv6 addresses can be |
| specified by enclosing the address in square brackets. 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. |
| |
| principals="principals" |
| On a cert-authority line, specifies allowed principals for |
| certificate authentication as a comma-separated list. At least |
| one name from the list must appear in the certificate's list of |
| principals for the certificate to be accepted. This option is |
| ignored for keys that are not marked as trusted certificate |
| signers using the cert-authority option. |
| |
| 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 |
| tunnel. |
| |
| 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 |
| automatically: 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: markers |
| (optional), hostnames, bits, exponent, modulus, comment. The fields are |
| separated by spaces. |
| |
| The marker is optional, but if it is present then it must be one of |
| ``@cert-authority'', to indicate that the line contains a certification |
| authority (CA) key, or ``@revoked'', to indicate that the key contained |
| on the line is revoked and must not ever be accepted. Only one marker |
| should be used on a key line. |
| |
| Hostnames is a comma-separated list of patterns (`*' and `?' act as |
| wildcards); 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 |
| indicate 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 |
| operators 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; either one that matches exactly or, if |
| the server has presented a certificate for authentication, the key of the |
| certification authority that signed the certificate. For a key to be |
| trusted as a certification authority, it must use the ``@cert-authority'' |
| marker described above. |
| |
| The known hosts file also provides a facility to mark keys as revoked, |
| for example when it is known that the associated private key has been |
| stolen. Revoked keys are specified by including the ``@revoked'' marker |
| at the beginning of the key line, and are never accepted for |
| authentication or as certification authorities, but instead will produce |
| a warning from ssh(1) when they are encountered. |
| |
| It is permissible (but not recommended) 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 conflicting 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, ssh-keyscan(1) or by taking |
| /etc/ssh/ssh_host_key.pub and adding the host names at the front. |
| ssh-keygen(1) also offers some basic automated editing for |
| ~/.ssh/known_hosts including removing hosts matching a host name and |
| converting all host names to their hashed representations. |
| |
| 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.....= |
| # A revoked key |
| @revoked * ssh-rsa AAAAB5W... |
| # A CA key, accepted for any host in *.mydomain.com or *.mydomain.org |
| @cert-authority *.mydomain.org,*.mydomain.com ssh-rsa AAAAB5W... |
| |
| 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 |
| partition, 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/ |
| This directory is the default location for all user-specific |
| configuration and authentication information. There is no |
| general requirement to keep the entire contents of this directory |
| secret, but the recommended permissions are read/write/execute |
| for the user, and not accessible by others. |
| |
| ~/.ssh/authorized_keys |
| Lists the public keys (DSA/ECDSA/RSA) 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''. |
| |
| ~/.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_host_key |
| /etc/ssh/ssh_host_dsa_key |
| /etc/ssh/ssh_host_ecdsa_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_ecdsa_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/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/sshd_config |
| Contains configuration data for sshd. The file format and |
| configuration 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- |
| readable. |
| |
| SEE ALSO |
| scp(1), sftp(1), ssh(1), ssh-add(1), ssh-agent(1), ssh-keygen(1), |
| ssh-keyscan(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 |
| created 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 |
| disabled (thus completely disabling rlogin and rsh into the machine). |
| |
| OpenBSD 5.0 August 2, 2011 OpenBSD 5.0 |
