1AMANDA-AUTH(7) Miscellanea AMANDA-AUTH(7)
2
6 amanda-auth - Communication/Authentication methods between Amanda
7 server and client
8
10 Amanda offers 8 methods of communication between Amanda server
11 (sometimes also called the tape server) and clients, each with its own
12 authentication method. The desired communication method is specified by
13 the auth parameter in the amanda.conf file (amanda.conf(5)) commonly as
14 a dumptype. Valid values to the auth parameter are bsd, bsdudp, bsdtcp,
15 krb5, local, rsh, and ssh. The authentication and communication method
16 is used during the backup process amdump (amdump(8)) as well as the
17 recovery process amrecover (amrecover(8)).
18
20 The communication method and thus type of authentication that will be
21 used by the Amanda server is specified by the auth parameter in the
22 dumptype for each disklist entry (DLE). The auth parameter thus may be
23 easily and globally specified in the "global" dumptype. If auth is not
24 specified, the bsdtcp communication method is used. See amanda.conf(5)
25 for more information on Amanda configuration and dumptypes, and
26 disklist(5) for more information on disklists.
27 On the client side, the Amanda daemon amandad validates the connection
29 depending on the value of the auth argument passed to it (see
30 Amanda(8)). Also, when it comes to recovery, the auth parameter can be
31 specified in the amanda-client.conf(5) file to specify the
32 communication method to be used by the client to the server.
33 When Amanda is being built from source code, desired communication and
35 thus authentication methods (shown as "Authentication") must be
36 specified as configure options at compilation time.
37 Authentication Configure option(s)
39 bsd --with-bsd-security --with-amandahosts (pre-2.6)
40 bsdtcp --with-bsdtcp-security --with-amandahosts (pre-2.6)
41 bsdudp --with-bsdudp-security --with-amandahosts (pre-2.6)
42 krb5 --with-krb5-security
43 local (always included)
44 rsh --with-rsh-security
45 ssh --with-ssh-security
46 ssl --with-ssl-security
47 There are additional configure options for bsd, bsdudp, and bsdtcp to
49 allow for specifying explicit UDP and TCP port ranges.
50 --with-udpportrange
52 --with-tcpportrange
53 --with-low-tcpportrange
54 See PORT USAGE below for more information.
56 There are additional configure options for Kerberos 5 if you so desire.
58 --with-krb5-security=DIR where libkrb.a lives [see below]
60 If configuring with --with-krb5-security, the configure script will
62 search under /usr/kerberos/lib, /usr/cygnus/lib, /usr/lib, and
63 /opt/kerberos/lib for the kerberos bits, libkrb.a, in this order.
64 Kerberos support will not be added if it does not find them. If the
65 kerberos bits are found under some other hierarchy, you can specify
66 this via --with-krb5-security=DIR where DIR is where the kerberos bits
67 live. The configure script will then look in the 'lib' directory under
68 this hierarchy for libkrb.a.
69 The auth parameter selects a communication/authentication method to use
71 between the client and the backup server. These methods are described
72 each in their own section below.
73 Usernames
75 When Amanda is built, a username is specified with the --with-user
76 option. Most Amanda processes run under this user's identity, to
77 minimize security risks. In binary distributions, this username is
78 usually one of 'amanda', 'amandabackup', or 'backup'. The examples
79 below use 'amandabackup' since it is unambiguous. You may need to
80 adjust accordingly for your system.
81 Authenticated Peer Hostnames
83 Amanda's authentication mechanisms provide an authenticated hostname of
84 the system on the other end of the connection, which is used to
85 restrict access to only particular hosts. The degree of
86 "authentication" performed on this hostname varies with the
87 authentication mechanism, and is discussed below.
88
90 For additional information including example configurations, see
91 http://wiki.zmanda.com/index.php/Configuring_bsd/bsdudp/bsdtcp_authentication.
92 The bsd, bsdudp, and bsdtcp communication methods use either UDP, TCP,
94 or both protocols operating as a network service to authenticate and
95 exchange data between server and clients.
96 The authentication proceeds as follows: for a new, incoming connection,
98 Amanda verifies that the source port is in the reserved range (less
99 than 1024), which for UNIX hosts suggests that the remote user has root
100 privileges. Amanda then verifies that the reverse DNS for the remote
101 address matches the forward DNS; that is, that the address maps to a
102 hostname which maps back to the same address. Finally, the remote
103 system must provide a username that matches the username in
104 .amandahosts.
105 In addition to compilation and general configuration (see COMPILATION
107 AND GENERAL INFORMATION above), the authentication method that the
108 client is configured to receive is specified by the auth parameter in
109 the network service configuration for Amanda. The authentication method
110 used by an Amanda client to reach the server during recovery is the
111 authentication method specified by the auth parameter in the client's
112 Amanda network service configuration or in its amanda-client.conf file
113 (see amanda-client.conf(5)).
114 By default, Amanda use the "amanda" service name and associated port
116 set in /etc/services. It can be changed by setting the dumptype
117 client-port option to a different port number or a different service
118 name. All examples are for the service name "amanda" that uses the
119 default port 10080.
120 .amandahosts file
122 Servers and clients using the bsd, bsdudp, and bsdtcp authentication
123 methods refer to the .amandahosts file to control access. Amanda should
124 be compiled for this access control if one of these methods will be
125 used and is the default compilation option for Amanda 2.6 (use
126 --with-amandahosts when compiling pre-2.6 versions of Amanda).
127 Amanda looks for the .amandahosts file in the Amanda user's home
129 directory, commonly /var/lib/amanda.
130 Each authorization is on its own line in the following format
132 hostname [ username [ service... ] ]
134 If username is omitted, it defaults to the user running amandad, i.e.
136 the user listed in the inetd or xinetd configuration file.
137 service... is a space-delimited list of services the client is
139 authorized to execute: noop, selfcheck, sendsize, sendbackup, amdump (a
140 shortcut for the previous four services which are required on clients),
141 amindexd, and amidxtaped. The last two services are required on a
142 server for clients to connect to it using amrecover.
143 If service is omitted, it defaults to noop selfcheck sendsize
145 sendbackup (which is equivalent to amdump).
146 Example of the .amandahosts file on an Amanda client, where
148 'amandabackup' is the Amanda dumpuser.
149 amandaserver.example.com amandabackup amdump
151 Example of the .amandahosts file on an Amanda server
153 amandaclient1.example.com root amindexd amidxtaped
155 bsd communication and authentication
157 The authentication is done using .amandahosts file in the Amanda user's
158 home directory. The protocol between Amanda server and client is UDP.
159 The number of disk list entries (DLEs)--number of Amanda clients--is
160 limited by the UDP packet size. This authentication protocol will use a
161 different port for each data stream (see PORT USAGE below)
162 bsdudp communication and authentication
164 The authentication is done using .amandahosts files in the Amanda
165 user's home directory. It uses UDP protocol between Amanda server and
166 client for data and hence the number of DLEs is limited by the UDP
167 packet size. It uses one TCP port to establish the connection and
168 multiplexes all data streams using one port on the server (see PORT
169 USAGE below).
170 bsdtcp communication and authentication
172 The authentication is done using .amandahosts files in the backup
173 user's (for example: amandabackup) home directory. It uses TCP protocol
174 between Amanda server and client. On the client, two reserved ports are
175 used. On the server, all data streams are multiplexed to one port (see
176 PORT USAGE below).
177 USING INETD SERVER
179 Template for Amanda client inetd service entry
180 service_name socket_type protocol wait/nowait amanda_backup_user absolute_path_to_amandad amandad server_args
182 Client example of using bsd authorization for inetd server given Amanda
184 user is "amandabackup":
185 amanda dgram udp wait amandabackup /path/to/amandad amandad -auth=bsd amdump
187 The same could be used for bsdudp if specifying -auth=bsdudp instead of
189 -auth=bsd.
190 Client example of using bsdtcp authorization for inetd server given
192 Amanda user is "amandabackup":
193 amanda stream tcp nowait amandabackup /path/to/amandad amandad -auth=bsdtcp amdump
195 amindexd and amidxtaped would typically be added at the end of the line
197 as amandad server arguments for an Amanda server.
198 Server example of using bsdtcp authorization for inetd server given
200 Amanda user is "amandabackup":
201 amanda stream tcp nowait amandabackup /path/to/amandad amandad -auth=bsdtcp amdump amindexd amidxtaped
203 For Amanda version 2.5.0 and earlier, remember that neither bsdudp nor
205 bsdtcp are supported and the Amanda daemon amandad accepts no
206 arguments. Because of the latter, amrecover as of Amanda version 2.5.1
207 is not compatible with 2.5.0 and earlier servers. Thus, servers that
208 are 2.5.0 or earlier must, in addition to the amanda service, run
209 amindexd and amidxtaped Amanda services as their own network services,
210 amandaidx and amidxtape, respectively (see below).
211 There are no compatibility issues if server and clients are all 2.5.0
213 or earlier. If your server is 2.5.1 or later, you can still have
214 clients that are 2.5.0 and earlier although you must then use bsd
215 communication/authentication with these clients and must also run
216 amindexd and amidxtaped Amanda services on the server as their own
217 network services, amandaidx and amidxtape, respectively (see below). If
218 you have a server that is 2.5.0 and earlier, clients of a later version
219 on which you wish to run amrecover must use amoldrecover instead and,
220 again, the server must be running the amandaidx and amidxtape network
221 services.
222 Example of amindexd and amidxtaped Amanda daemon services configured as
224 their own network services for a 2.5.0 or earlier server or a newer
225 server having 2.5.0 or earlier clients
226 amandaidx stream tcp nowait amandabackup /usr/local/libexec/amanda/current/amindexd amindexd
228 amidxtape stream tcp nowait amandabackup /usr/local/libexec/amanda/current/amidxtaped amidxtaped
229 USING XINETD SERVER
231 Template for Amanda client xinetd service file
232 service amanda
234 {
235 only_from = Amanda server
236 socket_type = socket type
237 protocol = protocol
238 wait = yes/no
239 user = amanda backup user
240 group = amanda backup user group id
241 groups = yes
242 server = absolute path to amandad
243 server_args = amandad server arguments
244 disable = no
245 }
246 The only_from parameter can be used with xinetd but is usually in
248 addition to the primary form of access control via the .amandahosts
249 file.
250 Client example of using bsd authorization for xinetd server and for
252 Amanda user "amandabackup":
253 service amanda
255 {
256 only_from = amandaserver.example.com
257 socket_type = dgram
258 protocol = udp
259 wait = yes
260 user = amandabackup
261 group = disk
262 groups = yes
263 server = /path/to/amandad
264 server_args = -auth=bsd amdump
265 disable = no
266 }
267 The same could be used for bsdudp if specifying -auth=bsdudp instead of
269 -auth=bsd.
270 Client example of using bsdtcp authorization for xinetd server and for
272 Amanda user "amandabackup":
273 service amanda
275 {
276 only_from = amandaserver.example.com amandaclient.example.com
277 socket_type = stream
278 protocol = tcp
279 wait = no
280 user = amandabackup
281 group = disk
282 groups = yes
283 server = /path/to/amandad
284 server_args = -auth=bsdtcp amdump
285 disable = no
286 }
287 amindexd and amidxtaped would typically be added as additional
289 amandadserver_args for an Amanda server.
290 For Amanda version 2.5.0 and earlier, remember that neither bsdudp nor
292 bsdtcp are supported and the Amanda daemon amandad accepts no
293 arguments. Because of the latter, amrecover as of Amanda version 2.5.1
294 is not compatible with 2.5.0 and earlier servers. Thus, servers that
295 are 2.5.0 or earlier must, in addition to the amanda service, run
296 amindexd and amidxtaped Amanda services as their own network services,
297 amandaidx and amidxtape, respectively (see below).
298 There are no compatibility issues if server and clients are all 2.5.0
300 or earlier. If your server is 2.5.1 or later, you can still have
301 clients that are 2.5.0 and earlier although you must then use bsd
302 communication/authentication with these clients and must also run
303 amindexd and amidxtaped Amanda services on the server as their own
304 network services, amandaidx and amidxtape, respectively (see below). If
305 you have a server that is 2.5.0 and earlier, clients of a later version
306 on which you wish to run amrecover must use amoldrecover instead and,
307 again, the server must be running the amandaidx and amidxtape network
308 services.
309 Example of amindexd and amidxtaped Amanda daemon services configured as
311 their own network services for a 2.5.0 or earlier server or a newer
312 server having 2.5.0 or earlier clients
313 service amandaidx
315 {
316 socket_type = stream
317 protocol = tcp
318 wait = no
319 user = amanda
320 group = disk
321 server = /usr/local/libexec/amanda/amindexd
322 disable = no
323 }
324 service amidxtape
326 {
327 socket_type = stream
328 protocol = tcp
329 wait = no
330 user = amanda
331 group = disk
332 server = /usr/local/libexec/amanda/amidxtaped
333 disable = no
334 }
335 PORT USAGE
337 List of TCP/UDP ports used by network service communication methods for
338 Amanda server and client.
339 Key:
341 UP = Unreserved Port
342 RPpAP = Reserved Port per Amanda Process
343 UPpDLE = Unreserved Port per DLE
344 [..] = Configure options that can be used at compile time to define port ranges
345 Authentication Protocol Amanda server Amanda client
347 bsd udp 1 RPpAP [--with-udpportrange] 10080
348 tcp 1 UP [--with-tcpportrange] 3 UPpDLE [--with-tcpportrange]
349 bsdudp udp 1 RPpAP [--with-udpportrange] 10080
350 tcp 1 UP [-with-tcpportrange] 1 UPpDLE [--with-tcpportrange]
351 bsdtcp tcp 1 RPpAP [--with-low-tcpportrange] 10080
352 Amanda server also uses two ports (dumper process) to communicate with
354 the chunker/taper processes. These ports are in the range set by
355 --with-tcpportrange.
356 You can override the default port ranges that Amanda was compiled with
358 in each configuration using the reserved-udp-port, reserved-tcp-port,
359 and unreserved-tcp-port parameters in amanda.conf and
360 amanda-client.conf configuration files (see amanda.conf(5) and amanda-
361 client.conf(5)).
362 Authenticated Peer Hostnames with BSD Authentications
364 The BSD authentication mechanisms only verify that the remote host's
365 DNS is configured correctly and that the remote user has access to
366 reserved ports. As such, the peer hostname should only be trusted to
367 the extent that the local DNS service is trusted.
368
370 For more detail, see
371 http://wiki.zmanda.com/index.php/Kerberos_authentication.
372 Amanda supports Kerberos 5 communication methods between Amanda server
374 and client.
375 General information including compilation are given above (see
377 COMPILATION AND GENERAL INFORMATION above).
378 Kerberos 5 uses TCP and the server uses only one TCP port and data
380 streams are multiplexed to this port.
381 The krb5 driver script defaults to:
384 /*
385 * The lifetime of our tickets in minutes.
386 */
387 #define AMANDA_TKT_LIFETIME (12*60)
388 /*
390 * The name of the service in /etc/services.
391 */
392 #define AMANDA_KRB5_SERVICE_NAME "k5amanda"
393 You can currently only override these by editing the source code.
396 The kerberized AMANDA service uses a different port on the client
398 hosts. The /etc/services line is:
399 k5amanda 10082/tcp
400 And the /etc/inetd.conf line is:
402 k5amanda stream tcp nowait root /usr/local/libexec/amanda/amandad amandad -auth=krb5
404 Note that you're running this as root, rather than as your dump user.
406 AMANDA will set its UID down to the dump user at times it doesn't need
407 to read the keytab file, and give up root permissions entirely before
408 it goes off and runs dump. Alternately you can change your keytab files
409 to be readable by user amanda. You should understand the security
410 implications of this before changing the permissions on the keytab.
411 The following dumptype options apply to krb5:
413 auth "krb5" # use krb5 auth for this host
415 # (you can mingle krb hosts and bsd .rhosts in one conf)
416 The principal and keytab files that Amanda uses must be set in the
418 amanda.conf file for kerberos 5 dumps to work. You can hardcode this in
419 the source code if you really want to (common-src/krb5-security.c)
420 krb5keytab
422 krb5principal
423 For example:
425 krb5keytab "/etc/krb5.keytab-amanda"
427 krb5principal "amanda/saidin.omniscient.com"
428 The principal in the second option must be contained in the first. The
430 keytab should be readable by the amanda user (and definitely not world
431 readable!) and is (obviously) on the server. In MIT's kadmin, the
432 following:
433 addprinc -randkey amanda/saidin.omniscient.com
435 ktadd -k /etc/krb5.keytab-amanda amanda/saidin.omniscient.com
436 will do the trick. You will obviously want to change the principal name
438 to reflect something appropriate for the conventions at your site.
439 You must also configure each client to allow the amanda principal in
441 for dumps.
442 There are several ways to go about authorizing a server to connect to a
444 client.
445 The normal way is via a .k5amandausers file or a .k5login file in the
447 client user's home directory. The determination of which file to use is
448 based on the way you ran configure on AMANDA. By default, AMANDA will
449 use .k5amandahosts, but if you configured with --without-amandahosts,
450 AMANDA will use .k5login. (similar to the default for
451 .rhosts/.amandahosts-style security). The .k5login file syntax is a
452 superset of the default krb5 .k5login. The routines to check it are
453 implemented in amanda rather than using krb5_kuserok because the
454 connections are actually gssapi based.
455 This .k5amandahosts/.k5login is a hybrid of the .amandahosts and a
457 .k5login file. You can just list principal names, as in a .k5login file
458 and the principal will be permitted in from any host. If you do NOT
459 specify a realm, then there is no attempt to validate the realm (this
460 is only really a concern if you have cross-realm authentication set up
461 with another realm or something else that allows you multiple realms in
462 your kdc. If you do specify a realm, only that principal@realm will be
463 permitted to connect.
464 You may prepend this with a hostname and whitespace, and only that
466 principal (with optional realm as above) will be permitted to access
467 from that hostname.
468 Here are examples of valid entries in the .k5amandahosts:
470 service/amanda
472 service/amanda@TEST.COM
473 dumpmaster.test.com service/amanda
474 dumpmaster.test.com service/amanda@TEST.COM
475 Rather than using a .k5amandahosts or .k5login file, the easiest way is
477 to use a principal named after the destination user, (such as
478 amanda@TEST.COM in our example) and not have either a .k5amandahosts or
479 .k5login file in the destination user's home directory.
480 There is no attempt to verify the realm in this case (only a concern if
482 you have cross-realm authentication setup).
483 Authenticated Peer Hostnames with Kerberos Authentication
485 When accepting a new incoming connection, the Kerberos authentication
486 mechanism performs a similar check to that done by the BSD
487 authentications: the forward and reverse DNS entries for the remote
488 host must match. As such, while Kerberos authentication can
489 cryptographically ensure that the remote system is recognized (since it
490 has a ticket), its assurances about the remote host's identity are
491 weaker and depend on the integrity of the DNS.
492
494 The Amanda server communicates with the client internally versus over
495 the network, ie. the client is also the server.
496 This is the only method that requires no authentication as it is
498 clearly not needed.
499 The authenticated peer hostname for this authentication will be as
501 reported by gethostname if that succeeds, or the fixed string localhost
502 otherwise.
503 This method requires the host name in the DLE to be one that refers to
505 this host. Any name for which gataddrinfo is able to return at least
506 one address usable as the local end of a socket will work.
507
509 For more detail, see
510 http://wiki.zmanda.com/index.php/Configuring_rsh_authentication.
511 The Amanda server communicates with its client as the Amanda user via
513 the RSH protocol.
514 Please note that RSH protocol itself is insecure and should be used
516 with caution especially on any servers and clients with public IPs.
517 Each Amanda client communicates with the server using one TCP port and
519 all data streams from the client are multiplexed over one port. The
520 number of Amanda clients is limited by the number of reserved ports
521 available on the Amanda server. Some versions of RSH do not use
522 reserved ports and, thus, this restriction is not valid.
523 General information including compilation is given above (see
525 COMPILATION AND GENERAL INFORMATION above).
526 In addition to specifying the auth field in dumptype definition, it
528 might be required to specify client-username and amandad fields. If the
529 backup user name is different on the Amanda client, the user name is
530 specified as client-username. If the location of the Amanda daemon
531 amandad is different on the Amanda client, the location is specified as
532 amandad-path field value.
533 For example:
535 define dumptype rsh_example {
536 ...
537 auth "rsh"
538 client-username "amandabackup"
539 amandad-path "/usr/lib/exec/amandad"
540 ...
541 }
542 Authenticated Peer Hostnames with RSH Authentication
544 The RSH authentication mechanism does not provide an authenticated peer
545 hostname.
546
548 For more detail, see
549 http://wiki.zmanda.com/index.php/How_To:Set_up_transport_encryption_with_SSH.
550 Amanda client sends data to the server using SSH. SSH keys have to be
552 set up so that Amanda server can communicate with its clients using
553 SSH.
554 General information including compilation is given above (see
556 COMPILATION AND GENERAL INFORMATION above).
557 SSH provides transport encryption and authentication. To set up an SSH
559 authentication session, Amanda will run the equivalent of the following
560 to start the backup process.
561 /path/to/ssh -l user_name client.zmanda.com $libexecdir/amandad
562 To use SSH, you need to set up SSH keys either by storing the
564 passphrase in cleartext, using ssh-agent, or using no passphrase at
565 all. All of these options have security implications which should be
566 carefully considered before adoption.
567 When you use a public key on the client to do data encryption (see
569 http://wiki.zmanda.com/index.php/How_To:Set_up_data_encryption), you
570 can lock away the private key in a secure place. Both, transport and
571 storage will be encrypted with such a setup. See
572 http://wiki.zmanda.com/index.php/Encryption for an overview of
573 encryption options.
574 Enable SSH authentication and set the ssh-keys option in all DLEs for
576 that host by adding the following to the DLE itself or to the
577 corresponding dumptype in amanda.conf:
578 auth "ssh"
580 ssh-keys "/home/amandabackup/.ssh/id_rsa_amdump"
581 ssh-keys is the path to the private key on the client. If the username
583 to which Amanda should connect is different from the default, then you
584 should also add
585 client-username "otherusername"
587 If your server amandad path and client amandad path are different, you
589 should also add
590 amandad-path "/client/amandad/path"
592 Include the keys used for AMANDA in the clients' authorized_keys file,
594 prepended with the following options:
595 from="amanda_server.your.domain.com",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/absolute/path/to/amandad -auth=ssh amdump" ssh-rsa AAAB3..
597 This will limit that key to connect only from Amanda server and only be
599 able to execute amandad(8). This avoids several attacks that are
600 possible if the no options are specified in the authorized_keys file.
601 In the same way, prepend the key used for AMANDA in the server's
603 authorized_keys file with:
604 from="amanda_client.your.domain.com",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/absolute/path/to/amandad -auth=ssh amindexd amidxtaped"
606 You can omit the from=.. option if you have too many clients to list,
608 although this has obvious security implications.
609 Set ssh-keys and any other necessary options in
611 /etc/amanda/amanda_client.conf:
612 auth "ssh"
614 ssh-keys "/root/.ssh/id_rsa_amrecover"
615 client-username "amanda"
616 amandad-path "/server/amandad/path"
617 Besides user keys, SSH uses host keys to uniquely identify each host,
619 to prevent one host from impersonating another. Unfortunately, the only
620 easy way to set up these host keys is to make a connection and tell SSH
621 that you trust the identity:
622 $ ssh client1.zmanda.com
624 The authenticity of host 'client1.zmanda.com (192.168.10.1)' can't be established.
625 RSA key fingerprint is 26:4e:df:a2:be:c8:cb:20:1c:68:8b:cc:c0:3b:8e:9d.
626 Are you sure you want to continue connecting (yes/no)?yes
627 As Amanda will not answer this question itself, you must manually make
629 every connection (server to client and client to server) that you
630 expect Amanda to make. Note that you must use the same username that
631 Amanda will use (that is, ssh client and ssh client.domain.com are
632 distinct).
633 Authenticated Peer Hostnames with SSH Authentication
635 When accepting an incoming connection, the SSH daemon gives Amanda
636 information about the remote system in the $SSH_CONNECTION environment
637 variable. Amanda parses this information to determine the remote
638 address, and then performs a similar check to that done by the BSD
639 authentications: the forward and reverse DNS entries for the remote
640 host must match. As such, while SSH authentication can
641 cryptographically ensure that the remote system is recognized (since it
642 had a recognized secret key), its assurances about the remote host's
643 identity are weaker and depend on the integrity of the DNS.
644
646 See amanda-auth-ssl(7)
647
649 amanda(8), amanda-auth-ssl(7), amanda.conf(5), amanda-client.conf(5),
650 disklist(5), amdump(8), amrecover(8)
651 The Amanda Wiki: : http://wiki.zmanda.com/
653
655 Jean-Louis Martineau <martineau@zmanda.com>
656 Zmanda, Inc. (http://www.zmanda.com)
657 Dustin J. Mitchell <dustin@zmanda.com>
659 Zmanda, Inc. (http://www.zmanda.com)
660 Paul Yeatman <pyeatman@zmanda.com>
662 Zmanda, Inc. (http://www.zmanda.com)
663Amanda 3.5.1 12/01/2017 AMANDA-AUTH(7)