.amandahosts file¶

Servers and clients using the bsd, bsdudp, and bsdtcp authentication methods refer to the .amandahosts file to control access. Amanda should be compiled for this access control if one of these methods will be used and is the default compilation option for Amanda 2.6 (use --with-amandahosts when compiling pre-2.6 versions of Amanda).

Amanda looks for the .amandahosts file in the Amanda user´s home directory, commonly /var/lib/amanda.

Each authorization is on its own line in the following format

hostname [ username [ service... ] ]

If username is ommitted, it defaults to the user running amandad, i.e. the user listed in the inetd or xinetd configuration file.

service... is a space-delimited list of services the client is authorized to execute: noop, selfcheck, sendsize, sendbackup, amdump (a shortcut for the previous four services which are required on clients), amindexd, and amidxtaped. The last two services are required on a server for clients to connect to it using amrecover.

Example of the .amandahosts file on an Amanda client

    amandaserver.example.com   amandabackup   amdump

Example of the .amandahosts file on an Amanda server

    amandaclient1.example.com   root   amindexd amidxtaped

bsd communication and authentication¶

The authentication is done using .amandahosts file in the Amanda user´s home directory. The protocol between Amanda server and client is UDP. The number of disk list entries (DLEs)--number of Amanda clients--is limited by the UDP packet size. This authentication protocol will use a different port for each data stream (see PORT USAGE below)

bsdudp communication and authentication¶

The authentication is done using .amandahosts files in the Amanda user´s home directory. It uses UDP protocol between Amanda server and client for data and hence the number of DLEs is limited by the UDP packet size. It uses one TCP port to establish the connection and multiplexes all data streams using one port on the server (see PORT USAGE below).

bsdtcp communication and authentication¶

The authentication is done using .amandahosts files in the backup user´s (for example: amandabackup) home directory. It uses TCP protocol between Amanda server and client. On the client, two reserved ports are used. On the server, all data streams are multiplexed to one port (see PORT USAGE below).

USING INETD SERVER¶

Template for Amanda client inetd service entry

   service_name socket_type protocol wait/nowait amanda_backup_user absolute_path_to_amandad amandad server_args

Client example of using bsd authorization for inetd server given Amanda user is "amandabackup":

   amanda dgram udp wait amandabackup /path/to/amandad amandad -auth=bsd amdump

The same could be used for bsdudp if specifying -auth=bsdudp instead of -auth=bsd.

Client example of using bsdtcp authorization for inetd server given Amanda user is "amandabackup":

   amanda stream tcp nowait amanda /path/to/amandad amandad -auth=bsdtcp amdump

amindexd and amidxtaped would typically be added at the end of the line as amandad server arguments for an Amanda server.

Server example of using bsdtcp authorization for inetd server given Amanda user is "amandabackup":

   amanda stream tcp nowait amanda /path/to/amandad amandad -auth=bsdtcp amdump amindexd amidxtaped

For Amanda version 2.5.0 and earlier, remember that neither bsdudp nor bsdtcp are supported and the Amanda daemon amandad accepts no arguments. Because of the latter, amrecover as of Amanda version 2.5.1 is not compatible with 2.5.0 and earlier servers. Thus, servers that are 2.5.0 or earlier must, in addition to the amanda service, run amindexd and amidxtaped Amanda services as their own network services, amandaidx and amidxtape, respectively (see below).

There are no compatibility issues if server and clients are all 2.5.0 or earlier. If your server is 2.5.1 or later, you can still have clients that are 2.5.0 and earlier although you must then use bsd communication/authentication with these clients and must also run amindexd and amidxtaped Amanda services on the server as their own network services, amandaidx and amidxtape, respectively (see below). If you have a server that is 2.5.0 and earlier, clients of a later version on which you wish to run amrecover must use amoldrecover instead and, again, the server must be running the amandaidx and amidxtape network services.

Example of amindexd and amidxtaped Amanda daemon services configured as their own network services for a 2.5.0 or earlier server or a newer server having 2.5.0 or earlier clients

   amandaidx stream tcp nowait amanda /usr/local/libexec/amanda/current/amindexd   amindexd
   amidxtape stream tcp nowait amanda /usr/local/libexec/amanda/current/amidxtaped amidxtaped

USING XINETD SERVER¶

Template for Amanda client xinetd service file

service amanda
{
	only_from               = Amanda server
	socket_type             = socket type
	protocol                = protocol
	wait                    = yes/no
	user                    = amanda backup user
	group                   = amanda backup user group id
	groups                  = yes
	server                  = absolute path to amandad
	server_args             = amandad server arguments
	disable                 = no
}

The only_from parameter can be used with xinetd but is usually in addition to the primary form of access control via the .amandahosts file.

Client example of using bsd authorization for xinetd server and for Amanda user "amandabackup":

service amanda
{
	only_from       = amandaserver.example.com
	socket_type     = dgram
	protocol        = udp
	wait            = yes
	user            = amandabackup
	group           = disk
	groups          = yes
	server          = /path/to/amandad
	server_args     = -auth=bsd amdump
	disable         = no 
}

The same could be used for bsdudp if specifying -auth=bsdudp instead of -auth=bsd.

Client example of using bsdtcp authorization for xinetd server and for Amanda user "amandabackup":

service amanda
{
	only_from       = amandaserver.example.com amandaclient.example.com
	socket_type     = stream
	protocol        = tcp
	wait            = no
	user            = amandabackup
	group           = disk
	groups          = yes
	server          = /path/to/amandad
	server_args     = -auth=bsdtcp amdump
	disable         = no 
}

amindexd and amidxtaped would typically be added as additional amandad server_args for an Amanda server.

For Amanda version 2.5.0 and earlier, remember that neither bsdudp nor bsdtcp are supported and the Amanda daemon amandad accepts no arguments. Because of the latter, amrecover as of Amanda version 2.5.1 is not compatible with 2.5.0 and earlier servers. Thus, servers that are 2.5.0 or earlier must, in addition to the amanda service, run amindexd and amidxtaped Amanda services as their own network services, amandaidx and amidxtape, respectively (see below).

There are no compatibility issues if server and clients are all 2.5.0 or earlier. If your server is 2.5.1 or later, you can still have clients that are 2.5.0 and earlier although you must then use bsd communication/authentication with these clients and must also run amindexd and amidxtaped Amanda services on the server as their own network services, amandaidx and amidxtape, respectively (see below). If you have a server that is 2.5.0 and earlier, clients of a later version on which you wish to run amrecover must use amoldrecover instead and, again, the server must be running the amandaidx and amidxtape network services.

Example of amindexd and amidxtaped Amanda daemon services configured as their own network services for a 2.5.0 or earlier server or a newer server having 2.5.0 or earlier clients

service amandaidx
{
	socket_type		= stream
	protocol		= tcp
	wait			= no
	user			= amanda
	group			= disk
	server			= /usr/local/libexec/amanda/amindexd 
	disable			= no
}
service amidxtape
{
	socket_type		= stream
	protocol		= tcp
	wait			= no
	user			= amanda
	group			= disk
	server			= /usr/local/libexec/amanda/amidxtaped
	disable			= no
}

PORT USAGE¶

List of TCP/UDP ports used by network service communication methods for Amanda server and client.

   Key:


       UP = Unreserved Port


    RPpAP = Reserved Port per Amanda Process


   UPpDLE = Unreserved Port per DLE


     [..] = Configure options that can be used at compile time to define port ranges
Authentication	Protocol	Amanda server					Amanda client
bsd			udp		1 RPpAP [--with-udpportrange]		10080
			tcp		1 UP [--with-tcpportrange]		3 UPpDLE [--with-tcpportrange]
bsdudp		udp		1 RPpAP [--with-udpportrange]		10080
			tcp		1 UP [-with-tcpportrange]		1 UPpDLE [--with-tcpportrange]
bsdtcp		tcp		1 RPpAP [--with-low-tcpportrange]	10080

Amanda server also uses two ports (dumper process) to communicate with the chunker/taper processes. These ports are in the range set by --with-tcpportrange.

You can override the default port ranges that Amanda was compiled with in each configuration using the reserved-udp-port, reserved-tcp-port, and unreserved-tcp-port parameters in amanda.conf and amanda-client.conf configuration files (see amanda.conf(5) and amanda-client.conf(5)).

KERBEROS v4¶

Please note that support for Kerberos 4 will be removed in the next release.

Kerberos 4 uses UDP protocol and the number of DLEs is limited by UDP packet size.

The kerberized AMANDA service uses a different port on the client hosts. The /etc/services line is:

kamanda 10081/udp

And the /etc/inetd.conf line is:

    kamanda dgram udp wait root /usr/local/libexec/amanda/amandad amandad -auth=krb4

Note that you´re running this as root, rather than as your dump user. AMANDA will set its uid down to the dump user at times it doesn´t need to read the srvtab file, and give up root permissions entirely before it goes off and runs dump. Alternately you can change your srvtab files to be readable by user amanda.

The following dumptype options apply to krb4:

auth "krb4"    # use krb4 auth for this host


               # (you can mingle krb hosts and bsd .rhosts in one conf)
kencrypt       # encrypt this filesystem over the net using the krb4


               # session key.  About 2x slower.  Good for those root


               # partitions containing your keyfiles.  Don´t want to


               # give away the keys to an ethernet sniffer!


               # This is currently always enabled.  There is no


               # way to disable it.  This is a bug.

KERBEROS v5¶

Kerberos 5 uses TCP and the server uses only one TCP port and data streams are multiplexed to this port.

The krb5 driver script defaults to:

/*
* The lifetime of our tickets in minutes.
*/ #define AMANDA_TKT_LIFETIME (12*60)

/*
* The name of the service in /etc/services.
*/ #define AMANDA_KRB5_SERVICE_NAME "k5amanda"

You can currently only override these by editing the source code.

The kerberized AMANDA service uses a different port on the client hosts. The /etc/services line is:

k5amanda 10082/tcp

And the /etc/inetd.conf line is:

   k5amanda stream tcp nowait root /usr/local/libexec/amanda/amandad amandad -auth=krb5

Note that you´re running this as root, rather than as your dump user. AMANDA will set its UID down to the dump user at times it doesn´t need to read the keytab file, and give up root permissions entirely before it goes off and runs dump. Alternately you can change your keytab files to be readable by user amanda. You should understand the security implications of this before changing the permissions on the keytab.

The following dumptype options apply to krb5:

   auth "krb5"    # use krb5 auth for this host


                  # (you can mingle krb hosts and bsd .rhosts in one conf)

The principal and keytab files that Amanda uses must be set in the amanda.conf file for kerberos 5 dumps to work. You can hardcode this in the source code if you really want to (common-src/krb5-security.c)

   krb5keytab


   krb5principal

For example:

   krb5keytab	  "/etc/krb5.keytab-amanda"


   krb5principal  "amanda/saidin.omniscient.com"

The principal in the second option must be contained in the first. The keytab should be readable by the amanda user (and definitely not world readable!) and is (obviously) on the server. In MIT´s kadmin, the following:

   addprinc -randkey amanda/saidin.omniscient.com


   ktadd -k /etc/krb5.keytab-amanda amanda/saidin.omniscient.com

will do the trick. You will obviously want to change the principal name to reflect something appropriate for the conventions at your site.

You must also configure each client to allow the amanda principal in for dumps.

There are several ways to go about authorizing a server to connect to a client.

The normal way is via a .k5amandausers file or a .k5login file in the client user´s home directory. The determination of which file to use is based on the way you ran configure on AMANDA. By default, AMANDA will use .k5amandahosts, but if you configured with --without-amandahosts, AMANDA will use .k5login. (similar to the default for .rhosts/.amandahosts-style security). The .k5login file syntax is a superset of the default krb5 .k5login. The routines to check it are implemented in amanda rather than using krb5_kuserok because the connections are actually gssapi based.

This .k5amandahosts/.k5login is a hybrid of the .amandahosts and a .k5login file. You can just list principal names, as in a .k5login file and the principal will be permitted in from any host. If you do NOT specify a realm, then there is no attempt to validate the realm (this is only really a concern if you have cross-realm authentication set up with another realm or something else that allows you multiple realms in your kdc. If you do specify a realm, only that principal@realm will be permitted to connect.

You may prepend this with a hostname and whitespace, and only that principal (with optional realm as above) will be permitted to access from that hostname.

Here are examples of valid entries in the .k5amandahosts:

   service/amanda


   service/amanda@TEST.COM


   dumpmaster.test.com service/amanda


   dumpmaster.test.com service/amanda@TEST.COM

Rather than using a .k5amandahosts or .k5login file, the easiest way is to use a principal named after the destination user, (such as amanda@TEST.COM in our example) and not have either a .k5amandahosts or .k5login file in the destination user´s home directory.

There is no attempt to verify the realm in this case (only a concern if you have cross-realm authentication setup).