summaryrefslogtreecommitdiff
path: root/other/openssh-2.1.1p4/sshd.0
diff options
context:
space:
mode:
Diffstat (limited to 'other/openssh-2.1.1p4/sshd.0')
-rw-r--r--other/openssh-2.1.1p4/sshd.0732
1 files changed, 0 insertions, 732 deletions
diff --git a/other/openssh-2.1.1p4/sshd.0 b/other/openssh-2.1.1p4/sshd.0
deleted file mode 100644
index 639cdc6..0000000
--- a/other/openssh-2.1.1p4/sshd.0
+++ /dev/null
@@ -1,732 +0,0 @@
1
2SSHD(8) System Manager's Manual SSHD(8)
3
4NAME
5 sshd - secure shell daemon
6
7SYNOPSIS
8 sshd [-diqQ46] [-b bits] [-f config_file] [-g login_grace_time] [-h
9 host_key_file] [-k key_gen_time] [-p port] [-V client_protocol_id]
10
11DESCRIPTION
12 sshd (Secure Shell Daemon) is the daemon program for ssh(1). Together
13 these programs replace rlogin and rsh, and provide secure encrypted com-
14 munications between two untrusted hosts over an insecure network. The
15 programs are intended to be as easy to install and use as possible.
16
17 sshd is the daemon that listens for connections from clients. It is nor-
18 mally started at boot from /etc/rc. It forks a new daemon for each incom-
19 ing connection. The forked daemons handle key exchange, encryption, au-
20 thentication, command execution, and data exchange. This implementation
21 of sshd supports both SSH protocol version 1 and 2 simultaneously. sshd
22 works as follows.
23
24 SSH protocol version 1
25
26 Each host has a host-specific RSA key (normally 1024 bits) used to iden-
27 tify the host. Additionally, when the daemon starts, it generates a
28 server RSA key (normally 768 bits). This key is normally regenerated ev-
29 ery hour if it has been used, and is never stored on disk.
30
31 Whenever a client connects the daemon responds with its public host and
32 server keys. The client compares the RSA host key against its own
33 database to verify that it has not changed. The client then generates a
34 256 bit random number. It encrypts this random number using both the
35 host key and the server key, and sends the encrypted number to the serv-
36 er. Both sides then use this random number as a session key which is
37 used to encrypt all further communications in the session. The rest of
38 the session is encrypted using a conventional cipher, currently Blowfish
39 or 3DES, with 3DES being used by default. The client selects the encryp-
40 tion algorithm to use from those offered by the server.
41
42 Next, the server and the client enter an authentication dialog. The
43 client tries to authenticate itself using .rhosts authentication, .rhosts
44 authentication combined with RSA host authentication, RSA challenge-re-
45 sponse authentication, or password based authentication.
46
47 Rhosts authentication is normally disabled because it is fundamentally
48 insecure, but can be enabled in the server configuration file if desired.
49 System security is not improved unless rshd(8), rlogind(8), rexecd(8),
50 and rexd(8) are disabled (thus completely disabling rlogin(1) and rsh(1)
51 into the machine).
52
53 SSH protocol version 2
54
55 Version 2 works similar: Each host has a host-specific DSA key used to
56 identify the host. However, when the daemon starts, it does not generate
57 a server key. Forward security is provided through a Diffie-Hellman key
58 agreement. This key agreement results in a shared session key. The rest
59 of the session is encrypted using a symmetric cipher, currently Blowfish,
60 3DES or CAST128 in CBC mode or Arcfour. The client selects the encryp-
61 tion algorithm to use from those offered by the server. Additionally,
62 session integrity is provided through a cryptographic message authentica-
63 tion code (hmac-sha1 or hmac-md5).
64
65
66 Protocol version 2 provides a public key based user authentication method
67 (DSAAuthentication) and conventional password authentication.
68
69 Command execution and data forwarding
70
71 If the client successfully authenticates itself, a dialog for preparing
72 the session is entered. At this time the client may request things like
73 allocating a pseudo-tty, forwarding X11 connections, forwarding TCP/IP
74 connections, or forwarding the authentication agent connection over the
75 secure channel.
76
77 Finally, the client either requests a shell or execution of a command.
78 The sides then enter session mode. In this mode, either side may send
79 data at any time, and such data is forwarded to/from the shell or command
80 on the server side, and the user terminal in the client side.
81
82 When the user program terminates and all forwarded X11 and other connec-
83 tions have been closed, the server sends command exit status to the
84 client, and both sides exit.
85
86 sshd can be configured using command-line options or a configuration
87 file. Command-line options override values specified in the configura-
88 tion file.
89
90 sshd rereads its configuration file when it receives a hangup signal,
91 SIGHUP.
92
93 The options are as follows:
94
95 -b bits
96 Specifies the number of bits in the server key (default 768).
97
98 -d Debug mode. The server sends verbose debug output to the system
99 log, and does not put itself in the background. The server also
100 will not fork and will only process one connection. This option
101 is only intended for debugging for the server.
102
103 -f configuration_file
104 Specifies the name of the configuration file. The default is
105 /etc/sshd_config. sshd refuses to start if there is no configura-
106 tion file.
107
108 -g login_grace_time
109 Gives the grace time for clients to authenticate themselves (de-
110 fault 300 seconds). If the client fails to authenticate the user
111 within this many seconds, the server disconnects and exits. A
112 value of zero indicates no limit.
113
114 -h host_key_file
115 Specifies the file from which the RSA host key is read (default
116 /etc/ssh_host_key). This option must be given if sshd is not run
117 as root (as the normal host file is normally not readable by any-
118 one but root).
119
120 -i Specifies that sshd is being run from inetd. sshd is normally
121 not run from inetd because it needs to generate the server key
122 before it can respond to the client, and this may take tens of
123 seconds. Clients would have to wait too long if the key was re-
124 generated every time. However, with small key sizes (e.g., 512)
125 using sshd from inetd may be feasible.
126
127 -k key_gen_time
128 Specifies how often the server key is regenerated (default 3600
129 seconds, or one hour). The motivation for regenerating the key
130 fairly often is that the key is not stored anywhere, and after
131 about an hour, it becomes impossible to recover the key for de-
132 crypting intercepted communications even if the machine is
133 cracked into or physically seized. A value of zero indicates
134 that the key will never be regenerated.
135
136 -p port
137 Specifies the port on which the server listens for connections
138 (default 22).
139
140 -q Quiet mode. Nothing is sent to the system log. Normally the be-
141 ginning, authentication, and termination of each connection is
142 logged.
143
144 -Q Do not print an error message if RSA support is missing.
145
146 -V client_protocol_id
147 SSH2 compatibility mode. When this option is specified sshd as-
148 sumes the client has sent the supplied version string and skips
149 the Protocol Version Identification Exchange.
150
151 -4 Forces sshd to use IPv4 addresses only.
152
153 -6 Forces sshd to use IPv6 addresses only.
154
155CONFIGURATION FILE
156 sshd reads configuration data from /etc/sshd_config (or the file speci-
157 fied with -f on the command line). The file contains keyword-value
158 pairs, one per line. Lines starting with `#' and empty lines are inter-
159 preted as comments.
160
161 The following keywords are possible.
162
163 AFSTokenPassing
164 Specifies whether an AFS token may be forwarded to the server.
165 Default is ``yes''.
166
167 AllowGroups
168 This keyword can be followed by a number of group names, separat-
169 ed by spaces. If specified, login is allowed only for users
170 whose primary group matches one of the patterns. `*' and `?' can
171 be used as wildcards in the patterns. Only group names are
172 valid, a numerical group ID isn't recognized. By default login
173 is allowed regardless of the primary group.
174
175 AllowUsers
176 This keyword can be followed by a number of user names, separated
177 by spaces. If specified, login is allowed only for users names
178 that match one of the patterns. `*' and `?' can be used as wild-
179 cards in the patterns. Only user names are valid, a numerical
180 user ID isn't recognized. By default login is allowed regardless
181 of the user name.
182
183 Ciphers
184 Specifies the ciphers allowed for protocol version 2. Multiple
185 ciphers must be comma-separated. The default is ``3des-
186 cbc,blowfish-cbc,arcfour,cast128-cbc''.
187
188 CheckMail
189 Specifies whether sshd should check for new mail for interactive
190 logins. The default is ``no''.
191
192 DenyGroups
193 This keyword can be followed by a number of group names, separat-
194 ed by spaces. Users whose primary group matches one of the pat-
195 terns aren't allowed to log in. `*' and `?' can be used as wild-
196 cards in the patterns. Only group names are valid, a numerical
197 group ID isn't recognized. By default login is allowed regard-
198 less of the primary group.
199
200 DenyUsers
201 This keyword can be followed by a number of user names, separated
202 by spaces. Login is disallowed for user names that match one of
203 the patterns. `*' and `?' can be used as wildcards in the pat-
204 terns. Only user names are valid, a numerical user ID isn't rec-
205 ognized. By default login is allowed regardless of the user
206 name.
207
208 DSAAuthentication
209 Specifies whether DSA authentication is allowed. The default is
210 ``yes''. Note that this option applies to protocol version 2 on-
211 ly.
212
213 GatewayPorts
214 Specifies whether remote hosts are allowed to connect to ports
215 forwarded for the client. The argument must be ``yes'' or
216 ``no''. The default is ``no''.
217
218 HostDsaKey
219 Specifies the file containing the private DSA host key (default
220 /etc/ssh_host_dsa_key) used by SSH protocol 2.0. Note that sshd
221 disables protocol 2.0 if this file is group/world-accessible.
222
223 HostKey
224 Specifies the file containing the private RSA host key (default
225 /etc/ssh_host_key) used by SSH protocols 1.3 and 1.5. Note that
226 sshd disables protocols 1.3 and 1.5 if this file is group/world-
227 accessible.
228
229 IgnoreRhosts
230 Specifies that .rhosts and .shosts files will not be used in au-
231 thentication. /etc/hosts.equiv and /etc/shosts.equiv are still
232 used. The default is ``yes''.
233
234 IgnoreUserKnownHosts
235 Specifies whether sshd should ignore the user's
236 $HOME/.ssh/known_hosts during RhostsRSAAuthentication. The de-
237 fault is ``no''.
238
239 KeepAlive
240 Specifies whether the system should send keepalive messages to
241 the other side. If they are sent, death of the connection or
242 crash of one of the machines will be properly noticed. However,
243 this means that connections will die if the route is down tem-
244 porarily, and some people find it annoying. On the other hand,
245 if keepalives are not sent, sessions may hang indefinitely on the
246 server, leaving ``ghost'' users and consuming server resources.
247
248 The default is ``yes'' (to send keepalives), and the server will
249 notice if the network goes down or the client host reboots. This
250 avoids infinitely hanging sessions.
251
252 To disable keepalives, the value should be set to ``no'' in both
253 the server and the client configuration files.
254
255 KerberosAuthentication
256 Specifies whether Kerberos authentication is allowed. This can
257 be in the form of a Kerberos ticket, or if PasswordAuthentication
258 is yes, the password provided by the user will be validated
259 through the Kerberos KDC. Default is ``yes''.
260
261 KerberosOrLocalPasswd
262 If set then if password authentication through Kerberos fails
263 then the password will be validated via any additional local
264
265 mechanism such as /etc/passwd or SecurID. Default is ``yes''.
266
267 KerberosTgtPassing
268 Specifies whether a Kerberos TGT may be forwarded to the server.
269 Default is ``no'', as this only works when the Kerberos KDC is
270 actually an AFS kaserver.
271
272 KerberosTicketCleanup
273 Specifies whether to automatically destroy the user's ticket
274 cache file on logout. Default is ``yes''.
275
276 KeyRegenerationInterval
277 The server key is automatically regenerated after this many sec-
278 onds (if it has been used). The purpose of regeneration is to
279 prevent decrypting captured sessions by later breaking into the
280 machine and stealing the keys. The key is never stored anywhere.
281 If the value is 0, the key is never regenerated. The default is
282 3600 (seconds).
283
284 ListenAddress
285 Specifies what local address sshd should listen on. The default
286 is to listen to all local addresses. Multiple options of this
287 type are permitted. Additionally, the Ports options must precede
288 this option.
289
290 LoginGraceTime
291 The server disconnects after this time if the user has not suc-
292 cessfully logged in. If the value is 0, there is no time limit.
293 The default is 600 (seconds).
294
295 LogLevel
296 Gives the verbosity level that is used when logging messages from
297 sshd. The possible values are: QUIET, FATAL, ERROR, INFO, VERBOSE
298 and DEBUG. The default is INFO. Logging with level DEBUG vio-
299 lates the privacy of users and is not recommended.
300
301 MaxStartups
302 Specifies the maximum number of concurrent unauthenticated con-
303 nections to the sshd daemon. Additional connections will be
304 dropped until authentication succeeds or the LoginGraceTime ex-
305 pires for a connection. The default is 10.
306
307 PasswordAuthentication
308 Specifies whether password authentication is allowed. The de-
309 fault is ``yes''. Note that this option applies to both protocol
310 version 1 and 2.
311
312 PermitEmptyPasswords
313 When password authentication is allowed, it specifies whether the
314 server allows login to accounts with empty password strings. The
315 default is ``no''.
316
317 PermitRootLogin
318 Specifies whether the root can log in using ssh(1). The argument
319 must be ``yes'', ``without-password'' or ``no''. The default is
320 ``yes''. If this options is set to ``without-password'' only
321 password authentication is disabled for root.
322
323 Root login with RSA authentication when the command option has
324 been specified will be allowed regardless of the value of this
325 setting (which may be useful for taking remote backups even if
326 root login is normally not allowed).
327
328 PidFile
329 Specifies the file that contains the process identifier of the
330
331 sshd daemon. The default is /var/run/sshd.pid.
332
333 Port Specifies the port number that sshd listens on. The default is
334 22. Multiple options of this type are permitted.
335
336 PrintMotd
337 Specifies whether sshd should print /etc/motd when a user logs in
338 interactively. (On some systems it is also printed by the shell,
339 /etc/profile, or equivalent.) The default is ``yes''.
340
341 Protocol
342 Specifies the protocol versions sshd should support. The possi-
343 ble values are ``1'' and ``2''. Multiple versions must be comma-
344 separated. The default is ``1''.
345
346 RandomSeed
347 Obsolete. Random number generation uses other techniques.
348
349 RhostsAuthentication
350 Specifies whether authentication using rhosts or /etc/hosts.equiv
351 files is sufficient. Normally, this method should not be permit-
352 ted because it is insecure. RhostsRSAAuthentication should be
353 used instead, because it performs RSA-based host authentication
354 in addition to normal rhosts or /etc/hosts.equiv authentication.
355 The default is ``no''.
356
357 RhostsRSAAuthentication
358 Specifies whether rhosts or /etc/hosts.equiv authentication to-
359 gether with successful RSA host authentication is allowed. The
360 default is ``no''.
361
362 RSAAuthentication
363 Specifies whether pure RSA authentication is allowed. The de-
364 fault is ``yes''. Note that this option applies to protocol ver-
365 sion 1 only.
366
367 ServerKeyBits
368 Defines the number of bits in the server key. The minimum value
369 is 512, and the default is 768.
370
371 SkeyAuthentication
372 Specifies whether skey(1) authentication is allowed. The default
373 is ``yes''. Note that s/key authentication is enabled only if
374 PasswordAuthentication is allowed, too.
375
376 StrictModes
377 Specifies whether sshd should check file modes and ownership of
378 the user's files and home directory before accepting login. This
379 is normally desirable because novices sometimes accidentally
380 leave their directory or files world-writable. The default is
381 ``yes''.
382
383 Subsystem
384 Configures an external subsystem (e.g. file transfer daemon).
385 Arguments should be a subsystem name and a command to execute up-
386 on subsystem request. By default no subsystems are defined.
387 Note that this option applies to protocol version 2 only.
388
389 SyslogFacility
390 Gives the facility code that is used when logging messages from
391 sshd. The possible values are: DAEMON, USER, AUTH, LOCAL0, LO-
392 CAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7. The de-
393 fault is AUTH.
394
395 UseLogin
396 Specifies whether login(1) is used for interactive login ses-
397 sions. Note that login(1) is not never for remote command execu-
398 tion. The default is ``no''.
399
400 X11DisplayOffset
401 Specifies the first display number available for sshd's X11 for-
402 warding. This prevents sshd from interfering with real X11
403 servers. The default is 10.
404
405 X11Forwarding
406 Specifies whether X11 forwarding is permitted. The default is
407 ``no''. Note that disabling X11 forwarding does not improve secu-
408 rity in any way, as users can always install their own for-
409 warders.
410
411 XAuthLocation
412 Specifies the location of the xauth(1) program. The default is
413 /usr/X11R6/bin/xauth.
414
415LOGIN PROCESS
416 When a user successfully logs in, sshd does the following:
417
418 1. If the login is on a tty, and no command has been specified,
419 prints last login time and /etc/motd (unless prevented in the
420 configuration file or by $HOME/.hushlogin; see the FILES sec-
421 tion).
422
423 2. If the login is on a tty, records login time.
424
425 3. Checks /etc/nologin; if it exists, prints contents and quits
426 (unless root).
427
428 4. Changes to run with normal user privileges.
429
430 5. Sets up basic environment.
431
432 6. Reads $HOME/.ssh/environment if it exists.
433
434 7. Changes to user's home directory.
435
436 8. If $HOME/.ssh/rc exists, runs it; else if /etc/sshrc exists,
437 runs it; otherwise runs xauth. The ``rc'' files are given the
438 X11 authentication protocol and cookie in standard input.
439
440 9. Runs user's shell or command.
441
442AUTHORIZED_KEYS FILE FORMAT
443 The $HOME/.ssh/authorized_keys file lists the RSA keys that are permitted
444 for RSA authentication in SSH protocols 1.3 and 1.5 Similarly, the
445 $HOME/.ssh/authorized_keys2 file lists the DSA keys that are permitted
446 for DSA authentication in SSH protocol 2.0. Each line of the file con-
447 tains one key (empty lines and lines starting with a `#' are ignored as
448 comments). Each line consists of the following fields, separated by
449 spaces: options, bits, exponent, modulus, comment. The options field is
450 optional; its presence is determined by whether the line starts with a
451 number or not (the option field never starts with a number). The bits,
452 exponent, modulus and comment fields give the RSA key; the comment field
453 is not used for anything (but may be convenient for the user to identify
454 the key).
455
456 Note that lines in this file are usually several hundred bytes long (be-
457 cause of the size of the RSA key modulus). You don't want to type them
458 in; instead, copy the identity.pub file and edit it.
459
460 The options (if present) consists of comma-separated option specifica-
461 tions. No spaces are permitted, except within double quotes. The fol-
462
463 lowing option specifications are supported:
464
465 from="pattern-list"
466 Specifies that in addition to RSA authentication, the canonical
467 name of the remote host must be present in the comma-separated
468 list of patterns (`*' and `?' serve as wildcards). The list may
469 also contain patterns negated by prefixing them with `!'; if the
470 canonical host name matches a negated pattern, the key is not ac-
471 cepted. The purpose of this option is to optionally increase se-
472 curity: RSA authentication by itself does not trust the network
473 or name servers or anything (but the key); however, if somebody
474 somehow steals the key, the key permits an intruder to log in
475 from anywhere in the world. This additional option makes using a
476 stolen key more difficult (name servers and/or routers would have
477 to be compromised in addition to just the key).
478
479 command="command"
480 Specifies that the command is executed whenever this key is used
481 for authentication. The command supplied by the user (if any) is
482 ignored. The command is run on a pty if the connection requests
483 a pty; otherwise it is run without a tty. A quote may be includ-
484 ed in the command by quoting it with a backslash. This option
485 might be useful to restrict certain RSA keys to perform just a
486 specific operation. An example might be a key that permits re-
487 mote backups but nothing else. Note that the client may specify
488 TCP/IP and/or X11 forwarding unless they are explicitly prohibit-
489 ed.
490
491 environment="NAME=value"
492 Specifies that the string is to be added to the environment when
493 logging in using this key. Environment variables set this way
494 override other default environment values. Multiple options of
495 this type are permitted.
496
497 no-port-forwarding
498 Forbids TCP/IP forwarding when this key is used for authentica-
499 tion. Any port forward requests by the client will return an er-
500 ror. This might be used, e.g., in connection with the command
501 option.
502
503 no-X11-forwarding
504 Forbids X11 forwarding when this key is used for authentication.
505 Any X11 forward requests by the client will return an error.
506
507 no-agent-forwarding
508 Forbids authentication agent forwarding when this key is used for
509 authentication.
510
511 no-pty Prevents tty allocation (a request to allocate a pty will fail).
512
513 Examples
514 1024 33 12121...312314325 ylo@foo.bar
515
516 from="*.niksula.hut.fi,!pc.niksula.hut.fi" 1024 35 23...2334 ylo@niksula
517
518 command="dump /home",no-pty,no-port-forwarding 1024 33 23...2323 back-
519 up.hut.fi
520
521SSH_KNOWN_HOSTS FILE FORMAT
522 The /etc/ssh_known_hosts, /etc/ssh_known_hosts2, $HOME/.ssh/known_hosts,
523 and $HOME/.ssh/known_hosts2 files contain host public keys for all known
524 hosts. The global file should be prepared by the administrator (option-
525 al), and the per-user file is maintained automatically: whenever the user
526 connects an unknown host its key is added to the per-user file.
527
528
529 Each line in these files contains the following fields: hostnames, bits,
530 exponent, modulus, comment. The fields are separated by spaces.
531
532 Hostnames is a comma-separated list of patterns ('*' and '?' act as wild-
533 cards); each pattern in turn is matched against the canonical host name
534 (when authenticating a client) or against the user-supplied name (when
535 authenticating a server). A pattern may also be preceded by `!' to indi-
536 cate negation: if the host name matches a negated pattern, it is not ac-
537 cepted (by that line) even if it matched another pattern on the line.
538
539 Bits, exponent, and modulus are taken directly from the RSA host key;
540 they can be obtained, e.g., from /etc/ssh_host_key.pub. The optional com-
541 ment field continues to the end of the line, and is not used.
542
543 Lines starting with `#' and empty lines are ignored as comments.
544
545 When performing host authentication, authentication is accepted if any
546 matching line has the proper key. It is thus permissible (but not recom-
547 mended) to have several lines or different host keys for the same names.
548 This will inevitably happen when short forms of host names from different
549 domains are put in the file. It is possible that the files contain con-
550 flicting information; authentication is accepted if valid information can
551 be found from either file.
552
553 Note that the lines in these files are typically hundreds of characters
554 long, and you definitely don't want to type in the host keys by hand.
555 Rather, generate them by a script or by taking /etc/ssh_host_key.pub and
556 adding the host names at the front.
557
558 Examples
559 closenet,closenet.hut.fi,...,130.233.208.41 1024 37 159...93
560 closenet.hut.fi
561
562FILES
563 /etc/sshd_config
564 Contains configuration data for sshd. This file should be
565 writable by root only, but it is recommended (though not neces-
566 sary) that it be world-readable.
567
568 /etc/ssh_host_key
569 Contains the private part of the host key. This file should only
570 be owned by root, readable only by root, and not accessible to
571 others. Note that sshd does not start if this file is
572 group/world-accessible.
573
574 /etc/ssh_host_key.pub
575 Contains the public part of the host key. This file should be
576 world-readable but writable only by root. Its contents should
577 match the private part. This file is not really used for any-
578 thing; it is only provided for the convenience of the user so its
579 contents can be copied to known hosts files. These two files are
580 created using ssh-keygen(1).
581
582 /var/run/sshd.pid
583 Contains the process ID of the sshd listening for connections (if
584 there are several daemons running concurrently for different
585 ports, this contains the pid of the one started last). The con-
586 tents of this file are not sensitive; it can be world-readable.
587
588 $HOME/.ssh/authorized_keys
589 Lists the RSA keys that can be used to log into the user's ac-
590 count. This file must be readable by root (which may on some ma-
591 chines imply it being world-readable if the user's home directory
592 resides on an NFS volume). It is recommended that it not be ac-
593 cessible by others. The format of this file is described above.
594 Users will place the contents of their identity.pub files into
595 this file, as described in ssh-keygen(1).
596
597 $HOME/.ssh/authorized_keys2
598 Lists the DSA keys that can be used to log into the user's ac-
599 count. This file must be readable by root (which may on some ma-
600 chines imply it being world-readable if the user's home directory
601 resides on an NFS volume). It is recommended that it not be ac-
602 cessible by others. The format of this file is described above.
603 Users will place the contents of their id_dsa.pub files into this
604 file, as described in ssh-keygen(1).
605
606 /etc/ssh_known_hosts and $HOME/.ssh/known_hosts
607 These files are consulted when using rhosts with RSA host authen-
608 tication to check the public key of the host. The key must be
609 listed in one of these files to be accepted. The client uses the
610 same files to verify that the remote host is the one we intended
611 to connect. These files should be writable only by root/the own-
612 er. /etc/ssh_known_hosts should be world-readable, and
613 $HOME/.ssh/known_hosts can but need not be world-readable.
614
615 /etc/nologin
616 If this file exists, sshd refuses to let anyone except root log
617 in. The contents of the file are displayed to anyone trying to
618 log in, and non-root connections are refused. The file should be
619 world-readable.
620
621 /etc/hosts.allow, /etc/hosts.deny
622 If compiled with LIBWRAP support, tcp-wrappers access controls
623 may be defined here as described in hosts_access(5).
624
625 $HOME/.rhosts
626 This file contains host-username pairs, separated by a space, one
627 per line. The given user on the corresponding host is permitted
628 to log in without password. The same file is used by rlogind and
629 rshd. The file must be writable only by the user; it is recom-
630 mended that it not be accessible by others.
631
632 If is also possible to use netgroups in the file. Either host or
633 user name may be of the form +@groupname to specify all hosts or
634 all users in the group.
635
636 $HOME/.shosts
637 For ssh, this file is exactly the same as for .rhosts. However,
638 this file is not used by rlogin and rshd, so using this permits
639 access using SSH only. /etc/hosts.equiv This file is used during
640 .rhosts authentication. In the simplest form, this file contains
641 host names, one per line. Users on those hosts are permitted to
642 log in without a password, provided they have the same user name
643 on both machines. The host name may also be followed by a user
644 name; such users are permitted to log in as any user on this ma-
645 chine (except root). Additionally, the syntax ``+@group'' can be
646 used to specify netgroups. Negated entries start with `-'.
647
648 If the client host/user is successfully matched in this file, lo-
649 gin is automatically permitted provided the client and server us-
650 er names are the same. Additionally, successful RSA host authen-
651 tication is normally required. This file must be writable only
652 by root; it is recommended that it be world-readable.
653
654 Warning: It is almost never a good idea to use user names in
655 hosts.equiv. Beware that it really means that the named user(s)
656 can log in as anybody, which includes bin, daemon, adm, and other
657 accounts that own critical binaries and directories. Using a us-
658 er name practically grants the user root access. The only valid
659 use for user names that I can think of is in negative entries.
660
661 Note that this warning also applies to rsh/rlogin.
662
663 /etc/shosts.equiv
664 This is processed exactly as /etc/hosts.equiv. However, this file
665 may be useful in environments that want to run both rsh/rlogin
666 and ssh.
667
668 $HOME/.ssh/environment
669 This file is read into the environment at login (if it exists).
670 It can only contain empty lines, comment lines (that start with
671 `#'), and assignment lines of the form name=value. The file
672 should be writable only by the user; it need not be readable by
673 anyone else.
674
675 $HOME/.ssh/rc
676 If this file exists, it is run with /bin/sh after reading the en-
677 vironment files but before starting the user's shell or command.
678 If X11 spoofing is in use, this will receive the "proto cookie"
679 pair in standard input (and DISPLAY in environment). This must
680 call xauth(1) in that case.
681
682 The primary purpose of this file is to run any initialization
683 routines which may be needed before the user's home directory be-
684 comes accessible; AFS is a particular example of such an environ-
685 ment.
686
687 This file will probably contain some initialization code followed
688 by something similar to: "if read proto cookie; then echo add
689 $DISPLAY $proto $cookie | xauth -q -; fi".
690
691 If this file does not exist, /etc/sshrc is run, and if that does
692 not exist either, xauth is used to store the cookie.
693
694 This file should be writable only by the user, and need not be
695 readable by anyone else.
696
697 /etc/sshrc
698 Like $HOME/.ssh/rc. This can be used to specify machine-specific
699 login-time initializations globally. This file should be
700 writable only by root, and should be world-readable.
701
702AUTHOR
703 OpenSSH is a derivative of the original (free) ssh 1.2.12 release by Tatu
704 Ylonen, but with bugs removed and newer features re-added. Rapidly after
705 the 1.2.12 release, newer versions of the original ssh bore successively
706 more restrictive licenses, and thus demand for a free version was born.
707
708 This version of OpenSSH
709
710 o has all components of a restrictive nature (i.e., patents) directly
711 removed from the source code; any licensed or patented components are
712 chosen from external libraries.
713
714 o has been updated to support SSH protocol 1.5 and 2, making it compat-
715 ible with all other SSH clients and servers.
716
717 o contains added support for kerberos(8) authentication and ticket
718 passing.
719
720 o supports one-time password authentication with skey(1).
721
722 OpenSSH has been created by Aaron Campbell, Bob Beck, Markus Friedl,
723 Niels Provos, Theo de Raadt, and Dug Song.
724
725
726 The support for SSH protocol 2 was written by Markus Friedl.
727
728SEE ALSO
729 scp(1), ssh(1), ssh-add(1), ssh-agent(1), ssh-keygen(1), rlogin(1),
730 rsh(1)
731
732BSD Experimental September 25, 1999 12