1sshd(1M) System Administration Commands sshd(1M)
2
6 sshd - secure shell daemon
7
9 sshd [-deiqtD46] [-b bits] [-f config_file]
10 [-g login_grace_time] [-h host_key_file]
11 [-k key_gen_time] [-p port] [-V client_protocol_id]
12
15 The sshd (Secure Shell daemon) is the daemon program for ssh(1).
16 Together these programs replace rlogin and rsh, and provide secure
17 encrypted communications between two untrusted hosts over an insecure
18 network. The programs are intended to be as easy to install and use as
19 possible.
20 sshd is the daemon that listens for connections from clients. It forks
23 a new daemon for each incoming connection. The forked daemons handle
24 key exchange, encryption, authentication, command execution, and data
25 exchange.
26 This implementation of sshd supports both SSH protocol versions 1 and 2
29 simultaneously. Because of security weaknesses in the v1 protocol,
30 sites should run only v2, if possible. In the default configuration,
31 only protocol v2 is enabled for the server. To enable v1 and v2 simul‐
32 taneously, see the instructions in sshd_config(4).
33 Support for v1 is provided to help sites with existing ssh v1 clients
36 and servers to transition to v2. v1 might not be supported in a future
37 release.
38 SSH Protocol Version 1
40 Each host has a host-specific RSA key (normally 1024 bits) used to
41 identify the host. Additionally, when the daemon starts, it generates a
42 server RSA key (normally 768 bits). This key is normally regenerated
43 every hour if it has been used, and is never stored on disk.
44 Whenever a client connects the daemon responds with its public host and
47 server keys. The client compares the RSA host key against its own data‐
48 base to verify that it has not changed. The client then generates a
49 256-bit random number. It encrypts this random number using both the
50 host key and the server key, and sends the encrypted number to the
51 server. Both sides then use this random number as a session key which
52 is used to encrypt all further communications in the session. The rest
53 of the session is encrypted using a conventional cipher, currently
54 Blowfish or 3DES, with 3DES being used by default. The client selects
55 the encryption algorithm to use from those offered by the server.
56 Next, the server and the client enter an authentication dialog. The
59 client tries to authenticate itself using .rhosts authentication,
60 .rhosts authentication combined with RSA host authentication, RSA chal‐
61 lenge-response authentication, or password-based authentication.
62 Rhosts authentication is normally disabled because it is fundamentally
65 insecure, but can be enabled in the server configuration file if
66 desired. System security is not improved unless rshd(1M), rlogind(1M),
67 rexecd(1M), and rexd(1M) are disabled (thus completely disabling
68 rlogin(1) and rsh(1) into the machine).
69 SSH Protocol Version 2
71 Version 2 works similarly to version 1: Each host has a host-specific
72 DSA/RSA key. However, when the daemon starts, it does not generate a
73 server key. Forward security is provided through a Diffie-Hellman key
74 agreement. This key agreement results in a shared session key. The rest
75 of the session is encrypted using a symmetric cipher, currently 128-bit
76 AES, Blowfish, 3DES, or AES. The client selects the encryption algo‐
77 rithm to use from those offered by the server. Additionally, session
78 integrity is provided through a cryptographic message authentication
79 code (hmac-sha1 or hmac-md5).
80 Protocol version 2 provides a public key based user authentication
83 method (PubKeyAuthentication) GSS-API based user authentication, con‐
84 ventional password authentication, and a generic prompt/reply protocol
85 for password-based authentication.
86 Command Execution and Data Forwarding
88 If the client successfully authenticates itself, a dialog for preparing
89 the session is entered. At this time the client can request things like
90 allocating a pseudo-tty, forwarding X11 connections, forwarding TCP/IP
91 connections, or forwarding the authentication agent connection over the
92 secure channel.
93 Finally, the client either requests a shell or execution of a command.
96 The sides then enter session mode. In this mode, either side may send
97 data at any time, and such data is forwarded to/from the shell or com‐
98 mand on the server side, and the user terminal on the client side.
99 When the user program terminates and all forwarded X11 and other con‐
102 nections have been closed, the server sends command exit status to the
103 client, and both sides exit.
104 sshd can be configured using command-line options or the configuration
107 file /etc/ssh/ssh_config, described in ssh_config(4). Command-line
108 options override values specified in the configuration file.
109 sshd rereads its configuration file when it receives a hangup signal,
112 SIGHUP, by executing itself with the name it was started as, that is,
113 /usr/lib/ssh/sshd.
114 Host Access Control
116 The sshd daemon uses TCP Wrappers to restrict access to hosts. It uses
117 the service name of sshd for hosts_access(). For more information on
118 TCP Wrappers see tcpd(1M) and hosts_access(3) man pages, which are part
119 of the SUNWsfman package (they are not SunOS man pages). TCP wrappers
120 binaries, including libwrap, are in SUNWtcpd, a required package for
121 SUNWsshdu, the package containing sshd.
122
124 The options for sshd are as follows:
125 -b bits
127 Specifies the number of bits in the server key (the default is
129 768).
130 -d
133 Debug mode. The server sends verbose debug output to the system
135 log, and does not put itself in the background. The server also
136 will not fork and will only process one connection. This option is
137 only intended for debugging for the server. Multiple -d options
138 increase the debugging level. Maximum is 3.
139 -e
142 When this option is specified, sshd will send the output to stan‐
144 dard error instead of to the system log.
145 -f configuration_file
148 Specifies the name of the configuration file. The default is
150 /etc/ssh/sshd_config. sshd refuses to start if there is no configu‐
151 ration file.
152 -g login_grace_time
155 Gives the grace time for clients to authenticate themselves (the
157 default is 300 seconds). If the client fails to authenticate the
158 user within this number of seconds, the server disconnects and
159 exits. A value of zero indicates no limit.
160 -h host_key_file
163 Specifies a file from which a host key is read. This option must be
165 given if sshd is not run as root (as the normal host key files are
166 normally not readable by anyone but root). The default is
167 /etc/ssh/ssh_host_key for protocol version 1, and
168 /etc/ssh/ssh_host_rsa_key and /etc/ssh/ssh_host_dsa_key for proto‐
169 col version 2. It is possible to have multiple host key files for
170 the different protocol versions and host key algorithms.
171 -i
174 Specifies that sshd is being run from inetd. sshd is normally not
176 run from inetd because it needs to generate the server key before
177 it can respond to the client, and this may take tens of seconds.
178 Clients would have to wait too long if the key was regenerated
179 every time. However, with small key sizes (for example, 512) using
180 sshd from inetd may be reasonable.
181 -k key_gen_time
184 (SSHv1-specific) Specifies how often the server key is regenerated
186 (the default is 3600 seconds, or one hour). The motivation for
187 regenerating the key fairly often is that the key is not stored
188 anywhere, and after about an hour, it becomes impossible to recover
189 the key for decrypting intercepted communications even if the
190 machine is cracked into or physically seized. A value of zero indi‐
191 cates that the key will never be regenerated.
192 -o option
195 Can be used to specify options in the format used in the configura‐
197 tion file. This is useful for specifying options for which there
198 are no separate command-line flags.
199 -p port
202 Specifies the port on which the server listens for connections (the
204 default is 22).
205 -q
208 Quiet mode. Nothing is sent to the system log. Normally the begin‐
210 ning, authentication, and termination of each connection is logged.
211 -t
214 Test mode. Check only the validity of the configuration file and
216 the sanity of the keys. This is useful for updating sshd reliably
217 as configuration options might change.
218 -D
221 When this option is specified sshd does not detach and does not
223 become a daemon. This allows easy monitoring of sshd.
224 -4
227 Forces sshd to use IPv4 addresses only.
229 -6
232 Forces sshd to use IPv6 addresses only.
234
237 authorized_keys File Format
238 The $HOME/.ssh/authorized_keys file lists the public keys that are per‐
239 mitted for RSA authentication in protocol version 1 and for public key
240 authentication (PubkeyAuthentication) in protocol version 2. The Autho‐
241 rizedKeysFile configuration option can be used to specify an alterna‐
242 tive file.
243 Each line of the file contains one key (empty lines and lines starting
246 with a hash mark [#] are ignored as comments).
247 For each RSA key for protocol version 1, the file consists of the fol‐
250 lowing space-separated fields:
251 options bits exponent modulus comment
253 For the public key for protocol version 2, the file consists of the
258 following space-separated fields:
259 options key-type base64-encoding-key comment
261 For protocol version 2, key-type is one of ssh-rsa or ssh-dsa.
266 The options field is optional; its presence is determined by whether
269 the line starts with a number. (The option field never starts with a
270 number.) The bits, exponent, and modulus fields give the RSA key; the
271 comment field is a convenient place for you to identify the key.
272 Lines in this file are usually several hundred bytes long (because of
275 the size of the key modulus). You will find it very inconvenient to
276 type them in; instead, copy the public key file and edit it.
277 Permissions of this file must be set so that it is not world or group
280 writable. See the StrictModes option of sshd_config(4).
281 The options (if present) consist of comma-separated option specifica‐
284 tions. No spaces are permitted, except within double quotes. The fol‐
285 lowing option specifications are supported:
286 from="pattern-list"
288 Specifies that, in addition to public key authentication, the
290 canonical name of the remote host must be present in the comma-sep‐
291 arated list of patterns (`*' and `?' serve as wildcards). The list
292 can also contain negated patterns by prefixing the patterns with
293 `!'. If the canonical host name matches a negated pattern, the key
294 is not accepted.
295 The purpose of this option is to give you the option of increasing
297 security: public key authentication by itself does not trust the
298 network or name servers or anything but the key. However, if some‐
299 one manages to steal the key, possession of the key would permit
300 the intruder to log in from anywhere in the world. This option
301 makes using a stolen key more difficult, because name servers and
302 routers would have to be compromised, in addition to just the key.
303 command="command"
306 Specifies that the command is executed whenever this key is used
308 for authentication. The command supplied by the user (if any) is
309 ignored. The command is run on a pty if the client requests a pty;
310 otherwise it is run without a tty. If an 8-bit clean channel is
311 required, one must not request a pty or should specify no-pty. You
312 can include a quote in the command by escaping it with a backslash.
313 This option might be useful to restrict certain public keys from
314 performing a specific operation. An example is a key that permits
315 remote backups but nothing else. Note that the client can specify
316 TCP/IP and/or X11 forwarding unless they are explicitly prohibited
317 from doing so. Also note that this option applies to shell, com‐
318 mand, or subsystem execution.
319 environment="NAME=value"
322 Specifies that the string NAME=value is to be added to the environ‐
324 ment when logging in using this key. Environment variables set this
325 way override other default environment values. Multiple options of
326 this type are permitted. Environment processing is disabled by
327 default and is controlled via the PermitUserEnvironment option.
328 no-port-forwarding
331 Forbids TCP/IP forwarding when this key is used for authentication.
333 Any port forward requests by the client will return an error. This
334 might be used, for example, in connection with the command option.
335 no-X11-forwarding
338 Forbids X11 forwarding when this key is used for authentication.
340 Any X11 forward requests by the client will return an error.
341 no-agent-forwarding
344 Forbids authentication agent forwarding when this key is used for
346 authentication.
347 no-pty
350 Prevents tty allocation (a request to allocate a pty will fail).
352 permitopen="host:port"
355 Limit local ssh -L port forwarding such that it can connect only to
357 the specified host and port. IPv6 addresses can be specified with
358 an alternative syntax: host/port. You can invoke multiple permi‐
359 topen options, with each instance separated by a comma. No pattern
360 matching is performed on the specified hostnames. They must be lit‐
361 eral domains or addresses.
362 ssh_known_hosts File Format
365 The /etc/ssh/ssh_known_hosts and $HOME/.ssh/known_hosts files contain
366 host public keys for all known hosts. The global file should be pre‐
367 pared by the administrator (optional), and the per-user file is main‐
368 tained automatically: whenever the user connects from an unknown host
369 its key is added to the per-user file.
370 For the RSA key for protocol version 1, these files consist of the fol‐
373 lowing space-separated fields:
374 hostnames bits exponent modulus comment
376 For the public key for protocol version 2, these files consist of the
381 following space-separated fields:
382 hostnames key-type base64-encoding-key comment
384 For protocol version 2, key-type is one of ssh-rsa or ssh-dsa.
389 Hostnames is a comma-separated list of patterns (* and ? act as wild‐
392 cards); each pattern in turn is matched against the canonical host name
393 (when authenticating a client) or against the user-supplied name (when
394 authenticating a server). A pattern can also be preceded by ! to indi‐
395 cate negation: if the host name matches a negated pattern, it is not
396 accepted (by that line) even if it matched another pattern on the line.
397 Alternately, hostnames can be stored in a hashed form, which hides host
400 names and addresses should the file's contents be disclosed. Hashed
401 hostnames start with a vertical bar (|) character. Only one hashed
402 hostname can appear on a single line and none of the above negation or
403 wildcard operators may be applied.
404 Bits, exponent, and modulus are taken directly from the RSA host key;
407 they can be obtained, for example, from /etc/ssh/ssh_host_rsa_key.pub.
408 The optional comment field continues to the end of the line, and is not
409 used.
410 Lines starting with a hash mark (#) and empty lines are ignored as com‐
413 ments.
414 When performing host authentication, authentication is accepted if any
417 matching line has the proper key. It is thus permissible (but not rec‐
418 ommended) to have several lines or different host keys for the same
419 names. This will inevitably happen when short forms of host names from
420 different domains are put in the file. It is possible that the files
421 contain conflicting information; authentication is accepted if valid
422 information can be found from either file.
423 The lines in these files are typically hundreds of characters long. You
426 should definitely not type in the host keys by hand. Rather, generate
427 them by a script or by taking /etc/ssh/ssh_host_rsa_key.pub and adding
428 the host names at the front.
429
431 sshd sets the following environment variables for commands executed by
432 ssh users:
433 DISPLAY
435 Indicates the location of the X11 server. It is automatically set
437 by sshd to point to a value of the form hostname:n, where hostname
438 indicates the host where the shell runs, and n is an integer
439 greater than or equal to 1. ssh uses this special value to forward
440 X11 connections over the secure channel. Unless you have important
441 reasons to do otherwise, you should not set DISPLAY explicitly, as
442 that will render the X11 connection insecure and will require you
443 to manually copy any required authorization cookies.
444 HOME
447 Set to the path of the user's home directory.
449 LANG, LC_ALL, LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY,
452 LC_NUMERIC, LC_TIME
453 A locale setting. The locale defaults to that of sshd (usually the
455 system-wide default locale), or is negotiated between the client
456 and server during initial key exchange (as per RFC 4253).
457 Following initial key exchange, each of the variables can be over‐
459 riden in the following sequence:
460 1. If a locale setting is set in a client's environment and
462 that client supports "Environment Variable Passing" (see
463 RFC 4254), then the setting will be passed over to the
464 server side.
465 2. If the public key authentication method was used to
467 authenticate the server and the PermitUserEnvironment
468 variable in sshd_config(4) is set to yes on the server
469 side, then the setting can be changed through the use of
470 the environment option in the client's Authorized‐
471 KeysFile file.
472 3. The setting can be change in the client's ~/.ssh/envi‐
474 ronment file on the server.
475 See PermitUserEnvironment in sshd_config(4) as to when the Autho‐
476 rizedKeysFile and ~/.ssh/environment files are processed and used
477 for setting the user environment.
478 LOGNAME
481 Synonym for USER. Set for compatibility with systems that use this
483 variable.
484 MAIL
487 Set to point to the user's mailbox.
489 SSH_AUTH_SOCK
492 Indicates the path of a unix-domain socket used to communicate with
494 the agent.
495 SSH_CONNECTION
498 Identifies the client and server ends of the connection. The vari‐
500 able contains four space-separated values: client IP address,
501 client port number, server IP address and server port number.
502 SSH_CLIENT
505 Identifies the client end of the connection. The variable contains
507 three space-separated values: client IP address, client port num‐
508 ber, and server port number.
509 SSH_TTY
512 Set to the name of the tty (path to the device) associated with the
514 current shell or command. If the current session has no tty, this
515 variable is not set.
516 TZ
519 Indicates the present timezone, if TIMEZONE is set in
521 /etc/default/login or if TZ was set when the daemon was started.
522 HZ
525 If set in /etc/default/login, the daemon sets it to the same value.
527 SHELL
530 The user's shell, if ALTSHELL=YES in /etc/default/login.
532 PATH
535 Set to the value of PATH or SUPATH (see login(1)) in
537 /etc/default/login, or, if not set, to /usr/bin:/bin.
538 USER
541 Set to the name of the user logging in.
543 Additionally, sshd reads $HOME/.ssh/environment and adds lines of the
547 format VARNAME=value to the environment.
548
550 In the following examples, certain lines might wrap due to line length
551 limits in your display. You should nevertheless consider the wrapped
552 line as a single line.
553 Example 1 authorized_key File Entries
555 The following are examples of authorized_key file entries for protocol
558 1:
559 1024 33 12121...312314325 ylo@foo.bar
562 from="*.niksula.hut.fi,!pc.niksula.hut.fi" 1024 35 23...2334 ylo@niksula
564 command="dump /home",no-pty,no-port-forwarding 1024 33 23...2323 backup.hut.fi
566 Example 2 authorized_key File Entries for Protocol 2
570 The following are examples of authorized_key file entries for protocol
573 2:
574 ssh-rsa AAAAB3NzaC1y.....EU88ovYKg4GfclWGCFYTuw8= ylo@foo.bar
577 from="*.niksula.hut.fi" ssh-rsa AAAAB3NzaC...uw8= ylo@niksula
578 command="dump /home",no-pty,no-port-forwarding ssh-rsa AA..8= backup.hut.fi
579 Example 3 ssh_known_hosts File Entries for Protocol 1
583 The following are examples of ssh_known_hosts file entries for protocol
586 1:
587 closenet,closenet.hut.fi,...,130.233.208.41 1024 37 159...93 closenet.hut.fi
590 Example 4 ssh_known_hosts File Entries for Protocol 2
594 The following are examples of ssh_known_hosts file entries for protocol
597 2:
598 closenet,closenet.hut.fi,...,130.233.208.41 ssh-rsa AA..8= closenet.hut.fi
601
605 The following exit values are returned:
606 0 Successful completion.
608 >0 An error occurred.
611
614 /etc/default/login
615 Contains defaults for several sshd_config parameters, environment
617 variables, and other environmental factors.
618 The following parameters affect environment variables (see login(1)
620 and descriptions of these variables, above):
621 o TIMEZONE
623 o HZ
625 o ALTSHELL
627 o PATH
629 o SUPATH
631 The following /etc/default/login parameters supply default values
632 for corresponding sshd_config(4) parameters:
633 o CONSOLE (see PermitRootLogin in sshd_config(4))
635 o PASSREQ (see PermitEmptyPasswords in sshd_config(4))
637 o TIMEOUT (see LoginGraceTime in sshd_config(4))
639 The following /etc/default/login parameters:
640 o UMASK
642 o ULIMIT
644 ...set the umask(2) and file size limit of, respectively, the
645 shells and commands spawned by sshd.
646 Finally, two /etc/default/login parameters affect the maximum
648 allowed login attempts per-connection using interactive user
649 authentication methods (for example, keyboard-interactive but not
650 publickey), as per login(1):
651 o RETRIES
653 o SYSLOG_FAILED_LOGINS
655 /etc/ssh/sshd_config
658 Contains configuration data for sshd. This file should be writable
660 by root only, but it is recommended (though not necessary) that it
661 be world-readable.
662 /etc/ssh/ssh_host_key
665 /etc/ssh/ssh_host_dsa_key
666 /etc/ssh/ssh_host_rsa_key
667 Contains the private part of the host key. This file should only be
669 owned by root, readable only by root, and not accessible to others.
670 sshd does not start if this file is group/world-accessible.
671 /etc/ssh/ssh_host_key.pub
674 /etc/ssh/ssh_host_dsa_key.pub
675 /etc/ssh/ssh_host_rsa_key.pub
676 Contains the public part of the host key. This file should be
678 world-readable but writable only by root. Its contents should match
679 the private part. This file is not used for encryption; it is pro‐
680 vided only for the convenience of the user so its contents can be
681 copied to known hosts files. These two files are created using ssh-
682 keygen(1).
683 /var/run/sshd.pid
686 Contains the process ID of the sshd listening for connections. If
688 there are several daemons running concurrently for different ports,
689 this contains the pid of the one started last. The content of this
690 file is not sensitive; it can be world-readable. You can use the
691 PidFile keyword in sshd_config to specify a file other than
692 /var/run/sshd.pid. See sshd_config(4).
693 /etc/ssh/ssh_known_hosts and $HOME/.ssh/known_hosts
696 These files are consulted when using rhosts with public key host
698 authentication to check the public key of the host. The key must be
699 listed in one of these files to be accepted. The client uses the
700 same files to verify that the remote host is the one it intended to
701 connect. These files should be writable only by root or the owner.
702 /etc/ssh/ssh_known_hosts should be world-readable, and
703 $HOME/.ssh/known_hosts can but need not be world-readable.
704 /etc/nologin
707 If this file exists, sshd refuses to let anyone except root log in.
709 The contents of the file are displayed to anyone trying to log in,
710 and non-root connections are refused. The file should be world-
711 readable.
712 $HOME/.ssh/authorized_keys
715 Lists the public keys (RSA or DSA) that can be used to log into the
717 user's account. This file must be readable by root. This might, on
718 some machines, imply that it is world-readable if the user's home
719 directory resides on an NFS volume. It is recommended that it not
720 be accessible by others. The format of this file is described
721 above. Users will place the contents of their identity.pub,
722 id_dsa.pub and/or id_rsa.pub files into this file, as described in
723 ssh-keygen(1).
724 $HOME/.rhosts
727 This file contains host-username pairs, separated by a space, one
729 per line. The given user on the corresponding host is permitted to
730 log in without password. The same file is used by rlogind and rshd.
731 The file must be writable only by the user; it is recommended that
732 it not be accessible by others. It is also possible to use net‐
733 groups in the file. Either host or user name may be of the form
734 +@groupname to specify all hosts or all users in the group.
735 $HOME/.shosts
738 For ssh, this file is exactly the same as for .rhosts. However,
740 this file is not used by rlogin and rshd, so using this permits
741 access using SSH only.
742 /etc/hosts.equiv
745 This file is used during .rhosts authentication. In its simplest
747 form, this file contains host names, one per line. Users on these
748 hosts are permitted to log in without a password, provided they
749 have the same user name on both machines. The host name can also be
750 followed by a user name; such users are permitted to log in as any
751 user on this machine (except root). Additionally, the syntax
752 +@group can be used to specify netgroups. Negated entries start
753 with a hyphen (-).
754 If the client host/user is successfully matched in this file, login
756 is automatically permitted, provided the client and server user
757 names are the same. Additionally, successful RSA host authentica‐
758 tion is normally required. This file must be writable only by root;
759 it is recommended that it be world-readable.
760 Warning: It is almost never a good idea to use user names in
762 hosts.equiv. Beware that it really means that the named user(s) can
763 log in as anybody, which includes bin, daemon, adm, and other
764 accounts that own critical binaries and directories. For practical
765 purposes, using a user name grants the user root access. Probably
766 the only valid use for user names is in negative entries. This
767 warning also applies to rsh/rlogin.
768 /etc/ssh/moduli
771 A private file.
773 /etc/ssh/shosts.equiv
776 This file is processed exactly as /etc/hosts.equiv. However, this
778 file might be useful in environments that want to run both
779 rsh/rlogin and ssh.
780 $HOME/.ssh/environment
783 This file is read into the environment at login (if it exists). It
785 can contain only empty lines, comment lines (that start with #),
786 and assignment lines of the form name=value. The file should be
787 writable only by the user; it need not be readable by anyone else.
788 Environment processing is disabled by default and is controlled by
789 means of the PermitUserEnvironment option.
790 $HOME/.ssh/rc
793 If this file exists, it is run with /bin/sh after reading the envi‐
795 ronment files but before starting the user's shell or command. If
796 X11 spoofing is in use, this will receive the proto cookie pair in
797 standard input (and DISPLAY in environment). This must call xauth
798 in that case.
799 The primary purpose of $HOME/.ssh/rc is to run any initialization
801 routines that might be needed before the user's home directory
802 becomes accessible; AFS is a particular example of such an environ‐
803 ment. If this file exists, it is run with /bin/sh after reading the
804 environment files, but before starting the user's shell or command.
805 It must not produce any output on stdout; stderr must be used
806 instead. If X11 forwarding is in use, it will receive the proto
807 cookie pair in its standard input and DISPLAY in its environment.
808 The script must call xauth because sshd will not run xauth automat‐
809 ically to add X11 cookies.
810 This file will probably contain some initialization code followed
812 by something similar to:
813 if read proto cookie && [ -n "$DISPLAY" ]
815 then
816 if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]
817 then
818 # X11UseLocalhost=yes
819 echo add unix:`echo $DISPLAY |
820 cut -c11-` $proto $cookie
821 else
822 # X11UseLocalhost=no
823 echo add $DISPLAY $proto $cookie
824 fi | xauth -q -
825 fi
826 If this file does not exist, /etc/ssh/sshrc is run, and if that
829 does not exist, xauth is used to store the cookie. $HOME/.ssh/rc
830 should be writable only by the user, and need not be readable by
831 anyone else.
832 /etc/ssh/sshrc
835 Similar to $HOME/.ssh/rc. This can be used to specify machine-spe‐
837 cific login-time initializations globally. This file should be
838 writable only by root, and should be world-readable.
839
842 sshd supports the use of several user authentication mechanisms: a pub‐
843 lic key system where keys are associated with users (through users'
844 authorized_keys files), a public key system where keys are associated
845 with hosts (see the HostbasedAuthentication configuration parameter), a
846 GSS-API based method (see the GssAuthentication and GssKeyEx configura‐
847 tion parameters) and three initial authentication methods: none, pass‐
848 word, and a generic prompt/reply protocol, keyboard-interactive.
849 sshd negotiates the use of the GSS-API with clients only if it has a
852 GSS-API acceptor credential for the "host" service. This means that,
853 for GSS-API based authentication, the server must have a Kerberos V
854 keytab entry (see below) or the equivalent for any other GSS-API mecha‐
855 nism that might be installed.
856 In order for Kerberos authentication to work, a host/<FQDN> Kerberos
859 principal must exist for each Fully Qualified Domain Name associated
860 with the in.sshd server. Each of these host/<FQDN> principals must have
861 a keytab entry in the /etc/krb5/krb5.keytab file on the in.sshd server.
862 An example principal might be:
863 host/bigmachine.eng.example.com
866 See kadmin(1M) or gkadmin(1M) for instructions on adding a principal to
869 a krb5.keytab file. See for a discussion of Kerberos authentication.
870 GSS-API authorization is covered in gss_auth_rules(5).
873 sshd uses pam(3PAM) for the three initial authentication methods as
876 well as for account management, session management, and password man‐
877 agement for all authentication methods.
878 Specifically, sshd calls pam_authenticate() for the "none," "password"
881 and "keyboard-interactive" SSHv2 userauth types, as well as for for the
882 null and password authentication methods for SSHv1. Other SSHv2 authen‐
883 tication methods do not call pam_authenticate(). pam_acct_mgmt() is
884 called for each authentication method that succeeds.
885 pam_setcred() and pam_open_session() are called when authentication
888 succeeds and pam_close_session() is called when connections are closed.
889 pam_open_session() and pam_close_session() are also called when SSHv2
892 channels with ptys are opened and closed.
893 Each SSHv2 userauth type has its own PAM service name:
896 ┌─────────────────────────────┬─────────────────────────────┐
901 │ SSHv2 Userauth │ PAM Service Name │
902 ├─────────────────────────────┼─────────────────────────────┤
903 │none │sshd-none │
904 ├─────────────────────────────┼─────────────────────────────┤
905 │password │sshd-password │
906 ├─────────────────────────────┼─────────────────────────────┤
907 │keyboard-interactive │sshd-kbdint │
908 ├─────────────────────────────┼─────────────────────────────┤
909 │pubkey │sshd-pubkey │
910 ├─────────────────────────────┼─────────────────────────────┤
911 │hostbased │sshd-hostbased │
912 ├─────────────────────────────┼─────────────────────────────┤
913 │gssapi-with-mic │sshd-gssapi │
914 ├─────────────────────────────┼─────────────────────────────┤
915 │gssapi-keyex │sshd-gssapi │
916 └─────────────────────────────┴─────────────────────────────┘
917 For SSHv1, sshd-v1 is always used.
920 If pam_acct_mgmt() returns PAM_NEW_AUTHTOK_REQD (indicating that the
923 user's authentication tokens have expired), then sshd forces the use of
924 "keyboard-interactive" userauth, if version 2 of the protocol is in
925 use. The "keyboard-interactive" userauth will call pam_chauthtok() if
926 pam_acct_mgmt() once again returns PAM_NEW_AUTHTOK_REQD. By this means,
927 administrators are able to control what authentication methods are
928 allowed for SSHv2 on a per-user basis.
929 Setting up Host-based Authentication
931 To establish host-based authentication, you must perform the following
932 steps:
933 o Configure the client.
935 o Configure the server.
937 o Publish known hosts.
939 o Make appropriate entries in /etc/ssh/shosts.equiv and
941 ~/.shosts.
942 These steps are expanded in the following paragraphs.
945 o On a client machine, in the system-wide client configuration
947 file, /etc/ssh/ssh_config, you must have the entry:
948 HostbasedAuthentication yes
950 See ssh_config(4) and ssh-keysign(1M).
952 o On the server, in the system-wide server configuration file,
954 /etc/ssh/sshd_config, you must have the entry:
955 HostbasedAuthentication yes
957 If per-user .shost files are to be allowed (see last step),
959 in the same file, you must have:
960 IgnoreRhosts no
962 See sshd_config(4) for a description of these keywords.
964 o To publish known hosts, you must have entries for the
966 clients from which users will be allowed host-based authen‐
967 tication. Make these entries in either or both of the sys‐
968 tem-wide file (/etc/ssh/ssh_known_hosts) or the per-user
969 file (~/.ssh/known_hosts).
970 o Note that sshd uses .shosts, not .rhosts. If you want the
972 functionality provided by .rhosts, but do not want to use
973 rlogin or rsh because of their security shortcomings, you
974 can use .shosts in conjunction with sshd. To use this fea‐
975 ture, make appropriate entries in /etc/ssh/shosts.equiv and
976 ~/.shosts, in the format specified in rhosts(4).
977 For the vast majority of network environments, .shosts is
979 preferred over .rhosts.
980
982 See attributes(5) for descriptions of the following attributes:
983 ┌─────────────────────────────┬─────────────────────────────┐
988 │ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
989 ├─────────────────────────────┼─────────────────────────────┤
990 │Availability │SUNWsshdu │
991 ├─────────────────────────────┼─────────────────────────────┤
992 │Interface Stability │Evolving │
993 └─────────────────────────────┴─────────────────────────────┘
994 The interface stability of /etc/ssh/moduli is Private.
997
999 login(1), scp(1), ssh(1), ssh-add(1), ssh-agent(1), ssh-keygen(1),
1000 svcs(1), gkadmin(1M), kadmin(1M), sftp-server(1M), ssh-keysign(1M),
1001 svcadm(1M), pam(3PAM), rhosts(4), ssh_config(4), sshd_config(4),
1002 attributes(5), gss_auth_rules(5), kerberos(5), pam_roles(5), smf(5)
1003
1008 The sshd service is managed by the service management facility, smf(5),
1009 under the service identifier:
1010 svc:/network/ssh:default
1012 Administrative actions on this service, such as enabling, disabling, or
1017 requesting restart, can be performed using svcadm(1M). The service's
1018 status can be queried using the svcs(1) command.
1019 sshd always sets PAM_RHOST and sets PAM_AUSER in the case of host-based
1022 userauth. This behavior allows for remote logins to roles using host-
1023 based authentication. See pam_roles(5).
1024SunOS 5.11 17 Mar 2009 sshd(1M)