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

NAME

4     sshd — OpenSSH daemon
5

SYNOPSIS

7     sshd [-46DdeGiqTtV] [-C connection_spec] [-c host_certificate_file]
8          [-E log_file] [-f config_file] [-g login_grace_time]
9          [-h host_key_file] [-o option] [-p port] [-u len]
10

DESCRIPTION

12     sshd (OpenSSH Daemon) is the daemon program for ssh(1).  It provides se‐
13     cure encrypted communications between two untrusted hosts over an inse‐
14     cure 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     -C connection_spec
34             Specify the connection parameters to use for the -T extended test
35             mode.  If provided, any Match directives in the configuration
36             file that would apply are applied before the configuration is
37             written to standard output.  The connection parameters are sup‐
38             plied as keyword=value pairs and may be supplied in any order,
39             either with multiple -C options or as a comma-separated list.
40             The keywords are “addr”, “user”, “host”, “laddr”, “lport”, and
41             “rdomain” and correspond to source address, user, resolved source
42             host name, local address, local port number and routing domain
43             respectively.
44
45     -c host_certificate_file
46             Specifies a path to a certificate file to identify sshd during
47             key exchange.  The certificate file must match a host key file
48             specified using the -h option or the HostKey configuration direc‐
49             tive.
50
51     -D      When this option is specified, sshd will not detach and does not
52             become a daemon.  This allows easy monitoring of sshd.
53
54     -d      Debug mode.  The server sends verbose debug output to standard
55             error, and does not put itself in the background.  The server
56             also will not fork(2) and will only process one connection.  This
57             option is only intended for debugging for the server.  Multiple
58             -d options increase the debugging level.  Maximum is 3.
59
60     -E log_file
61             Append debug logs to log_file instead of the system log.
62
63     -e      Write debug logs to 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      Parse and print configuration file.  Check the validity of the
71             configuration file, output the effective configuration to stdout
72             and then exit.  Optionally, Match rules may be applied by speci‐
73             fying the connection parameters using one or more -C options.
74
75     -g login_grace_time
76             Gives the grace time for clients to authenticate themselves (de‐
77             fault 120 seconds).  If the client fails to authenticate the user
78             within this many seconds, the server disconnects and exits.  A
79             value of zero indicates no limit.
80
81     -h host_key_file
82             Specifies a file from which a host key is read.  This option must
83             be given if sshd is not run as root (as the normal host key files
84             are normally not readable by anyone but root).  The default is
85             /etc/ssh/ssh_host_ecdsa_key, /etc/ssh/ssh_host_ed25519_key and
86             /etc/ssh/ssh_host_rsa_key.  It is possible to have multiple host
87             key files for the different host key algorithms.
88
89     -i      Specifies that sshd is being run from inetd(8).
90
91     -o option
92             Can be used to give options in the format used in the configura‐
93             tion file.  This is useful for specifying options for which there
94             is no separate command-line flag.  For full details of the op‐
95             tions, and their values, see sshd_config(5).
96
97     -p port
98             Specifies the port on which the server listens for connections
99             (default 22).  Multiple port options are permitted.  Ports speci‐
100             fied in the configuration file with the Port option are ignored
101             when a command-line port is specified.  Ports specified using the
102             ListenAddress option override command-line ports.
103
104     -q      Quiet mode.  Nothing is sent to the system log.  Normally the be‐
105             ginning, authentication, and termination of each connection is
106             logged.
107
108     -T      Extended test mode.  Check the validity of the configuration
109             file, output the effective configuration to stdout and then exit.
110             Optionally, Match rules may be applied by specifying the connec‐
111             tion parameters using one or more -C options.  This is similar to
112             the -G flag, but it includes the additional testing performed by
113             the -t flag.
114
115     -t      Test mode.  Only check the validity of the configuration file and
116             sanity of the keys.  This is useful for updating sshd reliably as
117             configuration options may change.
118
119     -u len  This option is used to specify the size of the field in the utmp
120             structure that holds the remote host name.  If the resolved host
121             name is longer than len, the dotted decimal value will be used
122             instead.  This allows hosts with very long host names that over‐
123             flow this field to still be uniquely identified.  Specifying -u0
124             indicates that only dotted decimal addresses should be put into
125             the utmp file.  -u0 may also be used to prevent sshd from making
126             DNS requests unless the authentication mechanism or configuration
127             requires it.  Authentication mechanisms that may require DNS in‐
128             clude HostbasedAuthentication and using a from="pattern-list" op‐
129             tion in a key file.  Configuration options that require DNS in‐
130             clude using a USER@HOST pattern in AllowUsers or DenyUsers.
131
132     -V      Display the version number and exit.
133

AUTHENTICATION

135     The OpenSSH SSH daemon supports SSH protocol 2 only.  Each host has a
136     host-specific key, used to identify the host.  Whenever a client con‐
137     nects, the daemon responds with its public host key.  The client compares
138     the host key against its own database to verify that it has not changed.
139     Forward secrecy is provided through a Diffie-Hellman key agreement.  This
140     key agreement results in a shared session key.  The rest of the session
141     is encrypted using a symmetric cipher.  The client selects the encryption
142     algorithm to use from those offered by the server.  Additionally, session
143     integrity is provided through a cryptographic message authentication code
144     (MAC).
145
146     Finally, the server and the client enter an authentication dialog.  The
147     client tries to authenticate itself using host-based authentication, pub‐
148     lic key authentication, GSSAPI authentication, challenge-response authen‐
149     tication, or password authentication.
150
151     Regardless of the authentication type, the account is checked to ensure
152     that it is accessible.  An account is not accessible if it is locked,
153     listed in DenyUsers or its group is listed in DenyGroups .  The defini‐
154     tion of a locked account is system dependent. Some platforms have their
155     own account database (eg AIX) and some modify the passwd field ( ‘*LK*’
156     on Solaris and UnixWare, ‘*’ on HP-UX, containing ‘Nologin’ on Tru64, a
157     leading ‘*LOCKED*’ on FreeBSD and a leading ‘!’ on most Linuxes).  If
158     there is a requirement to disable password authentication for the account
159     while allowing still public-key, then the passwd field should be set to
160     something other than these values (eg ‘NP’ or ‘*NP*’ ).
161
162     If the client successfully authenticates itself, a dialog for preparing
163     the session is entered.  At this time the client may request things like
164     allocating a pseudo-tty, forwarding X11 connections, forwarding TCP con‐
165     nections, or forwarding the authentication agent connection over the se‐
166     cure channel.
167
168     After this, the client either requests an interactive shell or execution
169     or a non-interactive command, which sshd will execute via the user's
170     shell using its -c option.  The sides then enter session mode.  In this
171     mode, either side may send data at any time, and such data is forwarded
172     to/from the shell or command on the server side, and the user terminal in
173     the client side.
174
175     When the user program terminates and all forwarded X11 and other connec‐
176     tions have been closed, the server sends command exit status to the
177     client, and both sides exit.
178

LOGIN PROCESS

180     When a user successfully logs in, sshd does the following:
181
182           1.   If the login is on a tty, and no command has been specified,
183                prints last login time and /etc/motd (unless prevented in the
184                configuration file or by ~/.hushlogin; see the FILES section).
185
186           2.   If the login is on a tty, records login time.
187
188           3.   Checks /etc/nologin; if it exists, prints contents and quits
189                (unless root).
190
191           4.   Changes to run with normal user privileges.
192
193           5.   Sets up basic environment.
194
195           6.   Reads the file ~/.ssh/environment, if it exists, and users are
196                allowed to change their environment.  See the
197                PermitUserEnvironment option in sshd_config(5).
198
199           7.   Changes to user's home directory.
200
201           8.   If ~/.ssh/rc exists and the sshd_config(5) PermitUserRC option
202                is set, runs it; else if /etc/ssh/sshrc exists, runs it; oth‐
203                erwise runs xauth(1).  The “rc” files are given the X11 au‐
204                thentication protocol and cookie in standard input.  See
205                SSHRC, below.
206
207           9.   Runs user's shell or command.  All commands are run under the
208                user's login shell as specified in the system password data‐
209                base.
210

SSHRC

212     If the file ~/.ssh/rc exists, sh(1) runs it after reading the environment
213     files but before starting the user's shell or command.  It must not pro‐
214     duce any output on stdout; stderr must be used instead.  If X11 forward‐
215     ing is in use, it will receive the "proto cookie" pair in its standard
216     input (and DISPLAY in its environment).  The script must call xauth(1)
217     because sshd will not run xauth automatically to add X11 cookies.
218
219     The primary purpose of this file is to run any initialization routines
220     which may be needed before the user's home directory becomes accessible;
221     AFS is a particular example of such an environment.
222
223     This file will probably contain some initialization code followed by
224     something similar to:
225
226        if read proto cookie && [ -n "$DISPLAY" ]; then
227                if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
228                        # X11UseLocalhost=yes
229                        echo add unix:`echo $DISPLAY |
230                            cut -c11-` $proto $cookie
231                else
232                        # X11UseLocalhost=no
233                        echo add $DISPLAY $proto $cookie
234                fi | xauth -q -
235        fi
236
237     If this file does not exist, /etc/ssh/sshrc is run, and if that does not
238     exist either, xauth is used to add the cookie.
239

AUTHORIZED_KEYS FILE FORMAT

241     AuthorizedKeysFile specifies the files containing public keys for public
242     key authentication; if this option is not specified, the default is
243     ~/.ssh/authorized_keys and ~/.ssh/authorized_keys2.  Each line of the
244     file contains one key (empty lines and lines starting with a ‘#’ are ig‐
245     nored as comments).  Public keys consist of the following space-separated
246     fields: options, keytype, base64-encoded key, comment.  The options field
247     is optional.  The supported key types are:
248
249           sk-ecdsa-sha2-nistp256@openssh.com
250           ecdsa-sha2-nistp256
251           ecdsa-sha2-nistp384
252           ecdsa-sha2-nistp521
253           sk-ssh-ed25519@openssh.com
254           ssh-ed25519
255           ssh-dss
256           ssh-rsa
257
258     The comment field is not used for anything (but may be convenient for the
259     user to identify the key).
260
261     Note that lines in this file can be several hundred bytes long (because
262     of the size of the public key encoding) up to a limit of 8 kilobytes,
263     which permits RSA keys up to 16 kilobits.  You don't want to type them
264     in; instead, copy the id_dsa.pub, id_ecdsa.pub, id_ecdsa_sk.pub,
265     id_ed25519.pub, id_ed25519_sk.pub, or the id_rsa.pub file and edit it.
266
267     sshd enforces a minimum RSA key modulus size of 1024 bits.
268
269     The options (if present) consist of comma-separated option specifica‐
270     tions.  No spaces are permitted, except within double quotes.  The fol‐
271     lowing option specifications are supported (note that option keywords are
272     case-insensitive):
273
274     agent-forwarding
275             Enable authentication agent forwarding previously disabled by the
276             restrict option.
277
278     cert-authority
279             Specifies that the listed key is a certification authority (CA)
280             that is trusted to validate signed certificates for user authen‐
281             tication.
282
283             Certificates may encode access restrictions similar to these key
284             options.  If both certificate restrictions and key options are
285             present, the most restrictive union of the two is applied.
286
287     command="command"
288             Specifies that the command is executed whenever this key is used
289             for authentication.  The command supplied by the user (if any) is
290             ignored.  The command is run on a pty if the client requests a
291             pty; otherwise it is run without a tty.  If an 8-bit clean chan‐
292             nel is required, one must not request a pty or should specify
293             no-pty.  A quote may be included in the command by quoting it
294             with a backslash.
295
296             This option might be useful to restrict certain public keys to
297             perform just a specific operation.  An example might be a key
298             that permits remote backups but nothing else.  Note that the
299             client may specify TCP and/or X11 forwarding unless they are ex‐
300             plicitly prohibited, e.g. using the restrict key option.
301
302             The command originally supplied by the client is available in the
303             SSH_ORIGINAL_COMMAND environment variable.  Note that this option
304             applies to shell, command or subsystem execution.  Also note that
305             this command may be superseded by a sshd_config(5) ForceCommand
306             directive.
307
308             If a command is specified and a forced-command is embedded in a
309             certificate used for authentication, then the certificate will be
310             accepted only if the two commands are identical.
311
312     environment="NAME=value"
313             Specifies that the string is to be added to the environment when
314             logging in using this key.  Environment variables set this way
315             override other default environment values.  Multiple options of
316             this type are permitted.  Environment processing is disabled by
317             default and is controlled via the PermitUserEnvironment option.
318
319     expiry-time="timespec"
320             Specifies a time after which the key will not be accepted.  The
321             time may be specified as a YYYYMMDD[Z] date or a YYYYMMD‐
322             DHHMM[SS][Z] time.  Dates and times will be interpreted in the
323             system time zone unless suffixed by a Z character, in which case
324             they will be interpreted in the UTC time zone.
325
326     from="pattern-list"
327             Specifies that in addition to public key authentication, either
328             the canonical name of the remote host or its IP address must be
329             present in the comma-separated list of patterns.  See PATTERNS in
330             ssh_config(5) for more information on patterns.
331
332             In addition to the wildcard matching that may be applied to host‐
333             names or addresses, a from stanza may match IP addresses using
334             CIDR address/masklen notation.
335
336             The purpose of this option is to optionally increase security:
337             public key authentication by itself does not trust the network or
338             name servers or anything (but the key); however, if somebody
339             somehow steals the key, the key permits an intruder to log in
340             from anywhere in the world.  This additional option makes using a
341             stolen key more difficult (name servers and/or routers would have
342             to be compromised in addition to just the key).
343
344     no-agent-forwarding
345             Forbids authentication agent forwarding when this key is used for
346             authentication.
347
348     no-port-forwarding
349             Forbids TCP forwarding when this key is used for authentication.
350             Any port forward requests by the client will return an error.
351             This might be used, e.g. in connection with the command option.
352
353     no-pty  Prevents tty allocation (a request to allocate a pty will fail).
354
355     no-user-rc
356             Disables execution of ~/.ssh/rc.
357
358     no-X11-forwarding
359             Forbids X11 forwarding when this key is used for authentication.
360             Any X11 forward requests by the client will return an error.
361
362     permitlisten="[host:]port"
363             Limit remote port forwarding with the ssh(1) -R option such that
364             it may only listen on the specified host (optional) and port.
365             IPv6 addresses can be specified by enclosing the address in
366             square brackets.  Multiple permitlisten options may be applied
367             separated by commas.  Hostnames may include wildcards as de‐
368             scribed in the PATTERNS section in ssh_config(5).  A port speci‐
369             fication of * matches any port.  Note that the setting of
370             GatewayPorts may further restrict listen addresses.  Note that
371             ssh(1) will send a hostname of “localhost” if a listen host was
372             not specified when the forwarding was requested, and that this
373             name is treated differently to the explicit localhost addresses
374             “127.0.0.1” and “::1”.
375
376     permitopen="host:port"
377             Limit local port forwarding with the ssh(1) -L option such that
378             it may only connect to the specified host and port.  IPv6 ad‐
379             dresses can be specified by enclosing the address in square
380             brackets.  Multiple permitopen options may be applied separated
381             by commas.  No pattern matching or name lookup is performed on
382             the specified hostnames, they must be literal host names and/or
383             addresses.  A port specification of * matches any port.
384
385     port-forwarding
386             Enable port forwarding previously disabled by the restrict op‐
387             tion.
388
389     principals="principals"
390             On a cert-authority line, specifies allowed principals for cer‐
391             tificate authentication as a comma-separated list.  At least one
392             name from the list must appear in the certificate's list of prin‐
393             cipals for the certificate to be accepted.  This option is ig‐
394             nored for keys that are not marked as trusted certificate signers
395             using the cert-authority option.
396
397     pty     Permits tty allocation previously disabled by the restrict op‐
398             tion.
399
400     no-touch-required
401             Do not require demonstration of user presence for signatures made
402             using this key.  This option only makes sense for the FIDO au‐
403             thenticator algorithms ecdsa-sk and ed25519-sk.
404
405     verify-required
406             Require that signatures made using this key attest that they ver‐
407             ified the user, e.g. via a PIN.  This option only makes sense for
408             the FIDO authenticator algorithms ecdsa-sk and ed25519-sk.
409
410     restrict
411             Enable all restrictions, i.e. disable port, agent and X11 for‐
412             warding, as well as disabling PTY allocation and execution of
413             ~/.ssh/rc.  If any future restriction capabilities are added to
414             authorized_keys files, they will be included in this set.
415
416     tunnel="n"
417             Force a tun(4) device on the server.  Without this option, the
418             next available device will be used if the client requests a tun‐
419             nel.
420
421     user-rc
422             Enables execution of ~/.ssh/rc previously disabled by the
423             restrict option.
424
425     X11-forwarding
426             Permits X11 forwarding previously disabled by the restrict op‐
427             tion.
428
429     An example authorized_keys file:
430
431        # Comments are allowed at start of line. Blank lines are allowed.
432        # Plain key, no restrictions
433        ssh-rsa ...
434        # Forced command, disable PTY and all forwarding
435        restrict,command="dump /home" ssh-rsa ...
436        # Restriction of ssh -L forwarding destinations
437        permitopen="192.0.2.1:80",permitopen="192.0.2.2:25" ssh-rsa ...
438        # Restriction of ssh -R forwarding listeners
439        permitlisten="localhost:8080",permitlisten="[::1]:22000" ssh-rsa ...
440        # Configuration for tunnel forwarding
441        tunnel="0",command="sh /etc/netstart tun0" ssh-rsa ...
442        # Override of restriction to allow PTY allocation
443        restrict,pty,command="nethack" ssh-rsa ...
444        # Allow FIDO key without requiring touch
445        no-touch-required sk-ecdsa-sha2-nistp256@openssh.com ...
446        # Require user-verification (e.g. PIN or biometric) for FIDO key
447        verify-required sk-ecdsa-sha2-nistp256@openssh.com ...
448        # Trust CA key, allow touch-less FIDO if requested in certificate
449        cert-authority,no-touch-required,principals="user_a" ssh-rsa ...
450

SSH_KNOWN_HOSTS FILE FORMAT

452     The /etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts files contain host
453     public keys for all known hosts.  The global file should be prepared by
454     the administrator (optional), and the per-user file is maintained auto‐
455     matically: whenever the user connects to an unknown host, its key is
456     added to the per-user file.
457
458     Each line in these files contains the following fields: marker (op‐
459     tional), hostnames, keytype, base64-encoded key, comment.  The fields are
460     separated by spaces.
461
462     The marker is optional, but if it is present then it must be one of
463     “@cert-authority”, to indicate that the line contains a certification au‐
464     thority (CA) key, or “@revoked”, to indicate that the key contained on
465     the line is revoked and must not ever be accepted.  Only one marker
466     should be used on a key line.
467
468     Hostnames is a comma-separated list of patterns (‘*’ and ‘?’ act as wild‐
469     cards); each pattern in turn is matched against the host name.  When sshd
470     is authenticating a client, such as when using HostbasedAuthentication,
471     this will be the canonical client host name.  When ssh(1) is authenticat‐
472     ing a server, this will be the host name given by the user, the value of
473     the ssh(1) HostkeyAlias if it was specified, or the canonical server
474     hostname if the ssh(1) CanonicalizeHostname option was used.
475
476     A pattern may also be preceded by ‘!’ to indicate negation: if the host
477     name matches a negated pattern, it is not accepted (by that line) even if
478     it matched another pattern on the line.  A hostname or address may op‐
479     tionally be enclosed within ‘[’ and ‘]’ brackets then followed by ‘:’ and
480     a non-standard port number.
481
482     Alternately, hostnames may be stored in a hashed form which hides host
483     names and addresses should the file's contents be disclosed.  Hashed
484     hostnames start with a ‘|’ character.  Only one hashed hostname may ap‐
485     pear on a single line and none of the above negation or wildcard opera‐
486     tors may be applied.
487
488     The keytype and base64-encoded key are taken directly from the host key;
489     they can be obtained, for example, from /etc/ssh/ssh_host_rsa_key.pub.
490     The optional comment field continues to the end of the line, and is not
491     used.
492
493     Lines starting with ‘#’ and empty lines are ignored as comments.
494
495     When performing host authentication, authentication is accepted if any
496     matching line has the proper key; either one that matches exactly or, if
497     the server has presented a certificate for authentication, the key of the
498     certification authority that signed the certificate.  For a key to be
499     trusted as a certification authority, it must use the “@cert-authority”
500     marker described above.
501
502     The known hosts file also provides a facility to mark keys as revoked,
503     for example when it is known that the associated private key has been
504     stolen.  Revoked keys are specified by including the “@revoked” marker at
505     the beginning of the key line, and are never accepted for authentication
506     or as certification authorities, but instead will produce a warning from
507     ssh(1) when they are encountered.
508
509     It is permissible (but not recommended) to have several lines or differ‐
510     ent host keys for the same names.  This will inevitably happen when short
511     forms of host names from different domains are put in the file.  It is
512     possible that the files contain conflicting information; authentication
513     is accepted if valid information can be found from either file.
514
515     Note that the lines in these files are typically hundreds of characters
516     long, and you definitely don't want to type in the host keys by hand.
517     Rather, generate them by a script, ssh-keyscan(1) or by taking, for exam‐
518     ple, /etc/ssh/ssh_host_rsa_key.pub and adding the host names at the
519     front.  ssh-keygen(1) also offers some basic automated editing for
520     ~/.ssh/known_hosts including removing hosts matching a host name and con‐
521     verting all host names to their hashed representations.
522
523     An example ssh_known_hosts file:
524
525        # Comments allowed at start of line
526        cvs.example.net,192.0.2.10 ssh-rsa AAAA1234.....=
527        # A hashed hostname
528        |1|JfKTdBh7rNbXkVAQCRp4OQoPfmI=|USECr3SWf1JUPsms5AqfD5QfxkM= ssh-rsa
529        AAAA1234.....=
530        # A revoked key
531        @revoked * ssh-rsa AAAAB5W...
532        # A CA key, accepted for any host in *.mydomain.com or *.mydomain.org
533        @cert-authority *.mydomain.org,*.mydomain.com ssh-rsa AAAAB5W...
534

FILES

536     ~/.hushlogin
537             This file is used to suppress printing the last login time and
538             /etc/motd, if PrintLastLog and PrintMotd, respectively, are en‐
539             abled.  It does not suppress printing of the banner specified by
540             Banner.
541
542     ~/.rhosts
543             This file is used for host-based authentication (see ssh(1) for
544             more information).  On some machines this file may need to be
545             world-readable if the user's home directory is on an NFS parti‐
546             tion, because sshd reads it as root.  Additionally, this file
547             must be owned by the user, and must not have write permissions
548             for anyone else.  The recommended permission for most machines is
549             read/write for the user, and not accessible by others.
550
551     ~/.shosts
552             This file is used in exactly the same way as .rhosts, but allows
553             host-based authentication without permitting login with
554             rlogin/rsh.
555
556     ~/.k5login
557     ~/.k5users
558             These files enforce GSSAPI/Kerberos authentication access con‐
559             trol.  Further details are described in ksu(1).  The location of
560             the k5login file depends on the configuration option
561             k5login_directory in the krb5.conf(5).
562
563     ~/.ssh/
564             This directory is the default location for all user-specific con‐
565             figuration and authentication information.  There is no general
566             requirement to keep the entire contents of this directory secret,
567             but the recommended permissions are read/write/execute for the
568             user, and not accessible by others.
569
570     ~/.ssh/authorized_keys
571             Lists the public keys (DSA, ECDSA, Ed25519, RSA) that can be used
572             for logging in as this user.  The format of this file is de‐
573             scribed above.  The content of the file is not highly sensitive,
574             but the recommended permissions are read/write for the user, and
575             not accessible by others.
576
577             If this file, the ~/.ssh directory, or the user's home directory
578             are writable by other users, then the file could be modified or
579             replaced by unauthorized users.  In this case, sshd will not al‐
580             low it to be used unless the StrictModes option has been set to
581             “no”.
582
583     ~/.ssh/environment
584             This file is read into the environment at login (if it exists).
585             It can only contain empty lines, comment lines (that start with
586             ‘#’), and assignment lines of the form name=value.  The file
587             should be writable only by the user; it need not be readable by
588             anyone else.  Environment processing is disabled by default and
589             is controlled via the PermitUserEnvironment option.
590
591     ~/.ssh/known_hosts
592             Contains a list of host keys for all hosts the user has logged
593             into that are not already in the systemwide list of known host
594             keys.  The format of this file is described above.  This file
595             should be writable only by root/the owner and can, but need not
596             be, world-readable.
597
598     ~/.ssh/rc
599             Contains initialization routines to be run before the user's home
600             directory becomes accessible.  This file should be writable only
601             by the user, and need not be readable by anyone else.
602
603     /etc/hosts.equiv
604             This file is for host-based authentication (see ssh(1)).  It
605             should only be writable by root.
606
607     /etc/ssh/moduli
608             Contains Diffie-Hellman groups used for the "Diffie-Hellman Group
609             Exchange" key exchange method.  The file format is described in
610             moduli(5).  If no usable groups are found in this file then fixed
611             internal groups will be used.
612
613     /etc/motd
614             See motd(5).
615
616     /etc/nologin
617             If this file exists, sshd refuses to let anyone except root log
618             in.  The contents of the file are displayed to anyone trying to
619             log in, and non-root connections are refused.  The file should be
620             world-readable.
621
622     /etc/ssh/shosts.equiv
623             This file is used in exactly the same way as hosts.equiv, but al‐
624             lows host-based authentication without permitting login with
625             rlogin/rsh.
626
627     /etc/ssh/ssh_host_ecdsa_key
628     /etc/ssh/ssh_host_ed25519_key
629     /etc/ssh/ssh_host_rsa_key
630             These files contain the private parts of the host keys.  These
631             files should only be owned by root, readable only by root, and
632             not accessible to others.  Note that sshd does not start if these
633             files are group/world-accessible.
634
635     /etc/ssh/ssh_host_ecdsa_key.pub
636     /etc/ssh/ssh_host_ed25519_key.pub
637     /etc/ssh/ssh_host_rsa_key.pub
638             These files contain the public parts of the host keys.  These
639             files should be world-readable but writable only by root.  Their
640             contents should match the respective private parts.  These files
641             are not really used for anything; they are provided for the con‐
642             venience of the user so their contents can be copied to known
643             hosts files.  These files are created using ssh-keygen(1).
644
645     /etc/ssh/ssh_known_hosts
646             Systemwide list of known host keys.  This file should be prepared
647             by the system administrator to contain the public host keys of
648             all machines in the organization.  The format of this file is de‐
649             scribed above.  This file should be writable only by root/the
650             owner and should be world-readable.
651
652     /etc/ssh/sshd_config
653             Contains configuration data for sshd.  The file format and con‐
654             figuration options are described in sshd_config(5).
655
656     /etc/ssh/sshrc
657             Similar to ~/.ssh/rc, it can be used to specify machine-specific
658             login-time initializations globally.  This file should be
659             writable only by root, and should be world-readable.
660
661     /usr/share/empty.sshd
662             chroot(2) directory used by sshd during privilege separation in
663             the pre-authentication phase.  The directory should not contain
664             any files and must be owned by root and not group or world-
665             writable.
666
667     /var/run/sshd.pid
668             Contains the process ID of the sshd listening for connections (if
669             there are several daemons running concurrently for different
670             ports, this contains the process ID of the one started last).
671             The content of this file is not sensitive; it can be world-read‐
672             able.
673

IPV6

675     IPv6 address can be used everywhere where IPv4 address. In all entries
676     must be the IPv6 address enclosed in square brackets. Note: The square
677     brackets are metacharacters for the shell and must be escaped in shell.
678

SEE ALSO

680     scp(1), sftp(1), ssh(1), ssh-add(1), ssh-agent(1), ssh-keygen(1),
681     ssh-keyscan(1), chroot(2), login.conf(5), moduli(5), sshd_config(5),
682     inetd(8), sftp-server(8)
683

AUTHORS

685     OpenSSH is a derivative of the original and free ssh 1.2.12 release by
686     Tatu Ylonen.  Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo
687     de Raadt and Dug Song removed many bugs, re-added newer features and cre‐
688     ated OpenSSH.  Markus Friedl contributed the support for SSH protocol
689     versions 1.5 and 2.0.  Niels Provos and Markus Friedl contributed support
690     for privilege separation.
691
692BSD                            February 10, 2023                           BSD
Impressum