1SSHD(8)                   BSD System Manager's Manual                  SSHD(8)
2

NAME

4     sshd — OpenSSH SSH daemon
5

SYNOPSIS

7     sshd [-46DdeiqTt] [-b bits] [-C connection_spec]
8          [-c host_certificate_file] [-f config_file] [-g login_grace_time]
9          [-h host_key_file] [-k key_gen_time] [-o option] [-p port] [-u len]
10

DESCRIPTION

12     sshd (OpenSSH Daemon) is the daemon program for ssh(1).  Together these
13     programs replace rlogin(1) and rsh(1), and provide secure encrypted com‐
14     munications between two untrusted hosts over an insecure network.
15
16     sshd listens for connections from clients.  It is normally started at
17     boot from /etc/rc.  It forks a new daemon for each incoming connection.
18     The forked daemons handle key exchange, encryption, authentication, com‐
19     mand execution, and data exchange.
20
21     sshd can be configured using command-line options or a configuration file
22     (by default sshd_config(5)); command-line options override values speci‐
23     fied in the configuration file.  sshd rereads its configuration file when
24     it receives a hangup signal, SIGHUP, by executing itself with the name
25     and options it was started with, e.g. /usr/sbin/sshd.
26
27     The options are as follows:
28
29     -4      Forces sshd to use IPv4 addresses only.
30
31     -6      Forces sshd to use IPv6 addresses only.
32
33     -b bits
34             Specifies the number of bits in the ephemeral protocol version 1
35             server key (default 1024).
36
37     -c host_certificate_file
38             Specifies a path to a certificate file to identify sshd during
39             key exchange.  The certificate file must match a host key file
40             specified using the --h option or the HostKey configuration
41             directive.
42
43     -C connection_spec
44             Specify the connection parameters to use for the -T extended test
45             mode.  If provided, any Match directives in the configuration
46             file that would apply to the specified user, host, and address
47             will be set before the configuration is written to standard out‐
48             put.  The connection parameters are supplied as keyword=value
49             pairs.  The keywords are “user”, “host”, “laddr”, “lport”, and
50             “addr”.  All are required and may be supplied in any order,
51             either with multiple -C options or as a comma-separated list.
52
53     -D      When this option is specified, sshd will not detach and does not
54             become a daemon.  This allows easy monitoring of sshd.
55
56     -d      Debug mode.  The server sends verbose debug output to the system
57             log, and does not put itself in the background.  The server also
58             will not fork and will only process one connection.  This option
59             is only intended for debugging for the server.  Multiple -d
60             options increase the debugging level.  Maximum is 3.
61
62     -e      When this option is specified, sshd will send the output to the
63             standard error instead of the system log.
64
65     -f config_file
66             Specifies the name of the configuration file.  The default is
67             /etc/ssh/sshd_config.  sshd refuses to start if there is no con‐
68             figuration file.
69
70     -g login_grace_time
71             Gives the grace time for clients to authenticate themselves
72             (default 120 seconds).  If the client fails to authenticate the
73             user within this many seconds, the server disconnects and exits.
74             A value of zero indicates no limit.
75
76     -h host_key_file
77             Specifies a file from which a host key is read.  This option must
78             be given if sshd is not run as root (as the normal host key files
79             are normally not readable by anyone but root).  The default is
80             /etc/ssh/ssh_host_key for protocol version 1, and
81             /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_ecdsa_key and
82             /etc/ssh/ssh_host_rsa_key for protocol version 2.  It is possible
83             to have multiple host key files for the different protocol ver‐
84             sions and host key algorithms.
85
86     -i      Specifies that sshd is being run from inetd(8).  sshd is normally
87             not run from inetd because it needs to generate the server key
88             before it can respond to the client, and this may take tens of
89             seconds.  Clients would have to wait too long if the key was
90             regenerated every time.  However, with small key sizes (e.g. 512)
91             using sshd from inetd may be feasible.
92
93     -k key_gen_time
94             Specifies how often the ephemeral protocol version 1 server key
95             is regenerated (default 3600 seconds, or one hour).  The motiva‐
96             tion for regenerating the key fairly often is that the key is not
97             stored anywhere, and after about an hour it becomes impossible to
98             recover the key for decrypting intercepted communications even if
99             the machine is cracked into or physically seized.  A value of
100             zero indicates that the key will never be regenerated.
101
102     -o option
103             Can be used to give options in the format used in the configura‐
104             tion file.  This is useful for specifying options for which there
105             is no separate command-line flag.  For full details of the
106             options, and their values, see sshd_config(5).
107
108     -p port
109             Specifies the port on which the server listens for connections
110             (default 22).  Multiple port options are permitted.  Ports speci‐
111             fied in the configuration file with the Port option are ignored
112             when a command-line port is specified.  Ports specified using the
113             ListenAddress option override command-line ports.
114
115     -q      Quiet mode.  Nothing is sent to the system log.  Normally the
116             beginning, authentication, and termination of each connection is
117             logged.
118
119     -T      Extended test mode.  Check the validity of the configuration
120             file, output the effective configuration to stdout and then exit.
121             Optionally, Match rules may be applied by specifying the connec‐
122             tion parameters using one or more -C options.
123
124     -t      Test mode.  Only check the validity of the configuration file and
125             sanity of the keys.  This is useful for updating sshd reliably as
126             configuration options may change.
127
128     -u len  This option is used to specify the size of the field in the utmp
129             structure that holds the remote host name.  If the resolved host
130             name is longer than len, the dotted decimal value will be used
131             instead.  This allows hosts with very long host names that over‐
132             flow this field to still be uniquely identified.  Specifying -u0
133             indicates that only dotted decimal addresses should be put into
134             the utmp file.  -u0 may also be used to prevent sshd from making
135             DNS requests unless the authentication mechanism or configuration
136             requires it.  Authentication mechanisms that may require DNS
137             include RhostsRSAAuthentication, HostbasedAuthentication, and
138             using a from="pattern-list" option in a key file.  Configuration
139             options that require DNS include using a USER@HOST pattern in
140             AllowUsers or DenyUsers.
141

AUTHENTICATION

143     The OpenSSH SSH daemon supports SSH protocols 1 and 2.  Both protocols
144     are supported by default, though this can be changed via the Protocol
145     option in sshd_config(5).  Protocol 2 supports DSA, ECDSA and RSA keys;
146     protocol 1 only supports RSA keys.  For both protocols, each host has a
147     host-specific key, normally 2048 bits, used to identify the host.
148
149     Forward security for protocol 1 is provided through an additional server
150     key, normally 768 bits, generated when the server starts.  This key is
151     normally regenerated every hour if it has been used, and is never stored
152     on disk.  Whenever a client connects, the daemon responds with its public
153     host and server keys.  The client compares the RSA host key against its
154     own database to verify that it has not changed.  The client then gener‐
155     ates a 256-bit random number.  It encrypts this random number using both
156     the host key and the server key, and sends the encrypted number to the
157     server.  Both sides then use this random number as a session key which is
158     used to encrypt all further communications in the session.  The rest of
159     the session is encrypted using a conventional cipher, currently Blowfish
160     or 3DES, with 3DES being used by default.  The client selects the encryp‐
161     tion algorithm to use from those offered by the server.
162
163     For protocol 2, forward security is provided through a Diffie-Hellman key
164     agreement.  This key agreement results in a shared session key.  The rest
165     of the session is encrypted using a symmetric cipher, currently 128-bit
166     AES, Blowfish, 3DES, CAST128, Arcfour, 192-bit AES, or 256-bit AES.  The
167     client selects the encryption algorithm to use from those offered by the
168     server.  Additionally, session integrity is provided through a crypto‐
169     graphic message authentication code (hmac-md5, hmac-sha1, umac-64, hmac-
170     ripemd160, hmac-sha2-256 or hmac-sha2-512).
171
172     Finally, the server and the client enter an authentication dialog.  The
173     client tries to authenticate itself using host-based authentication, pub‐
174     lic key authentication, challenge-response authentication, or password
175     authentication.
176
177     Regardless of the authentication type, the account is checked to ensure
178     that it is accessible.  An account is not accessible if it is locked,
179     listed in DenyUsers or its group is listed in DenyGroups .  The defini‐
180     tion of a locked account is system dependant. Some platforms have their
181     own account database (eg AIX) and some modify the passwd field ( ‘*LK*’
182     on Solaris and UnixWare, ‘*’ on HP-UX, containing ‘Nologin’ on Tru64, a
183     leading ‘*LOCKED*’ on FreeBSD and a leading ‘!’ on most Linuxes).  If
184     there is a requirement to disable password authentication for the account
185     while allowing still public-key, then the passwd field should be set to
186     something other than these values (eg ‘NP’ or ‘*NP*’ ).
187
188     If the client successfully authenticates itself, a dialog for preparing
189     the session is entered.  At this time the client may request things like
190     allocating a pseudo-tty, forwarding X11 connections, forwarding TCP con‐
191     nections, or forwarding the authentication agent connection over the
192     secure channel.
193
194     After this, the client either requests a shell or execution of a command.
195     The sides then enter session mode.  In this mode, either side may send
196     data at any time, and such data is forwarded to/from the shell or command
197     on the server side, and the user terminal in the client side.
198
199     When the user program terminates and all forwarded X11 and other connec‐
200     tions have been closed, the server sends command exit status to the
201     client, and both sides exit.
202

LOGIN PROCESS

204     When a user successfully logs in, sshd does the following:
205
206           1.   If the login is on a tty, and no command has been specified,
207                prints last login time and /etc/motd (unless prevented in the
208                configuration file or by ~/.hushlogin; see the FILES section).
209
210           2.   If the login is on a tty, records login time.
211
212           3.   Checks /etc/nologin; if it exists, prints contents and quits
213                (unless root).
214
215           4.   Changes to run with normal user privileges.
216
217           5.   Sets up basic environment.
218
219           6.   Reads the file ~/.ssh/environment, if it exists, and users are
220                allowed to change their environment.  See the
221                PermitUserEnvironment option in sshd_config(5).
222
223           7.   Changes to user's home directory.
224
225           8.   If ~/.ssh/rc exists, runs it; else if /etc/ssh/sshrc exists,
226                runs it; otherwise runs xauth.  The “rc” files are given the
227                X11 authentication protocol and cookie in standard input.  See
228                SSHRC, below.
229
230           9.   Runs user's shell or command.
231

SSHRC

233     If the file ~/.ssh/rc exists, sh(1) runs it after reading the environment
234     files but before starting the user's shell or command.  It must not pro‐
235     duce any output on stdout; stderr must be used instead.  If X11 forward‐
236     ing is in use, it will receive the "proto cookie" pair in its standard
237     input (and DISPLAY in its environment).  The script must call xauth(1)
238     because sshd will not run xauth automatically to add X11 cookies.
239
240     The primary purpose of this file is to run any initialization routines
241     which may be needed before the user's home directory becomes accessible;
242     AFS is a particular example of such an environment.
243
244     This file will probably contain some initialization code followed by
245     something similar to:
246
247        if read proto cookie && [ -n "$DISPLAY" ]; then
248                if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
249                        # X11UseLocalhost=yes
250                        echo add unix:`echo $DISPLAY |
251                            cut -c11-` $proto $cookie
252                else
253                        # X11UseLocalhost=no
254                        echo add $DISPLAY $proto $cookie
255                fi | xauth -q -
256        fi
257
258     If this file does not exist, /etc/ssh/sshrc is run, and if that does not
259     exist either, xauth is used to add the cookie.
260

AUTHORIZED_KEYS FILE FORMAT

262     AuthorizedKeysFile specifies the file containing public keys for public
263     key authentication; if none is specified, the default is
264     ~/.ssh/authorized_keys.  Each line of the file contains one key (empty
265     lines and lines starting with a ‘#’ are ignored as comments).  Protocol 1
266     public keys consist of the following space-separated fields: options,
267     bits, exponent, modulus, comment.  Protocol 2 public key consist of:
268     options, keytype, base64-encoded key, comment.  The options field is
269     optional; its presence is determined by whether the line starts with a
270     number or not (the options field never starts with a number).  The bits,
271     exponent, modulus, and comment fields give the RSA key for protocol ver‐
272     sion 1; the comment field is not used for anything (but may be convenient
273     for the user to identify the key).  For protocol version 2 the keytype is
274     “ecdsa-sha2-nistp256”, “ecdsa-sha2-nistp384”, “ecdsa-sha2-nistp521”,
275     “ssh-dss” or “ssh-rsa”.
276
277     Note that lines in this file are usually several hundred bytes long
278     (because of the size of the public key encoding) up to a limit of 8 kilo‐
279     bytes, which permits DSA keys up to 8 kilobits and RSA keys up to 16
280     kilobits.  You don't want to type them in; instead, copy the
281     identity.pub, id_dsa.pub, id_ecdsa.pub, or the id_rsa.pub file and edit
282     it.
283
284     sshd enforces a minimum RSA key modulus size for protocol 1 and protocol
285     2 keys of 768 bits.
286
287     The options (if present) consist of comma-separated option specifica‐
288     tions.  No spaces are permitted, except within double quotes.  The fol‐
289     lowing option specifications are supported (note that option keywords are
290     case-insensitive):
291
292     cert-authority
293             Specifies that the listed key is a certification authority (CA)
294             that is trusted to validate signed certificates for user authen‐
295             tication.
296
297             Certificates may encode access restrictions similar to these key
298             options.  If both certificate restrictions and key options are
299             present, the most restrictive union of the two is applied.
300
301     command="command"
302             Specifies that the command is executed whenever this key is used
303             for authentication.  The command supplied by the user (if any) is
304             ignored.  The command is run on a pty if the client requests a
305             pty; otherwise it is run without a tty.  If an 8-bit clean chan‐
306             nel is required, one must not request a pty or should specify
307             no-pty.  A quote may be included in the command by quoting it
308             with a backslash.  This option might be useful to restrict cer‐
309             tain public keys to perform just a specific operation.  An exam‐
310             ple might be a key that permits remote backups but nothing else.
311             Note that the client may specify TCP and/or X11 forwarding unless
312             they are explicitly prohibited.  The command originally supplied
313             by the client is available in the SSH_ORIGINAL_COMMAND environ‐
314             ment variable.  Note that this option applies to shell, command
315             or subsystem execution.  Also note that this command may be
316             superseded by either a sshd_config(5) ForceCommand directive or a
317             command embedded in a certificate.
318
319     environment="NAME=value"
320             Specifies that the string is to be added to the environment when
321             logging in using this key.  Environment variables set this way
322             override other default environment values.  Multiple options of
323             this type are permitted.  Environment processing is disabled by
324             default and is controlled via the PermitUserEnvironment option.
325             This option is automatically disabled if UseLogin is enabled.
326
327     from="pattern-list"
328             Specifies that in addition to public key authentication, either
329             the canonical name of the remote host or its IP address must be
330             present in the comma-separated list of patterns.  See PATTERNS in
331             ssh_config(5) for more information on patterns.
332
333             In addition to the wildcard matching that may be applied to host‐
334             names or addresses, a from stanza may match IP addresses using
335             CIDR address/masklen notation.
336
337             The purpose of this option is to optionally increase security:
338             public key authentication by itself does not trust the network or
339             name servers or anything (but the key); however, if somebody
340             somehow steals the key, the key permits an intruder to log in
341             from anywhere in the world.  This additional option makes using a
342             stolen key more difficult (name servers and/or routers would have
343             to be compromised in addition to just the key).
344
345     no-agent-forwarding
346             Forbids authentication agent forwarding when this key is used for
347             authentication.
348
349     no-port-forwarding
350             Forbids TCP forwarding when this key is used for authentication.
351             Any port forward requests by the client will return an error.
352             This might be used, e.g. in connection with the command option.
353
354     no-pty  Prevents tty allocation (a request to allocate a pty will fail).
355
356     no-user-rc
357             Disables execution of ~/.ssh/rc.
358
359     no-X11-forwarding
360             Forbids X11 forwarding when this key is used for authentication.
361             Any X11 forward requests by the client will return an error.
362
363     permitopen="host:port"
364             Limit local ``ssh -L'' port forwarding such that it may only con‐
365             nect to the specified host and port.  IPv6 addresses can be spec‐
366             ified with an alternative syntax: host/port.  Multiple permitopen
367             options may be applied separated by commas.  No pattern matching
368             is performed on the specified hostnames, they must be literal
369             domains or addresses.  A port specification of * matches any
370             port.
371
372     principals="principals"
373             On a cert-authority line, specifies allowed principals for cer‐
374             tificate authentication as a comma-separated list.  At least one
375             name from the list must appear in the certificate's list of prin‐
376             cipals for the certificate to be accepted.  This option is
377             ignored for keys that are not marked as trusted certificate sign‐
378             ers using the cert-authority option.
379
380     tunnel="n"
381             Force a tun(4) device on the server.  Without this option, the
382             next available device will be used if the client requests a tun‐
383             nel.
384
385     An example authorized_keys file:
386
387        # Comments allowed at start of line
388        ssh-rsa AAAAB3Nza...LiPk== user@example.net
389        from="*.sales.example.net,!pc.sales.example.net" ssh-rsa
390        AAAAB2...19Q== john@example.net
391        command="dump /home",no-pty,no-port-forwarding ssh-dss
392        AAAAC3...51R== example.net
393        permitopen="192.0.2.1:80",permitopen="192.0.2.2:25" ssh-dss
394        AAAAB5...21S==
395        tunnel="0",command="sh /etc/netstart tun0" ssh-rsa AAAA...==
396        jane@example.net
397

SSH_KNOWN_HOSTS FILE FORMAT

399     The /etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts files contain host
400     public keys for all known hosts.  The global file should be prepared by
401     the administrator (optional), and the per-user file is maintained auto‐
402     matically: whenever the user connects from an unknown host, its key is
403     added to the per-user file.
404
405     Each line in these files contains the following fields: markers
406     (optional), hostnames, bits, exponent, modulus, comment.  The fields are
407     separated by spaces.
408
409     The marker is optional, but if it is present then it must be one of
410     “@cert-authority”, to indicate that the line contains a certification
411     authority (CA) key, or “@revoked”, to indicate that the key contained on
412     the line is revoked and must not ever be accepted.  Only one marker
413     should be used on a key line.
414
415     Hostnames is a comma-separated list of patterns (‘*’ and ‘?’ act as wild‐
416     cards); each pattern in turn is matched against the canonical host name
417     (when authenticating a client) or against the user-supplied name (when
418     authenticating a server).  A pattern may also be preceded by ‘!’ to indi‐
419     cate negation: if the host name matches a negated pattern, it is not
420     accepted (by that line) even if it matched another pattern on the line.
421     A hostname or address may optionally be enclosed within ‘[’ and ‘]’
422     brackets then followed by ‘:’ and a non-standard port number.
423
424     Alternately, hostnames may be stored in a hashed form which hides host
425     names and addresses should the file's contents be disclosed.  Hashed
426     hostnames start with a ‘|’ character.  Only one hashed hostname may
427     appear on a single line and none of the above negation or wildcard opera‐
428     tors may be applied.
429
430     Bits, exponent, and modulus are taken directly from the RSA host key;
431     they can be obtained, for example, from /etc/ssh/ssh_host_key.pub.  The
432     optional comment field continues to the end of the line, and is not used.
433
434     Lines starting with ‘#’ and empty lines are ignored as comments.
435
436     When performing host authentication, authentication is accepted if any
437     matching line has the proper key; either one that matches exactly or, if
438     the server has presented a certificate for authentication, the key of the
439     certification authority that signed the certificate.  For a key to be
440     trusted as a certification authority, it must use the “@cert-authority”
441     marker described above.
442
443     The known hosts file also provides a facility to mark keys as revoked,
444     for example when it is known that the associated private key has been
445     stolen.  Revoked keys are specified by including the “@revoked” marker at
446     the beginning of the key line, and are never accepted for authentication
447     or as certification authorities, but instead will produce a warning from
448     ssh(1) when they are encountered.
449
450     It is permissible (but not recommended) to have several lines or differ‐
451     ent host keys for the same names.  This will inevitably happen when short
452     forms of host names from different domains are put in the file.  It is
453     possible that the files contain conflicting information; authentication
454     is accepted if valid information can be found from either file.
455
456     Note that the lines in these files are typically hundreds of characters
457     long, and you definitely don't want to type in the host keys by hand.
458     Rather, generate them by a script, ssh-keyscan(1) or by taking
459     /etc/ssh/ssh_host_key.pub and adding the host names at the front.
460     ssh-keygen(1) also offers some basic automated editing for
461     ~/.ssh/known_hosts including removing hosts matching a host name and con‐
462     verting all host names to their hashed representations.
463
464     An example ssh_known_hosts file:
465
466        # Comments allowed at start of line
467        closenet,...,192.0.2.53 1024 37 159...93 closenet.example.net
468        cvs.example.net,192.0.2.10 ssh-rsa AAAA1234.....=
469        # A hashed hostname
470        |1|JfKTdBh7rNbXkVAQCRp4OQoPfmI=|USECr3SWf1JUPsms5AqfD5QfxkM= ssh-rsa
471        AAAA1234.....=
472        # A revoked key
473        @revoked * ssh-rsa AAAAB5W...
474        # A CA key, accepted for any host in *.mydomain.com or *.mydomain.org
475        @cert-authority *.mydomain.org,*.mydomain.com ssh-rsa AAAAB5W...
476

FILES

478     ~/.hushlogin
479             This file is used to suppress printing the last login time and
480             /etc/motd, if PrintLastLog and PrintMotd, respectively, are
481             enabled.  It does not suppress printing of the banner specified
482             by Banner.
483
484     ~/.rhosts
485             This file is used for host-based authentication (see ssh(1) for
486             more information).  On some machines this file may need to be
487             world-readable if the user's home directory is on an NFS parti‐
488             tion, because sshd reads it as root.  Additionally, this file
489             must be owned by the user, and must not have write permissions
490             for anyone else.  The recommended permission for most machines is
491             read/write for the user, and not accessible by others.
492
493     ~/.shosts
494             This file is used in exactly the same way as .rhosts, but allows
495             host-based authentication without permitting login with
496             rlogin/rsh.
497
498     ~/.ssh/
499             This directory is the default location for all user-specific con‐
500             figuration and authentication information.  There is no general
501             requirement to keep the entire contents of this directory secret,
502             but the recommended permissions are read/write/execute for the
503             user, and not accessible by others.
504
505     ~/.ssh/authorized_keys
506             Lists the public keys (RSA/ECDSA/DSA) that can be used for log‐
507             ging in as this user.  The format of this file is described
508             above.  The content of the file is not highly sensitive, but the
509             recommended permissions are read/write for the user, and not
510             accessible by others.
511
512             If this file, the ~/.ssh directory, or the user's home directory
513             are writable by other users, then the file could be modified or
514             replaced by unauthorized users.  In this case, sshd will not
515             allow it to be used unless the StrictModes option has been set to
516             “no”.
517
518     ~/.ssh/environment
519             This file is read into the environment at login (if it exists).
520             It can only contain empty lines, comment lines (that start with
521             ‘#’), and assignment lines of the form name=value.  The file
522             should be writable only by the user; it need not be readable by
523             anyone else.  Environment processing is disabled by default and
524             is controlled via the PermitUserEnvironment option.
525
526     ~/.ssh/known_hosts
527             Contains a list of host keys for all hosts the user has logged
528             into that are not already in the systemwide list of known host
529             keys.  The format of this file is described above.  This file
530             should be writable only by root/the owner and can, but need not
531             be, world-readable.
532
533     ~/.ssh/rc
534             Contains initialization routines to be run before the user's home
535             directory becomes accessible.  This file should be writable only
536             by the user, and need not be readable by anyone else.
537
538     /etc/hosts.allow
539     /etc/hosts.deny
540             Access controls that should be enforced by tcp-wrappers are
541             defined here.  Further details are described in hosts_access(5).
542
543     /etc/hosts.equiv
544             This file is for host-based authentication (see ssh(1)).  It
545             should only be writable by root.
546
547     /etc/ssh/moduli
548             Contains Diffie-Hellman groups used for the "Diffie-Hellman Group
549             Exchange".  The file format is described in moduli(5).
550
551     /etc/motd
552             See motd(5).
553
554     /etc/nologin
555             If this file exists, sshd refuses to let anyone except root log
556             in.  The contents of the file are displayed to anyone trying to
557             log in, and non-root connections are refused.  The file should be
558             world-readable.
559
560     /etc/ssh/shosts.equiv
561             This file is used in exactly the same way as hosts.equiv, but
562             allows host-based authentication without permitting login with
563             rlogin/rsh.
564
565     /etc/ssh/ssh_host_key
566     /etc/ssh/ssh_host_dsa_key
567     /etc/ssh/ssh_host_ecdsa_key
568     /etc/ssh/ssh_host_rsa_key
569             These three files contain the private parts of the host keys.
570             These files should only be owned by root, readable only by root,
571             and not accessible to others.  Note that sshd does not start if
572             these files are group/world-accessible.
573
574     /etc/ssh/ssh_host_key.pub
575     /etc/ssh/ssh_host_dsa_key.pub
576     /etc/ssh/ssh_host_ecdsa_key.pub
577     /etc/ssh/ssh_host_rsa_key.pub
578             These three files contain the public parts of the host keys.
579             These files should be world-readable but writable only by root.
580             Their contents should match the respective private parts.  These
581             files are not really used for anything; they are provided for the
582             convenience of the user so their contents can be copied to known
583             hosts files.  These files are created using ssh-keygen(1).
584
585     /etc/ssh/ssh_known_hosts
586             Systemwide list of known host keys.  This file should be prepared
587             by the system administrator to contain the public host keys of
588             all machines in the organization.  The format of this file is
589             described above.  This file should be writable only by root/the
590             owner and should be world-readable.
591
592     /etc/ssh/sshd_config
593             Contains configuration data for sshd.  The file format and con‐
594             figuration options are described in sshd_config(5).
595
596     /etc/ssh/sshrc
597             Similar to ~/.ssh/rc, it can be used to specify machine-specific
598             login-time initializations globally.  This file should be
599             writable only by root, and should be world-readable.
600
601     /var/empty/sshd
602             chroot(2) directory used by sshd during privilege separation in
603             the pre-authentication phase.  The directory should not contain
604             any files and must be owned by root and not group or world-
605             writable.
606
607     /var/run/sshd.pid
608             Contains the process ID of the sshd listening for connections (if
609             there are several daemons running concurrently for different
610             ports, this contains the process ID of the one started last).
611             The content of this file is not sensitive; it can be world-read‐
612             able.
613

ENVIRONMENT

615     SSH_USE_STRONG_RNG
616             The reseeding of the OpenSSL random generator is usually done
617             from /dev/urandom.  If the SSH_USE_STRONG_RNG environment vari‐
618             able is set to value other than 0 the OpenSSL random generator is
619             reseeded from /dev/random.  The number of bytes read is defined
620             by the SSH_USE_STRONG_RNG value.  Minimum is 14 bytes.  This set‐
621             ting is not recommended on the computers without the hardware
622             random generator because insufficient entropy causes the connec‐
623             tion to be blocked until enough entropy is available.
624

IPV6

626     IPv6 address can be used everywhere where IPv4 address. In all entries
627     must be the IPv6 address enclosed in square brackets. Note: The square
628     brackets are metacharacters for the shell and must be escaped in shell.
629

SEE ALSO

631     scp(1), sftp(1), ssh(1), ssh-add(1), ssh-agent(1), ssh-keygen(1),
632     ssh-keyscan(1), chroot(2), hosts_access(5), login.conf(5), moduli(5),
633     sshd_config(5), inetd(8), sftp-server(8)
634

AUTHORS

636     OpenSSH is a derivative of the original and free ssh 1.2.12 release by
637     Tatu Ylonen.  Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo
638     de Raadt and Dug Song removed many bugs, re-added newer features and cre‐
639     ated OpenSSH.  Markus Friedl contributed the support for SSH protocol
640     versions 1.5 and 2.0.  Niels Provos and Markus Friedl contributed support
641     for privilege separation.
642

CAVEATS

644     System security is not improved unless rshd, rlogind, and rexecd are dis‐
645     abled (thus completely disabling rlogin and rsh into the machine).
646
647BSD                              June 21, 2019                             BSD
Impressum