summaryrefslogtreecommitdiff
path: root/sshd.0
diff options
context:
space:
mode:
authorColin Watson <cjwatson@debian.org>2003-09-01 18:52:37 +0000
committerColin Watson <cjwatson@debian.org>2003-09-01 18:52:37 +0000
commit854156dd39acbde9b4a47ec0fc54a042ea7358e0 (patch)
tree96755f8590acc2146f4b4ef5b5cdba600e5d9353 /sshd.0
parentfad82e8999e790899083f9e22a1841148d746df6 (diff)
parent053db7da5ce09acdf742789d9d1a05e81d4861d0 (diff)
Import OpenSSH 3.6.1p2.
Diffstat (limited to 'sshd.0')
-rw-r--r--sshd.0543
1 files changed, 543 insertions, 0 deletions
diff --git a/sshd.0 b/sshd.0
new file mode 100644
index 000000000..7bed03416
--- /dev/null
+++ b/sshd.0
@@ -0,0 +1,543 @@
1SSHD(8) BSD System ManagerM-bM-^@M-^Ys Manual SSHD(8)
2
3NAME
4 sshd - OpenSSH SSH daemon
5
6SYNOPSIS
7 sshd [-deiqtD46] [-b bits] [-f config_file] [-g login_grace_time]
8 [-h host_key_file] [-k key_gen_time] [-o option] [-p port] [-u len]
9
10DESCRIPTION
11 sshd (SSH Daemon) is the daemon program for ssh(1). Together these pro-
12 grams replace rlogin and rsh, and provide secure encrypted communications
13 between two untrusted hosts over an insecure network. The programs are
14 intended to be as easy to install and use as possible.
15
16 sshd is the daemon that listens for connections from clients. It is nor-
17 mally started at boot from /etc/rc. It forks a new daemon for each
18 incoming connection. The forked daemons handle key exchange, encryption,
19 authentication, command execution, and data exchange. This implementa-
20 tion of sshd supports both SSH protocol version 1 and 2 simultaneously.
21 sshd works as follows:
22
23 SSH protocol version 1
24 Each host has a host-specific RSA key (normally 1024 bits) used to iden-
25 tify the host. Additionally, when the daemon starts, it generates a
26 server RSA key (normally 768 bits). This key is normally regenerated
27 every hour if it has been used, and is never stored on disk.
28
29 Whenever a client connects, the daemon responds with its public host and
30 server keys. The client compares the RSA host key against its own
31 database to verify that it has not changed. The client then generates a
32 256 bit random number. It encrypts this random number using both the
33 host key and the server key, and sends the encrypted number to the
34 server. Both sides then use this random number as a session key which is
35 used to encrypt all further communications in the session. The rest of
36 the session is encrypted using a conventional cipher, currently Blowfish
37 or 3DES, with 3DES being used by default. The client selects the encryp-
38 tion algorithm to use from those offered by the server.
39
40 Next, the server and the client enter an authentication dialog. The
41 client tries to authenticate itself using .rhosts authentication, .rhosts
42 authentication combined with RSA host authentication, RSA challenge-
43 response authentication, or password based authentication.
44
45 Rhosts authentication is normally disabled because it is fundamentally
46 insecure, but can be enabled in the server configuration file if desired.
47 System security is not improved unless rshd, rlogind, and rexecd are dis-
48 abled (thus completely disabling rlogin and rsh into the machine).
49
50 SSH protocol version 2
51 Version 2 works similarly: Each host has a host-specific key (RSA or DSA)
52 used to identify the host. However, when the daemon starts, it does not
53 generate a server key. Forward security is provided through a Diffie-
54 Hellman key agreement. This key agreement results in a shared session
55 key.
56
57 The rest of the session is encrypted using a symmetric cipher, currently
58 128 bit AES, Blowfish, 3DES, CAST128, Arcfour, 192 bit AES, or 256 bit
59 AES. The client selects the encryption algorithm to use from those
60 offered by the server. Additionally, session integrity is provided
61 through a cryptographic message authentication code (hmac-sha1 or hmac-
62 md5).
63
64 Protocol version 2 provides a public key based user (PubkeyAuthentica-
65 tion) or client host (HostbasedAuthentication) authentication method,
66 conventional password authentication and challenge response based meth-
67 ods.
68
69 Command execution and data forwarding
70 If the client successfully authenticates itself, a dialog for preparing
71 the session is entered. At this time the client may request things like
72 allocating a pseudo-tty, forwarding X11 connections, forwarding TCP/IP
73 connections, or forwarding the authentication agent connection over the
74 secure channel.
75
76 Finally, the client either requests a shell or execution of a command.
77 The sides then enter session mode. In this mode, either side may send
78 data at any time, and such data is forwarded to/from the shell or command
79 on the server side, and the user terminal in the client side.
80
81 When the user program terminates and all forwarded X11 and other connec-
82 tions have been closed, the server sends command exit status to the
83 client, and both sides exit.
84
85 sshd can be configured using command-line options or a configuration
86 file. Command-line options override values specified in the configura-
87 tion file.
88
89 sshd rereads its configuration file when it receives a hangup signal,
90 SIGHUP, by executing itself with the name it was started as, i.e.,
91 /usr/sbin/sshd.
92
93 The options are as follows:
94
95 -b bits
96 Specifies the number of bits in the ephemeral protocol version 1
97 server key (default 768).
98
99 -d Debug mode. The server sends verbose debug output to the system
100 log, and does not put itself in the background. The server also
101 will not fork and will only process one connection. This option
102 is only intended for debugging for the server. Multiple -d
103 options increase the debugging level. Maximum is 3.
104
105 -e When this option is specified, sshd will send the output to the
106 standard error instead of the system log.
107
108 -f configuration_file
109 Specifies the name of the configuration file. The default is
110 /etc/ssh/sshd_config. sshd refuses to start if there is no con-
111 figuration file.
112
113 -g login_grace_time
114 Gives the grace time for clients to authenticate themselves
115 (default 120 seconds). If the client fails to authenticate the
116 user within this many seconds, the server disconnects and exits.
117 A value of zero indicates no limit.
118
119 -h host_key_file
120 Specifies a file from which a host key is read. This option must
121 be given if sshd is not run as root (as the normal host key files
122 are normally not readable by anyone but root). The default is
123 /etc/ssh/ssh_host_key for protocol version 1, and
124 /etc/ssh/ssh_host_rsa_key and /etc/ssh/ssh_host_dsa_key for pro-
125 tocol version 2. It is possible to have multiple host key files
126 for the different protocol versions and host key algorithms.
127
128 -i Specifies that sshd is being run from inetd(8). sshd is normally
129 not run from inetd because it needs to generate the server key
130 before it can respond to the client, and this may take tens of
131 seconds. Clients would have to wait too long if the key was
132 regenerated every time. However, with small key sizes (e.g.,
133 512) using sshd from inetd may be feasible.
134
135 -k key_gen_time
136 Specifies how often the ephemeral protocol version 1 server key
137 is regenerated (default 3600 seconds, or one hour). The motiva-
138 tion for regenerating the key fairly often is that the key is not
139 stored anywhere, and after about an hour, it becomes impossible
140 to recover the key for decrypting intercepted communications even
141 if the machine is cracked into or physically seized. A value of
142 zero indicates that the key will never be regenerated.
143
144 -o option
145 Can be used to give options in the format used in the configura-
146 tion file. This is useful for specifying options for which there
147 is no separate command-line flag.
148
149 -p port
150 Specifies the port on which the server listens for connections
151 (default 22). Multiple port options are permitted. Ports speci-
152 fied in the configuration file are ignored when a command-line
153 port is specified.
154
155 -q Quiet mode. Nothing is sent to the system log. Normally the
156 beginning, authentication, and termination of each connection is
157 logged.
158
159 -t Test mode. Only check the validity of the configuration file and
160 sanity of the keys. This is useful for updating sshd reliably as
161 configuration options may change.
162
163 -u len This option is used to specify the size of the field in the utmp
164 structure that holds the remote host name. If the resolved host
165 name is longer than len, the dotted decimal value will be used
166 instead. This allows hosts with very long host names that over-
167 flow this field to still be uniquely identified. Specifying -u0
168 indicates that only dotted decimal addresses should be put into
169 the utmp file. -u0 may also be used to prevent sshd from making
170 DNS requests unless the authentication mechanism or configuration
171 requires it. Authentication mechanisms that may require DNS
172 include RhostsAuthentication, RhostsRSAAuthentication,
173 HostbasedAuthentication and using a from="pattern-list" option in
174 a key file. Configuration options that require DNS include using
175 a USER@HOST pattern in AllowUsers or DenyUsers.
176
177 -D When this option is specified sshd will not detach and does not
178 become a daemon. This allows easy monitoring of sshd.
179
180 -4 Forces sshd to use IPv4 addresses only.
181
182 -6 Forces sshd to use IPv6 addresses only.
183
184CONFIGURATION FILE
185 sshd reads configuration data from /etc/ssh/sshd_config (or the file
186 specified with -f on the command line). The file format and configura-
187 tion options are described in sshd_config(5).
188
189LOGIN PROCESS
190 When a user successfully logs in, sshd does the following:
191
192 1. If the login is on a tty, and no command has been specified,
193 prints last login time and /etc/motd (unless prevented in the
194 configuration file or by $HOME/.hushlogin; see the FILES sec-
195 tion).
196
197 2. If the login is on a tty, records login time.
198
199 3. Checks /etc/nologin; if it exists, prints contents and quits
200 (unless root).
201
202 4. Changes to run with normal user privileges.
203
204 5. Sets up basic environment.
205
206 6. Reads $HOME/.ssh/environment if it exists and users are
207 allowed to change their environment. See the
208 PermitUserEnvironment option in sshd_config(5).
209
210 7. Changes to userM-bM-^@M-^Ys home directory.
211
212 8. If $HOME/.ssh/rc exists, runs it; else if /etc/ssh/sshrc
213 exists, runs it; otherwise runs xauth. The M-bM-^@M-^\rcM-bM-^@M-^] files are
214 given the X11 authentication protocol and cookie in standard
215 input.
216
217 9. Runs userM-bM-^@M-^Ys shell or command.
218
219AUTHORIZED_KEYS FILE FORMAT
220 $HOME/.ssh/authorized_keys is the default file that lists the public keys
221 that are permitted for RSA authentication in protocol version 1 and for
222 public key authentication (PubkeyAuthentication) in protocol version 2.
223 AuthorizedKeysFile may be used to specify an alternative file.
224
225 Each line of the file contains one key (empty lines and lines starting
226 with a M-bM-^@M-^X#M-bM-^@M-^Y are ignored as comments). Each RSA public key consists of the
227 following fields, separated by spaces: options, bits, exponent, modulus,
228 comment. Each protocol version 2 public key consists of: options, key-
229 type, base64 encoded key, comment. The options field is optional; its
230 presence is determined by whether the line starts with a number or not
231 (the options field never starts with a number). The bits, exponent, mod-
232 ulus and comment fields give the RSA key for protocol version 1; the com-
233 ment field is not used for anything (but may be convenient for the user
234 to identify the key). For protocol version 2 the keytype is M-bM-^@M-^\ssh-dssM-bM-^@M-^] or
235 M-bM-^@M-^\ssh-rsaM-bM-^@M-^].
236
237 Note that lines in this file are usually several hundred bytes long
238 (because of the size of the public key encoding). You donM-bM-^@M-^Yt want to type
239 them in; instead, copy the identity.pub, id_dsa.pub or the id_rsa.pub
240 file and edit it.
241
242 sshd enforces a minimum RSA key modulus size for protocol 1 and protocol
243 2 keys of 768 bits.
244
245 The options (if present) consist of comma-separated option specifica-
246 tions. No spaces are permitted, except within double quotes. The fol-
247 lowing option specifications are supported (note that option keywords are
248 case-insensitive):
249
250 from="pattern-list"
251 Specifies that in addition to public key authentication, the
252 canonical name of the remote host must be present in the comma-
253 separated list of patterns (M-bM-^@M-^X*M-bM-^@M-^Y and M-bM-^@M-^XM-bM-^@M-^Y? serve as wildcards).
254 The list may also contain patterns negated by prefixing them with
255 M-bM-^@M-^XM-bM-^@M-^Y!; if the canonical host name matches a negated pattern, the
256 key is not accepted. The purpose of this option is to optionally
257 increase security: public key authentication by itself does not
258 trust the network or name servers or anything (but the key); how-
259 ever, if somebody somehow steals the key, the key permits an
260 intruder to log in from anywhere in the world. This additional
261 option makes using a stolen key more difficult (name servers
262 and/or routers would have to be compromised in addition to just
263 the key).
264
265 command="command"
266 Specifies that the command is executed whenever this key is used
267 for authentication. The command supplied by the user (if any) is
268 ignored. The command is run on a pty if the client requests a
269 pty; otherwise it is run without a tty. If an 8-bit clean chan-
270 nel is required, one must not request a pty or should specify
271 no-pty. A quote may be included in the command by quoting it
272 with a backslash. This option might be useful to restrict cer-
273 tain public keys to perform just a specific operation. An exam-
274 ple might be a key that permits remote backups but nothing else.
275 Note that the client may specify TCP/IP and/or X11 forwarding
276 unless they are explicitly prohibited. Note that this option
277 applies to shell, command or subsystem execution.
278
279 environment="NAME=value"
280 Specifies that the string is to be added to the environment when
281 logging in using this key. Environment variables set this way
282 override other default environment values. Multiple options of
283 this type are permitted. Environment processing is disabled by
284 default and is controlled via the PermitUserEnvironment option.
285 This option is automatically disabled if UseLogin is enabled.
286
287 no-port-forwarding
288 Forbids TCP/IP forwarding when this key is used for authentica-
289 tion. Any port forward requests by the client will return an
290 error. This might be used, e.g., in connection with the command
291 option.
292
293 no-X11-forwarding
294 Forbids X11 forwarding when this key is used for authentication.
295 Any X11 forward requests by the client will return an error.
296
297 no-agent-forwarding
298 Forbids authentication agent forwarding when this key is used for
299 authentication.
300
301 no-pty Prevents tty allocation (a request to allocate a pty will fail).
302
303 permitopen="host:port"
304 Limit local M-bM-^@M-^XM-bM-^@M-^Xssh -LM-bM-^@M-^YM-bM-^@M-^Y port forwarding such that it may only con-
305 nect to the specified host and port. IPv6 addresses can be spec-
306 ified with an alternative syntax: host/port. Multiple permitopen
307 options may be applied separated by commas. No pattern matching
308 is performed on the specified hostnames, they must be literal
309 domains or addresses.
310
311 Examples
312 1024 33 12121...312314325 ylo@foo.bar
313
314 from="*.niksula.hut.fi,!pc.niksula.hut.fi" 1024 35 23...2334 ylo@niksula
315
316 command="dump /home",no-pty,no-port-forwarding 1024 33 23...2323
317 backup.hut.fi
318
319 permitopen="10.2.1.55:80",permitopen="10.2.1.56:25" 1024 33 23...2323
320
321SSH_KNOWN_HOSTS FILE FORMAT
322 The /etc/ssh/ssh_known_hosts and $HOME/.ssh/known_hosts files contain
323 host public keys for all known hosts. The global file should be prepared
324 by the administrator (optional), and the per-user file is maintained
325 automatically: whenever the user connects from an unknown host its key is
326 added to the per-user file.
327
328 Each line in these files contains the following fields: hostnames, bits,
329 exponent, modulus, comment. The fields are separated by spaces.
330
331 Hostnames is a comma-separated list of patterns (M-bM-^@M-^Y*M-bM-^@M-^Y and M-bM-^@M-^Y?M-bM-^@M-^Y act as wild-
332 cards); each pattern in turn is matched against the canonical host name
333 (when authenticating a client) or against the user-supplied name (when
334 authenticating a server). A pattern may also be preceded by M-bM-^@M-^XM-bM-^@M-^Y! to
335 indicate negation: if the host name matches a negated pattern, it is not
336 accepted (by that line) even if it matched another pattern on the line.
337
338 Bits, exponent, and modulus are taken directly from the RSA host key;
339 they can be obtained, e.g., from /etc/ssh/ssh_host_key.pub. The optional
340 comment field continues to the end of the line, and is not used.
341
342 Lines starting with M-bM-^@M-^X#M-bM-^@M-^Y and empty lines are ignored as comments.
343
344 When performing host authentication, authentication is accepted if any
345 matching line has the proper key. It is thus permissible (but not recom-
346 mended) to have several lines or different host keys for the same names.
347 This will inevitably happen when short forms of host names from different
348 domains are put in the file. It is possible that the files contain con-
349 flicting information; authentication is accepted if valid information can
350 be found from either file.
351
352 Note that the lines in these files are typically hundreds of characters
353 long, and you definitely donM-bM-^@M-^Yt want to type in the host keys by hand.
354 Rather, generate them by a script or by taking /etc/ssh/ssh_host_key.pub
355 and adding the host names at the front.
356
357 Examples
358 closenet,...,130.233.208.41 1024 37 159...93 closenet.hut.fi
359 cvs.openbsd.org,199.185.137.3 ssh-rsa AAAA1234.....=
360
361FILES
362 /etc/ssh/sshd_config
363 Contains configuration data for sshd. The file format and con-
364 figuration options are described in sshd_config(5).
365
366 /etc/ssh/ssh_host_key, /etc/ssh/ssh_host_dsa_key,
367 /etc/ssh/ssh_host_rsa_key
368 These three files contain the private parts of the host keys.
369 These files should only be owned by root, readable only by root,
370 and not accessible to others. Note that sshd does not start if
371 this file is group/world-accessible.
372
373 /etc/ssh/ssh_host_key.pub, /etc/ssh/ssh_host_dsa_key.pub,
374 /etc/ssh/ssh_host_rsa_key.pub
375 These three files contain the public parts of the host keys.
376 These files should be world-readable but writable only by root.
377 Their contents should match the respective private parts. These
378 files are not really used for anything; they are provided for the
379 convenience of the user so their contents can be copied to known
380 hosts files. These files are created using ssh-keygen(1).
381
382 /etc/moduli
383 Contains Diffie-Hellman groups used for the "Diffie-Hellman Group
384 Exchange". The file format is described in moduli(5).
385
386 /var/empty
387 chroot(2) directory used by sshd during privilege separation in
388 the pre-authentication phase. The directory should not contain
389 any files and must be owned by root and not group or world-
390 writable.
391
392 /var/run/sshd.pid
393 Contains the process ID of the sshd listening for connections (if
394 there are several daemons running concurrently for different
395 ports, this contains the process ID of the one started last).
396 The content of this file is not sensitive; it can be world-read-
397 able.
398
399 $HOME/.ssh/authorized_keys
400 Lists the public keys (RSA or DSA) that can be used to log into
401 the userM-bM-^@M-^Ys account. This file must be readable by root (which
402 may on some machines imply it being world-readable if the userM-bM-^@M-^Ys
403 home directory resides on an NFS volume). It is recommended that
404 it not be accessible by others. The format of this file is
405 described above. Users will place the contents of their
406 identity.pub, id_dsa.pub and/or id_rsa.pub files into this file,
407 as described in ssh-keygen(1).
408
409 /etc/ssh/ssh_known_hosts and $HOME/.ssh/known_hosts
410 These files are consulted when using rhosts with RSA host authen-
411 tication or protocol version 2 hostbased authentication to check
412 the public key of the host. The key must be listed in one of
413 these files to be accepted. The client uses the same files to
414 verify that it is connecting to the correct remote host. These
415 files should be writable only by root/the owner.
416 /etc/ssh/ssh_known_hosts should be world-readable, and
417 $HOME/.ssh/known_hosts can, but need not be, world-readable.
418
419 /etc/nologin
420 If this file exists, sshd refuses to let anyone except root log
421 in. The contents of the file are displayed to anyone trying to
422 log in, and non-root connections are refused. The file should be
423 world-readable.
424
425 /etc/hosts.allow, /etc/hosts.deny
426 Access controls that should be enforced by tcp-wrappers are
427 defined here. Further details are described in hosts_access(5).
428
429 $HOME/.rhosts
430 This file contains host-username pairs, separated by a space, one
431 per line. The given user on the corresponding host is permitted
432 to log in without a password. The same file is used by rlogind
433 and rshd. The file must be writable only by the user; it is rec-
434 ommended that it not be accessible by others.
435
436 If is also possible to use netgroups in the file. Either host or
437 user name may be of the form +@groupname to specify all hosts or
438 all users in the group.
439
440 $HOME/.shosts
441 For ssh, this file is exactly the same as for .rhosts. However,
442 this file is not used by rlogin and rshd, so using this permits
443 access using SSH only.
444
445 /etc/hosts.equiv
446 This file is used during .rhosts authentication. In the simplest
447 form, this file contains host names, one per line. Users on
448 those hosts are permitted to log in without a password, provided
449 they have the same user name on both machines. The host name may
450 also be followed by a user name; such users are permitted to log
451 in as any user on this machine (except root). Additionally, the
452 syntax M-bM-^@M-^\+@groupM-bM-^@M-^] can be used to specify netgroups. Negated
453 entries start with M-bM-^@M-^X-M-bM-^@M-^Y.
454
455 If the client host/user is successfully matched in this file,
456 login is automatically permitted provided the client and server
457 user names are the same. Additionally, successful RSA host
458 authentication is normally required. This file must be writable
459 only by root; it is recommended that it be world-readable.
460
461 Warning: It is almost never a good idea to use user names in
462 hosts.equiv. Beware that it really means that the named user(s)
463 can log in as anybody, which includes bin, daemon, adm, and other
464 accounts that own critical binaries and directories. Using a
465 user name practically grants the user root access. The only
466 valid use for user names that I can think of is in negative
467 entries.
468
469 Note that this warning also applies to rsh/rlogin.
470
471 /etc/shosts.equiv
472 This is processed exactly as /etc/hosts.equiv. However, this
473 file may be useful in environments that want to run both
474 rsh/rlogin and ssh.
475
476 $HOME/.ssh/environment
477 This file is read into the environment at login (if it exists).
478 It can only contain empty lines, comment lines (that start with
479 M-bM-^@M-^X#M-bM-^@M-^Y), and assignment lines of the form name=value. The file
480 should be writable only by the user; it need not be readable by
481 anyone else. Environment processing is disabled by default and
482 is controlled via the PermitUserEnvironment option.
483
484 $HOME/.ssh/rc
485 If this file exists, it is run with /bin/sh after reading the
486 environment files but before starting the userM-bM-^@M-^Ys shell or com-
487 mand. It must not produce any output on stdout; stderr must be
488 used instead. If X11 forwarding is in use, it will receive the
489 "proto cookie" pair in its standard input (and DISPLAY in its
490 environment). The script must call xauth(1) because sshd will
491 not run xauth automatically to add X11 cookies.
492
493 The primary purpose of this file is to run any initialization
494 routines which may be needed before the userM-bM-^@M-^Ys home directory
495 becomes accessible; AFS is a particular example of such an envi-
496 ronment.
497
498 This file will probably contain some initialization code followed
499 by something similar to:
500
501 if read proto cookie && [ -n "$DISPLAY" ]; then
502 if [ M-bM-^@M-^Xecho $DISPLAY | cut -c1-10M-bM-^@M-^X = M-bM-^@M-^Ylocalhost:M-bM-^@M-^Y ]; then
503 # X11UseLocalhost=yes
504 echo add unix:M-bM-^@M-^Xecho $DISPLAY |
505 cut -c11-M-bM-^@M-^X $proto $cookie
506 else
507 # X11UseLocalhost=no
508 echo add $DISPLAY $proto $cookie
509 fi | xauth -q -
510 fi
511
512 If this file does not exist, /etc/ssh/sshrc is run, and if that
513 does not exist either, xauth is used to add the cookie.
514
515 This file should be writable only by the user, and need not be
516 readable by anyone else.
517
518 /etc/ssh/sshrc
519 Like $HOME/.ssh/rc. This can be used to specify machine-specific
520 login-time initializations globally. This file should be
521 writable only by root, and should be world-readable.
522
523AUTHORS
524 OpenSSH is a derivative of the original and free ssh 1.2.12 release by
525 Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo
526 de Raadt and Dug Song removed many bugs, re-added newer features and cre-
527 ated OpenSSH. Markus Friedl contributed the support for SSH protocol
528 versions 1.5 and 2.0. Niels Provos and Markus Friedl contributed support
529 for privilege separation.
530
531SEE ALSO
532 scp(1), sftp(1), ssh(1), ssh-add(1), ssh-agent(1), ssh-keygen(1),
533 login.conf(5), moduli(5), sshd_config(5), sftp-server(8)
534
535 T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, and S. Lehtinen, SSH
536 Protocol Architecture, draft-ietf-secsh-architecture-12.txt, January
537 2002, work in progress material.
538
539 M. Friedl, N. Provos, and W. A. Simpson, Diffie-Hellman Group Exchange
540 for the SSH Transport Layer Protocol, draft-ietf-secsh-dh-group-
541 exchange-02.txt, January 2002, work in progress material.
542
543BSD September 25, 1999 BSD