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