1AMANDA-AUTH(7) Miscellanea AMANDA-AUTH(7)
2
6 amanda-auth - Communication/Authentication methods between Amanda
7 server and client
8
10 Amanda offers 7 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 krb4, krb5, local, rsh, and ssh. Please note that krb4 will be removed
16 in the next release. The authentication and communication method is
17 used during the backup process amdump (amdump(8)) as well as the
18 recovery process amrecover (amrecover(8)).
19
21 The communication method and thus type of authentication that will be
22 used by the Amanda server is specified by the auth parameter in the
23 dumptype for each disklist entry (DLE). The auth parameter thus may be
24 easily and globally specified in the "global" dumptype. If auth is not
25 specified, the bsd communication method is used. See amanda.conf(5) for
26 more information on Amanda configuration and dumptypes, and disklist(5)
27 for more information on disklists.
28 On the client side, the Amanda daemon amandad validates the connection
30 depending on the value of the auth argument passed to it (see
31 Amanda(8)). Also, when it comes to recovery, the auth parameter can be
32 specified in the amanda-client.conf(5) file to specify the
33 communication method to be used by the client to the server.
34 When Amanda is being built from source code, desired communication and
36 thus authentication methods (shown as "Authentication") must be
37 specified as configure options at compilation time.
38 Authentication Configure option(s)
40 bsd --with-bsd-security --with-amandahosts (pre-2.6)
41 bsdtcp --with-bsdtcp-security --with-amandahosts (pre-2.6)
42 bsdudp --with-bsdudp-security --with-amandahosts (pre-2.6)
43 krb5 --with-krb5-security
44 local (always included)
45 rsh --with-rsh-security
46 ssh --with-ssh-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 if you so desire.
58 All but the last option are for Kerberos 4. Defaults shown in square
59 brackets.
60 --with-server-principal=ARG server host principal [amanda]
62 --with-server-instance=ARG server host instance []
63 --with-server-keyfile=ARG server host key file [/.amanda]
64 --with-client-principal=ARG client host principal [rcmd]
65 --with-client-instance=ARG client host instance [HOSTNAME_INSTANCE]
66 --with-client-keyfile=ARG client host key file [KEYFILE]
67 --with-ticket-lifetime=ARG ticket lifetime [128]
68 --with-krb4-security=DIR where libkrb.a lives [see below]
69 --with-krb5-security=DIR where libkrb.a lives [see below]
70 If configuring with --with-krb4-security and/or --with-krb5-security,
72 the configure script will search under /usr/kerberos/lib,
73 /usr/cygnus/lib, /usr/lib, and /opt/kerberos/lib for the kerberos bits,
74 libkrb.a, in this order. Kerberos support will not be added if it does
75 not find them. If the kerberos bits are found under some other
76 hierarchy, you can specify this via --with-krb5-security=DIR and/or
77 --with-krb4-security=DIR, where DIR is where the kerberos bits live.
78 The configure script will then look in the ´lib´ directory under this
79 hierarchy for libkrb.a.
80 The auth parameter selects a communication/authentication method to use
82 between the client and the backup server. These methods are described
83 each in their own section below.
84
86 For additional information including example configurations, see
87 http://wiki.zmanda.com/index.php/Configuring_bsd/bsdudp/bsdtcp_authentication.
88 The bsd, bsdudp, and bsdtcp communication methods use either UDP, TCP,
90 or both protocols operating as a network service to authenticate and
91 exchange data between server and clients.
92 In addition to compilation and general configuration (see COMPILATION
94 AND GENERAL INFORMATION above), the authentication method that the
95 client is configured to receive is specified by the auth parameter in
96 the network service configuration for Amanda. The authentication method
97 used by an Amanda client to reach the server during recovery is the
98 authentication method specified by the auth parameter in the client´s
99 Amanda network service configuration or in its amanda-client.conf file
100 (see amanda-client.conf(5)).
101 By default, Amanda use the "amanda" service name and associated port
103 set in /etc/services. It can be changed by setting the dumptype
104 client_port option to a different port number or a different service
105 name. All examples are for the service name "amanda" that uses the
106 default port 10080.
107 .amandahosts file
109 Servers and clients using the bsd, bsdudp, and bsdtcp authentication
110 methods refer to the .amandahosts file to control access. Amanda should
111 be compiled for this access control if one of these methods will be
112 used and is the default compilation option for Amanda 2.6 (use
113 --with-amandahosts when compiling pre-2.6 versions of Amanda).
114 Amanda looks for the .amandahosts file in the Amanda user´s home
116 directory, commonly /var/lib/amanda.
117 Each authorization is on its own line in the following format
119 hostname [ username [ service... ] ]
121 If username is ommitted, it defaults to the user running amandad, i.e.
123 the user listed in the inetd or xinetd configuration file.
124 service... is a space-delimited list of services the client is
126 authorized to execute: noop, selfcheck, sendsize, sendbackup, amdump (a
127 shortcut for the previous four services which are required on clients),
128 amindexd, and amidxtaped. The last two services are required on a
129 server for clients to connect to it using amrecover.
130 If service is omitted, it defaults to noop selfcheck sendsize
132 sendbackup (which is equivalent to amdump).
133 Example of the .amandahosts file on an Amanda client
135 amandaserver.example.com amandabackup amdump
137 Example of the .amandahosts file on an Amanda server
139 amandaclient1.example.com root amindexd amidxtaped
141 bsd communication and authentication
143 The authentication is done using .amandahosts file in the Amanda user´s
144 home directory. The protocol between Amanda server and client is UDP.
145 The number of disk list entries (DLEs)--number of Amanda clients--is
146 limited by the UDP packet size. This authentication protocol will use a
147 different port for each data stream (see PORT USAGE below)
148 bsdudp communication and authentication
150 The authentication is done using .amandahosts files in the Amanda
151 user´s home directory. It uses UDP protocol between Amanda server and
152 client for data and hence the number of DLEs is limited by the UDP
153 packet size. It uses one TCP port to establish the connection and
154 multiplexes all data streams using one port on the server (see PORT
155 USAGE below).
156 bsdtcp communication and authentication
158 The authentication is done using .amandahosts files in the backup
159 user´s (for example: amandabackup) home directory. It uses TCP protocol
160 between Amanda server and client. On the client, two reserved ports are
161 used. On the server, all data streams are multiplexed to one port (see
162 PORT USAGE below).
163 USING INETD SERVER
165 Template for Amanda client inetd service entry
166 service_name socket_type protocol wait/nowait amanda_backup_user absolute_path_to_amandad amandad server_args
168 Client example of using bsd authorization for inetd server given Amanda
170 user is "amandabackup":
171 amanda dgram udp wait amandabackup /path/to/amandad amandad -auth=bsd amdump
173 The same could be used for bsdudp if specifying -auth=bsdudp instead of
175 -auth=bsd.
176 Client example of using bsdtcp authorization for inetd server given
178 Amanda user is "amandabackup":
179 amanda stream tcp nowait amanda /path/to/amandad amandad -auth=bsdtcp amdump
181 amindexd and amidxtaped would typically be added at the end of the line
183 as amandad server arguments for an Amanda server.
184 Server example of using bsdtcp authorization for inetd server given
186 Amanda user is "amandabackup":
187 amanda stream tcp nowait amanda /path/to/amandad amandad -auth=bsdtcp amdump amindexd amidxtaped
189 For Amanda version 2.5.0 and earlier, remember that neither bsdudp nor
191 bsdtcp are supported and the Amanda daemon amandad accepts no
192 arguments. Because of the latter, amrecover as of Amanda version 2.5.1
193 is not compatible with 2.5.0 and earlier servers. Thus, servers that
194 are 2.5.0 or earlier must, in addition to the amanda service, run
195 amindexd and amidxtaped Amanda services as their own network services,
196 amandaidx and amidxtape, respectively (see below).
197 There are no compatibility issues if server and clients are all 2.5.0
199 or earlier. If your server is 2.5.1 or later, you can still have
200 clients that are 2.5.0 and earlier although you must then use bsd
201 communication/authentication with these clients and must also run
202 amindexd and amidxtaped Amanda services on the server as their own
203 network services, amandaidx and amidxtape, respectively (see below). If
204 you have a server that is 2.5.0 and earlier, clients of a later version
205 on which you wish to run amrecover must use amoldrecover instead and,
206 again, the server must be running the amandaidx and amidxtape network
207 services.
208 Example of amindexd and amidxtaped Amanda daemon services configured as
210 their own network services for a 2.5.0 or earlier server or a newer
211 server having 2.5.0 or earlier clients
212 amandaidx stream tcp nowait amanda /usr/local/libexec/amanda/current/amindexd amindexd
214 amidxtape stream tcp nowait amanda /usr/local/libexec/amanda/current/amidxtaped amidxtaped
215 USING XINETD SERVER
217 Template for Amanda client xinetd service file
218 service amanda
220 {
221 only_from = Amanda server
222 socket_type = socket type
223 protocol = protocol
224 wait = yes/no
225 user = amanda backup user
226 group = amanda backup user group id
227 groups = yes
228 server = absolute path to amandad
229 server_args = amandad server arguments
230 disable = no
231 }
232 The only_from parameter can be used with xinetd but is usually in
234 addition to the primary form of access control via the .amandahosts
235 file.
236 Client example of using bsd authorization for xinetd server and for
238 Amanda user "amandabackup":
239 service amanda
241 {
242 only_from = amandaserver.example.com
243 socket_type = dgram
244 protocol = udp
245 wait = yes
246 user = amandabackup
247 group = disk
248 groups = yes
249 server = /path/to/amandad
250 server_args = -auth=bsd amdump
251 disable = no
252 }
253 The same could be used for bsdudp if specifying -auth=bsdudp instead of
255 -auth=bsd.
256 Client example of using bsdtcp authorization for xinetd server and for
258 Amanda user "amandabackup":
259 service amanda
261 {
262 only_from = amandaserver.example.com amandaclient.example.com
263 socket_type = stream
264 protocol = tcp
265 wait = no
266 user = amandabackup
267 group = disk
268 groups = yes
269 server = /path/to/amandad
270 server_args = -auth=bsdtcp amdump
271 disable = no
272 }
273 amindexd and amidxtaped would typically be added as additional amandad
275 server_args for an Amanda server.
276 For Amanda version 2.5.0 and earlier, remember that neither bsdudp nor
278 bsdtcp are supported and the Amanda daemon amandad accepts no
279 arguments. Because of the latter, amrecover as of Amanda version 2.5.1
280 is not compatible with 2.5.0 and earlier servers. Thus, servers that
281 are 2.5.0 or earlier must, in addition to the amanda service, run
282 amindexd and amidxtaped Amanda services as their own network services,
283 amandaidx and amidxtape, respectively (see below).
284 There are no compatibility issues if server and clients are all 2.5.0
286 or earlier. If your server is 2.5.1 or later, you can still have
287 clients that are 2.5.0 and earlier although you must then use bsd
288 communication/authentication with these clients and must also run
289 amindexd and amidxtaped Amanda services on the server as their own
290 network services, amandaidx and amidxtape, respectively (see below). If
291 you have a server that is 2.5.0 and earlier, clients of a later version
292 on which you wish to run amrecover must use amoldrecover instead and,
293 again, the server must be running the amandaidx and amidxtape network
294 services.
295 Example of amindexd and amidxtaped Amanda daemon services configured as
297 their own network services for a 2.5.0 or earlier server or a newer
298 server having 2.5.0 or earlier clients
299 service amandaidx
301 {
302 socket_type = stream
303 protocol = tcp
304 wait = no
305 user = amanda
306 group = disk
307 server = /usr/local/libexec/amanda/amindexd
308 disable = no
309 }
310 service amidxtape
312 {
313 socket_type = stream
314 protocol = tcp
315 wait = no
316 user = amanda
317 group = disk
318 server = /usr/local/libexec/amanda/amidxtaped
319 disable = no
320 }
321 PORT USAGE
323 List of TCP/UDP ports used by network service communication methods for
324 Amanda server and client.
325 Key:
327 UP = Unreserved Port
328 RPpAP = Reserved Port per Amanda Process
329 UPpDLE = Unreserved Port per DLE
330 [..] = Configure options that can be used at compile time to define port ranges
331 Authentication Protocol Amanda server Amanda client
333 bsd udp 1 RPpAP [--with-udpportrange] 10080
334 tcp 1 UP [--with-tcpportrange] 3 UPpDLE [--with-tcpportrange]
335 bsdudp udp 1 RPpAP [--with-udpportrange] 10080
336 tcp 1 UP [-with-tcpportrange] 1 UPpDLE [--with-tcpportrange]
337 bsdtcp tcp 1 RPpAP [--with-low-tcpportrange] 10080
338 Amanda server also uses two ports (dumper process) to communicate with
340 the chunker/taper processes. These ports are in the range set by
341 --with-tcpportrange.
342 You can override the default port ranges that Amanda was compiled with
344 in each configuration using the reserved-udp-port, reserved-tcp-port,
345 and unreserved-tcp-port parameters in amanda.conf and
346 amanda-client.conf configuration files (see amanda.conf(5) and amanda-
347 client.conf(5)).
348
350 For more detail, see
351 http://wiki.zmanda.com/index.php/Kerberos_authentication.
352 Amanda supports Kerberos 4 and 5 communication methods between Amanda
354 server and client. Please note, however, that support for Kerberos 4
355 will be removed in the next release.
356 General information including compilation are given above (see
358 COMPILATION AND GENERAL INFORMATION above). Below sections give
359 specific Kerberos 4 and 5 information.
360 KERBEROS v4
362 Please note that support for Kerberos 4 will be removed in the next
363 release.
364 Kerberos 4 uses UDP protocol and the number of DLEs is limited by UDP
366 packet size.
367 The kerberized AMANDA service uses a different port on the client
369 hosts. The /etc/services line is:
370 kamanda 10081/udp
372 And the /etc/inetd.conf line is:
374 kamanda dgram udp wait root /usr/local/libexec/amanda/amandad amandad -auth=krb4
376 Note that you´re running this as root, rather than as your dump user.
378 AMANDA will set its uid down to the dump user at times it doesn´t need
379 to read the srvtab file, and give up root permissions entirely before
380 it goes off and runs dump. Alternately you can change your srvtab files
381 to be readable by user amanda.
382 The following dumptype options apply to krb4:
384 auth "krb4" # use krb4 auth for this host
386 # (you can mingle krb hosts and bsd .rhosts in one conf)
387 kencrypt # encrypt this filesystem over the net using the krb4
388 # session key. About 2x slower. Good for those root
389 # partitions containing your keyfiles. Don´t want to
390 # give away the keys to an ethernet sniffer!
391 # This is currently always enabled. There is no
392 # way to disable it. This is a bug.
393 KERBEROS v5
395 Kerberos 5 uses TCP and the server uses only one TCP port and data
396 streams are multiplexed to this port.
397 The krb5 driver script defaults to:
400 /*
402 * The lifetime of our tickets in minutes.
403 */ #define AMANDA_TKT_LIFETIME (12*60)
404 /*
406 * The name of the service in /etc/services.
407 */ #define AMANDA_KRB5_SERVICE_NAME "k5amanda"
408 You can currently only override these by editing the source code.
410 The kerberized AMANDA service uses a different port on the client
412 hosts. The /etc/services line is:
413 k5amanda 10082/tcp
415 And the /etc/inetd.conf line is:
417 k5amanda stream tcp nowait root /usr/local/libexec/amanda/amandad amandad -auth=krb5
419 Note that you´re running this as root, rather than as your dump user.
421 AMANDA will set its UID down to the dump user at times it doesn´t need
422 to read the keytab file, and give up root permissions entirely before
423 it goes off and runs dump. Alternately you can change your keytab files
424 to be readable by user amanda. You should understand the security
425 implications of this before changing the permissions on the keytab.
426 The following dumptype options apply to krb5:
428 auth "krb5" # use krb5 auth for this host
430 # (you can mingle krb hosts and bsd .rhosts in one conf)
431 The principal and keytab files that Amanda uses must be set in the
433 amanda.conf file for kerberos 5 dumps to work. You can hardcode this in
434 the source code if you really want to (common-src/krb5-security.c)
435 krb5keytab
437 krb5principal
438 For example:
440 krb5keytab "/etc/krb5.keytab-amanda"
442 krb5principal "amanda/saidin.omniscient.com"
443 The principal in the second option must be contained in the first. The
445 keytab should be readable by the amanda user (and definitely not world
446 readable!) and is (obviously) on the server. In MIT´s kadmin, the
447 following:
448 addprinc -randkey amanda/saidin.omniscient.com
450 ktadd -k /etc/krb5.keytab-amanda amanda/saidin.omniscient.com
451 will do the trick. You will obviously want to change the principal name
453 to reflect something appropriate for the conventions at your site.
454 You must also configure each client to allow the amanda principal in
456 for dumps.
457 There are several ways to go about authorizing a server to connect to a
459 client.
460 The normal way is via a .k5amandausers file or a .k5login file in the
462 client user´s home directory. The determination of which file to use is
463 based on the way you ran configure on AMANDA. By default, AMANDA will
464 use .k5amandahosts, but if you configured with --without-amandahosts,
465 AMANDA will use .k5login. (similar to the default for
466 .rhosts/.amandahosts-style security). The .k5login file syntax is a
467 superset of the default krb5 .k5login. The routines to check it are
468 implemented in amanda rather than using krb5_kuserok because the
469 connections are actually gssapi based.
470 This .k5amandahosts/.k5login is a hybrid of the .amandahosts and a
472 .k5login file. You can just list principal names, as in a .k5login file
473 and the principal will be permitted in from any host. If you do NOT
474 specify a realm, then there is no attempt to validate the realm (this
475 is only really a concern if you have cross-realm authentication set up
476 with another realm or something else that allows you multiple realms in
477 your kdc. If you do specify a realm, only that principal@realm will be
478 permitted to connect.
479 You may prepend this with a hostname and whitespace, and only that
481 principal (with optional realm as above) will be permitted to access
482 from that hostname.
483 Here are examples of valid entries in the .k5amandahosts:
485 service/amanda
487 service/amanda@TEST.COM
488 dumpmaster.test.com service/amanda
489 dumpmaster.test.com service/amanda@TEST.COM
490 Rather than using a .k5amandahosts or .k5login file, the easiest way is
492 to use a principal named after the destination user, (such as
493 amanda@TEST.COM in our example) and not have either a .k5amandahosts or
494 .k5login file in the destination user´s home directory.
495 There is no attempt to verify the realm in this case (only a concern if
497 you have cross-realm authentication setup).
498
500 The Amanda server communicates with the client internally versus over
501 the network, ie. the client is also the server.
502 This is the only method that requires no authentication as it is
504 clearly not needed.
505
507 For more detail, see
508 http://wiki.zmanda.com/index.php/Configuring_rsh_authentication.
509 The Amanda server communicates with its client as the Amanda user via
511 the RSH protocol.
512 Please note that RSH protocol itself is insecure and should be used
514 with caution especially on any servers and clients with public IPs.
515 Each Amanda client communicates with the server using one TCP port and
517 all data streams from the client are multiplexed over one port. The
518 number of Amanda clients is limited by the number of reserved ports
519 available on the Amanda server. Some versions of RSH do not use
520 reserved ports and, thus, this restriction is not valid.
521 General information including compilation is given above (see
523 COMPILATION AND GENERAL INFORMATION above).
524 In addition to specifying the auth field in dumptype definition, it
526 might be required to specify client_username and amandad fields. If the
527 backup user name is different on the Amanda client, the user name is
528 specified as client_username. If the location of the Amanda daemon
529 amandad is different on the Amanda client, the location is specified as
530 amandad_path field value.
531 For example:
533 define dumptype rsh_example {
534 ...
535 auth "rsh"
536 client_username "amandabackup"
537 amandad_path "/usr/lib/exec/amandad"
538 ...
539 }
540
542 For more detail, see
543 http://wiki.zmanda.com/index.php/How_To:Set_up_transport_encryption_with_SSH.
544 Amanda client sends data to the server using SSH. SSH keys have to be
546 set up so that Amanda server can communicate with its clients using
547 SSH.
548 General information including compilation is given above (see
550 COMPILATION AND GENERAL INFORMATION above).
551 SSH provides transport encryption and authentication. To set up an SSH
553 authentication session, Amanda will run the equivalent of the following
554 to start the backup process.
555 /path/to/ssh -l user_name client.zmanda.com $libexecdir/amandad
557 To use SSH, you need to set up SSH keys either by storing the
559 passphrase in cleartext, using ssh-agent, or using no passphrase at
560 all. All of these options have security implications which should be
561 carefully considered before adoption.
562 When you use a public key on the client to do data encryption (see
564 http://wiki.zmanda.com/index.php/How_To:Set_up_data_encryption), you
565 can lock away the private key in a secure place. Both, transport and
566 storage will be encrypted with such a setup. See
567 http://wiki.zmanda.com/index.php/Encryption for an overview of
568 encryption options.
569 Enable SSH authentication and set the ssh_keys option in all DLEs for
571 that host by adding the following to the DLE itself or to the
572 corresponding dumptype in amanda.conf:
573 auth "ssh"
575 ssh_keys "/home/amandabackup/.ssh/id_rsa_amdump"
576 ssh_keys is the path to the private key on the client. If the username
578 to which Amanda should connect is different from the default, then you
579 should also add
580 client_username "otherusername"
582 If your server amandad path and client amandad path are different,
584 you should also add
585 amandad_path "/client/amandad/path"
587 For a marginal increase in security, prepend the keys used for AMANDA
589 in the clients´ authorized_keys file with the following:
590 from="amanda_server.your.domain.com",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/absolute/path/to/amandad -auth=ssh amdump"
592 This will limit that key to connect only from Amanda server and only be
594 able to execute amandad(8).
595 In the same way, prepend the key used for AMANDA in the server´s
597 authorized_keys file with:
598 from="amanda_client.your.domain.com",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/absolute/path/to/amandad -auth=ssh amindexd amidxtaped"
600 You can omit the from=.. option if you have too many clients to list,
602 although this has obvious security implications.
603 Set ssh_keys and any other necessary options in
605 /etc/amanda/amanda_client.conf:
606 auth "ssh"
608 ssh_keys "/root/.ssh/id_rsa_amrecover"
609 client_username "amanda"
610 amandad_path "/server/amandad/path"
611 Besides user keys, SSH uses host keys to uniquely identify each host,
613 to prevent one host from impersonating another. Unfortunately, the only
614 easy way to set up these host keys is to make a connection and tell SSH
615 that you trust the identity:
616 $ ssh client1.zmanda.com
618 The authenticity of host ´client1.zmanda.com (192.168.10.1)´ can´t be established.
619 RSA key fingerprint is 26:4e:df:a2:be:c8:cb:20:1c:68:8b:cc:c0:3b:8e:9d.
620 Are you sure you want to continue connecting (yes/no)?yes
621 As Amanda will not answer this question itself, you must manually make
623 every connection (server to client and client to server) that you
624 expect Amanda to make. Note that you must use the same username that
625 Amanda will use (that is, ssh client and ssh client.domain.com are
626 distinct).
627
629 amanda(8), amanda.conf(5), amanda-client.conf(5), disklist(5),
630 amdump(8), amrecover(8)
631 The Amanda Wiki: : http://wiki.zmanda.com/
633
635 Jean-Louis Martineau <martineau@zmanda.com>
636 Zmanda, Inc. (http://www.zmanda.com)
637 Dustin J. Mitchell <dustin@zmanda.com>
639 Zmanda, Inc. (http://www.zmanda.com)
640 Paul Yeatman <pyeatman@zmanda.com>
642 Zmanda, Inc. (http://www.zmanda.com)
643Amanda 3.1.3 10/04/2010 AMANDA-AUTH(7)