1sshd(1M)                System Administration Commands                sshd(1M)
2
3
4

NAME

6       sshd - secure shell daemon
7

SYNOPSIS

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
13

DESCRIPTION

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
21
22       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
27
28       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
34
35       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
39   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
45
46       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
57
58       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
63
64       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
70   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
81
82       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
87   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
94
95       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
100
101       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
105
106       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
110
111       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
115   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

OPTIONS

124       The options for sshd are as follows:
125
126       -b bits
127
128           Specifies the number of bits in the  server  key  (the  default  is
129           768).
130
131
132       -d
133
134           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
140
141       -e
142
143           When  this  option is specified, sshd will send the output to stan‐
144           dard error instead of to the system log.
145
146
147       -f configuration_file
148
149           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
153
154       -g login_grace_time
155
156           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
161
162       -h host_key_file
163
164           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
172
173       -i
174
175           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
182
183       -k key_gen_time
184
185           (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
193
194       -o option
195
196           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
200
201       -p port
202
203           Specifies the port on which the server listens for connections (the
204           default is 22).
205
206
207       -q
208
209           Quiet  mode. Nothing is sent to the system log. Normally the begin‐
210           ning, authentication, and termination of each connection is logged.
211
212
213       -t
214
215           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
219
220       -D
221
222           When this option is specified sshd does not  detach  and  does  not
223           become a daemon. This allows easy monitoring of sshd.
224
225
226       -4
227
228           Forces sshd to use IPv4 addresses only.
229
230
231       -6
232
233           Forces sshd to use IPv6 addresses only.
234
235

EXTENDED DESCRIPTION

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
244
245       Each  line of the file contains one key (empty lines and lines starting
246       with a hash mark [#] are ignored as comments).
247
248
249       For each RSA key for protocol version 1, the file consists of the  fol‐
250       lowing space-separated fields:
251
252         options  bits  exponent  modulus  comment
253
254
255
256
257       For  the  public  key  for protocol version 2, the file consists of the
258       following space-separated fields:
259
260         options key-type base64-encoding-key comment
261
262
263
264
265       For protocol version 2, key-type is one of ssh-rsa or ssh-dsa.
266
267
268       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
273
274       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
278
279       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
282
283       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
287       from="pattern-list"
288
289           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
296           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
304
305       command="command"
306
307           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
320
321       environment="NAME=value"
322
323           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
329
330       no-port-forwarding
331
332           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
336
337       no-X11-forwarding
338
339           Forbids X11 forwarding when this key is  used  for  authentication.
340           Any X11 forward requests by the client will return an error.
341
342
343       no-agent-forwarding
344
345           Forbids  authentication  agent forwarding when this key is used for
346           authentication.
347
348
349       no-pty
350
351           Prevents tty allocation (a request to allocate a pty will fail).
352
353
354       permitopen="host:port"
355
356           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
363
364   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
371
372       For the RSA key for protocol version 1, these files consist of the fol‐
373       lowing space-separated fields:
374
375         hostnames  bits  exponent  modulus  comment
376
377
378
379
380       For the public key for protocol version 2, these files consist  of  the
381       following space-separated fields:
382
383         hostnames key-type base64-encoding-key comment
384
385
386
387
388       For protocol version 2, key-type is one of ssh-rsa or ssh-dsa.
389
390
391       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
398
399       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
405
406       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
411
412       Lines starting with a hash mark (#) and empty lines are ignored as com‐
413       ments.
414
415
416       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
424
425       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

ENVIRONMENT VARIABLES

431       sshd  sets the following environment variables for commands executed by
432       ssh users:
433
434       DISPLAY
435
436           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
445
446       HOME
447
448           Set to the path of the user's home directory.
449
450
451       LANG, LC_ALL, LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY,
452       LC_NUMERIC, LC_TIME
453
454           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
458           Following initial key exchange, each of the variables can be  over‐
459           riden in the following sequence:
460
461               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
466               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
473               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
479
480       LOGNAME
481
482           Synonym for USER. Set for compatibility with systems that use  this
483           variable.
484
485
486       MAIL
487
488           Set to point to the user's mailbox.
489
490
491       SSH_AUTH_SOCK
492
493           Indicates the path of a unix-domain socket used to communicate with
494           the agent.
495
496
497       SSH_CONNECTION
498
499           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
503
504       SSH_CLIENT
505
506           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
510
511       SSH_TTY
512
513           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
517
518       TZ
519
520           Indicates  the  present   timezone,   if   TIMEZONE   is   set   in
521           /etc/default/login or if TZ was set when the daemon was started.
522
523
524       HZ
525
526           If set in /etc/default/login, the daemon sets it to the same value.
527
528
529       SHELL
530
531           The user's shell, if ALTSHELL=YES in /etc/default/login.
532
533
534       PATH
535
536           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
539
540       USER
541
542           Set to the name of the user logging in.
543
544
545
546       Additionally, sshd reads $HOME/.ssh/environment and adds lines  of  the
547       format VARNAME=value to the environment.
548

EXAMPLES

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
554       Example 1 authorized_key File Entries
555
556
557       The  following are examples of authorized_key file entries for protocol
558       1:
559
560
561         1024 33 12121...312314325 ylo@foo.bar
562
563         from="*.niksula.hut.fi,!pc.niksula.hut.fi" 1024 35 23...2334 ylo@niksula
564
565         command="dump /home",no-pty,no-port-forwarding 1024 33 23...2323 backup.hut.fi
566
567
568
569       Example 2 authorized_key File Entries for Protocol 2
570
571
572       The following are examples of authorized_key file entries for  protocol
573       2:
574
575
576         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
580
581
582       Example 3 ssh_known_hosts File Entries for Protocol 1
583
584
585       The following are examples of ssh_known_hosts file entries for protocol
586       1:
587
588
589         closenet,closenet.hut.fi,...,130.233.208.41 1024 37 159...93 closenet.hut.fi
590
591
592
593       Example 4 ssh_known_hosts File Entries for Protocol 2
594
595
596       The following are examples of ssh_known_hosts file entries for protocol
597       2:
598
599
600         closenet,closenet.hut.fi,...,130.233.208.41 ssh-rsa AA..8= closenet.hut.fi
601
602
603

EXIT STATUS

605       The following exit values are returned:
606
607       0            Successful completion.
608
609
610       >0           An error occurred.
611
612

FILES

614       /etc/default/login
615
616           Contains  defaults  for several sshd_config parameters, environment
617           variables, and other environmental factors.
618
619           The following parameters affect environment variables (see login(1)
620           and descriptions of these variables, above):
621
622               o      TIMEZONE
623
624               o      HZ
625
626               o      ALTSHELL
627
628               o      PATH
629
630               o      SUPATH
631           The  following  /etc/default/login parameters supply default values
632           for corresponding sshd_config(4) parameters:
633
634               o      CONSOLE (see PermitRootLogin in sshd_config(4))
635
636               o      PASSREQ (see PermitEmptyPasswords in sshd_config(4))
637
638               o      TIMEOUT (see LoginGraceTime in sshd_config(4))
639           The following /etc/default/login parameters:
640
641               o      UMASK
642
643               o      ULIMIT
644           ...set the umask(2) and  file  size  limit  of,  respectively,  the
645           shells and commands spawned by sshd.
646
647           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
652               o      RETRIES
653
654               o      SYSLOG_FAILED_LOGINS
655
656
657       /etc/ssh/sshd_config
658
659           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
663
664       /etc/ssh/ssh_host_key
665       /etc/ssh/ssh_host_dsa_key
666       /etc/ssh/ssh_host_rsa_key
667
668           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
672
673       /etc/ssh/ssh_host_key.pub
674       /etc/ssh/ssh_host_dsa_key.pub
675       /etc/ssh/ssh_host_rsa_key.pub
676
677           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
684
685       /var/run/sshd.pid
686
687           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
694
695       /etc/ssh/ssh_known_hosts and $HOME/.ssh/known_hosts
696
697           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
705
706       /etc/nologin
707
708           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
713
714       $HOME/.ssh/authorized_keys
715
716           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
725
726       $HOME/.rhosts
727
728           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
736
737       $HOME/.shosts
738
739           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
743
744       /etc/hosts.equiv
745
746           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
755           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
761           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
769
770       /etc/ssh/moduli
771
772           A private file.
773
774
775       /etc/ssh/shosts.equiv
776
777           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
781
782       $HOME/.ssh/environment
783
784           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
791
792       $HOME/.ssh/rc
793
794           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
800           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
811           This  file  will probably contain some initialization code followed
812           by something similar to:
813
814             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
827
828           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
833
834       /etc/ssh/sshrc
835
836           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
840

SECURITY

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
850
851       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
857
858       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
864
865       host/bigmachine.eng.example.com
866
867
868       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
871
872       GSS-API authorization is covered in gss_auth_rules(5).
873
874
875       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
879
880       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
886
887       pam_setcred() and pam_open_session()  are  called  when  authentication
888       succeeds and pam_close_session() is called when connections are closed.
889
890
891       pam_open_session()  and  pam_close_session() are also called when SSHv2
892       channels with ptys are opened and closed.
893
894
895       Each SSHv2 userauth type has its own PAM service name:
896
897
898
899
900       ┌─────────────────────────────┬─────────────────────────────┐
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
918
919       For SSHv1, sshd-v1 is always used.
920
921
922       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
930   Setting up Host-based Authentication
931       To establish host-based authentication, you must perform the  following
932       steps:
933
934           o      Configure the client.
935
936           o      Configure the server.
937
938           o      Publish known hosts.
939
940           o      Make   appropriate   entries  in  /etc/ssh/shosts.equiv  and
941                  ~/.shosts.
942
943
944       These steps are expanded in the following paragraphs.
945
946           o      On a client machine, in the system-wide client configuration
947                  file, /etc/ssh/ssh_config, you must have the entry:
948
949                    HostbasedAuthentication yes
950
951                  See ssh_config(4) and ssh-keysign(1M).
952
953           o      On the server, in the system-wide server configuration file,
954                  /etc/ssh/sshd_config, you must have the entry:
955
956                    HostbasedAuthentication yes
957
958                  If per-user .shost files are to be allowed (see last  step),
959                  in the same file, you must have:
960
961                    IgnoreRhosts no
962
963                  See sshd_config(4) for a description of these keywords.
964
965           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
971           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
978                  For the vast majority of network  environments,  .shosts  is
979                  preferred over .rhosts.
980

ATTRIBUTES

982       See attributes(5) for descriptions of the following attributes:
983
984
985
986
987       ┌─────────────────────────────┬─────────────────────────────┐
988       │      ATTRIBUTE TYPE         │      ATTRIBUTE VALUE        │
989       ├─────────────────────────────┼─────────────────────────────┤
990       │Availability                 │SUNWsshdu                    │
991       ├─────────────────────────────┼─────────────────────────────┤
992       │Interface Stability          │Evolving                     │
993       └─────────────────────────────┴─────────────────────────────┘
994
995
996       The interface stability of /etc/ssh/moduli is Private.
997

SEE ALSO

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
1004
1005
1006

NOTES

1008       The sshd service is managed by the service management facility, smf(5),
1009       under the service identifier:
1010
1011         svc:/network/ssh:default
1012
1013
1014
1015
1016       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
1020
1021       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).
1024
1025
1026
1027SunOS 5.11                        17 Mar 2009                         sshd(1M)
Impressum