1AMANDA-AUTH(7)                    Miscellanea                   AMANDA-AUTH(7)
2
3
4

NAME

6       amanda-auth - Communication/Authentication methods between Amanda
7       server and client
8

DESCRIPTION

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

COMPILATION AND GENERAL INFORMATION

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
28       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
34       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
38       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
48       There are additional configure options for bsd, bsdudp, and bsdtcp to
49       allow for specifying explicit UDP and TCP port ranges.
50
51          --with-udpportrange
52          --with-tcpportrange
53          --with-low-tcpportrange
54
55       See PORT USAGE below for more information.
56
57       There are additional configure options for Kerberos 5 if you so desire.
58
59          --with-krb5-security=DIR       where libkrb.a lives   [see below]
60
61       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
70       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
74   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
82   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

BSD, BSDUDP, AND BSDTCP COMMUNICATION AND AUTHENTICATION

90       For additional information including example configurations, see
91       http://wiki.zmanda.com/index.php/Configuring_bsd/bsdudp/bsdtcp_authentication.
92
93       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
97       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
106       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
115       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
121   .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
128       Amanda looks for the .amandahosts file in the Amanda user's home
129       directory, commonly /var/lib/amanda.
130
131       Each authorization is on its own line in the following format
132
133       hostname [ username [ service...  ] ]
134
135       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
138       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
144       If service is omitted, it defaults to noop selfcheck sendsize
145       sendbackup (which is equivalent to amdump).
146
147       Example of the .amandahosts file on an Amanda client, where
148       'amandabackup' is the Amanda dumpuser.
149
150           amandaserver.example.com   amandabackup   amdump
151
152       Example of the .amandahosts file on an Amanda server
153
154           amandaclient1.example.com   root   amindexd amidxtaped
155
156   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
163   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
171   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
178   USING INETD SERVER
179       Template for Amanda client inetd service entry
180
181          service_name socket_type protocol wait/nowait amanda_backup_user absolute_path_to_amandad amandad server_args
182
183       Client example of using bsd authorization for inetd server given Amanda
184       user is "amandabackup":
185
186          amanda dgram udp wait amandabackup /path/to/amandad amandad -auth=bsd amdump
187
188       The same could be used for bsdudp if specifying -auth=bsdudp instead of
189       -auth=bsd.
190
191       Client example of using bsdtcp authorization for inetd server given
192       Amanda user is "amandabackup":
193
194          amanda stream tcp nowait amandabackup /path/to/amandad amandad -auth=bsdtcp amdump
195
196       amindexd and amidxtaped would typically be added at the end of the line
197       as amandad server arguments for an Amanda server.
198
199       Server example of using bsdtcp authorization for inetd server given
200       Amanda user is "amandabackup":
201
202          amanda stream tcp nowait amandabackup /path/to/amandad amandad -auth=bsdtcp amdump amindexd amidxtaped
203
204       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
212       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
223       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
227          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
230   USING XINETD SERVER
231       Template for Amanda client xinetd service file
232
233       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
247       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
251       Client example of using bsd authorization for xinetd server and for
252       Amanda user "amandabackup":
253
254       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
268       The same could be used for bsdudp if specifying -auth=bsdudp instead of
269       -auth=bsd.
270
271       Client example of using bsdtcp authorization for xinetd server and for
272       Amanda user "amandabackup":
273
274       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
288       amindexd and amidxtaped would typically be added as additional amandad
289       server_args for an Amanda server.
290
291       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
299       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
310       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
314       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
325       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
336   PORT USAGE
337       List of TCP/UDP ports used by network service communication methods for
338       Amanda server and client.
339
340          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
346       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
353       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
357       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
363   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

KERBEROS COMMUNICATION AND AUTHENTICATION

370       For more detail, see
371       http://wiki.zmanda.com/index.php/Kerberos_authentication.
372
373       Amanda supports Kerberos 5 communication methods between Amanda server
374       and client.
375
376       General information including compilation are given above (see
377       COMPILATION AND GENERAL INFORMATION above).
378
379       Kerberos 5 uses TCP and the server uses only one TCP port and data
380       streams are multiplexed to this port.
381
382
383       The krb5 driver script defaults to:
384       /*
385        * The lifetime of our tickets in minutes.
386        */
387       #define AMANDA_TKT_LIFETIME     (12*60)
388
389       /*
390        * The name of the service in /etc/services.
391        */
392       #define AMANDA_KRB5_SERVICE_NAME        "k5amanda"
393
394
395       You can currently only override these by editing the source code.
396
397       The kerberized AMANDA service uses a different port on the client
398       hosts. The /etc/services line is:
399          k5amanda      10082/tcp
400
401       And the /etc/inetd.conf line is:
402
403          k5amanda stream tcp nowait root /usr/local/libexec/amanda/amandad amandad -auth=krb5
404
405       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
412       The following dumptype options apply to krb5:
413
414          auth "krb5"    # use krb5 auth for this host
415                         # (you can mingle krb hosts and bsd .rhosts in one conf)
416
417       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
421          krb5keytab
422          krb5principal
423
424       For example:
425
426          krb5keytab    "/etc/krb5.keytab-amanda"
427          krb5principal  "amanda/saidin.omniscient.com"
428
429       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
434          addprinc -randkey amanda/saidin.omniscient.com
435          ktadd -k /etc/krb5.keytab-amanda amanda/saidin.omniscient.com
436
437       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
440       You must also configure each client to allow the amanda principal in
441       for dumps.
442
443       There are several ways to go about authorizing a server to connect to a
444       client.
445
446       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
456       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
465       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
469       Here are examples of valid entries in the .k5amandahosts:
470
471          service/amanda
472          service/amanda@TEST.COM
473          dumpmaster.test.com service/amanda
474          dumpmaster.test.com service/amanda@TEST.COM
475
476       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
481       There is no attempt to verify the realm in this case (only a concern if
482       you have cross-realm authentication setup).
483
484   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

LOCAL COMMUNICATION

494       The Amanda server communicates with the client internally versus over
495       the network, ie. the client is also the server.
496
497       This is the only method that requires no authentication as it is
498       clearly not needed.
499
500       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
504       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

RSH COMMUNICATION AND AUTHENTICATION

509       For more detail, see
510       http://wiki.zmanda.com/index.php/Configuring_rsh_authentication.
511
512       The Amanda server communicates with its client as the Amanda user via
513       the RSH protocol.
514
515       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
518       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
524       General information including compilation is given above (see
525       COMPILATION AND GENERAL INFORMATION above).
526
527       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
534       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
543   Authenticated Peer Hostnames with RSH Authentication
544       The RSH authentication mechanism does not provide an authenticated peer
545       hostname.
546

SSH COMMUNICATION AND AUTHENTICATION

548       For more detail, see
549       http://wiki.zmanda.com/index.php/How_To:Set_up_transport_encryption_with_SSH.
550
551       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
555       General information including compilation is given above (see
556       COMPILATION AND GENERAL INFORMATION above).
557
558       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
563       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
568       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
575       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
579         auth "ssh"
580         ssh-keys "/home/amandabackup/.ssh/id_rsa_amdump"
581
582       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
586         client-username "otherusername"
587
588       If your server amandad path and client amandad path are different, you
589       should also add
590
591         amandad-path "/client/amandad/path"
592
593       Include the keys used for AMANDA in the clients' authorized_keys file,
594       prepended with the following options:
595
596         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
598       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
602       In the same way, prepend the key used for AMANDA in the server's
603       authorized_keys file with:
604
605         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
607       You can omit the from=.. option if you have too many clients to list,
608       although this has obvious security implications.
609
610       Set ssh-keys and any other necessary options in
611       /etc/amanda/amanda_client.conf:
612
613         auth "ssh"
614         ssh-keys "/root/.ssh/id_rsa_amrecover"
615         client-username "amanda"
616         amandad-path "/server/amandad/path"
617
618       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
623         $ 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
628       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
634   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

SSL COMMUNICATION AND AUTHENTICATION

646       See amanda-auth-ssl(7)
647

SEE ALSO

649       amanda(8), amanda-auth-ssl(7), amanda.conf(5), amanda-client.conf(5),
650       disklist(5), amdump(8), amrecover(8)
651
652       The Amanda Wiki: : http://wiki.zmanda.com/
653

AUTHORS

655       Jean-Louis Martineau <martineau@zmanda.com>
656           Zmanda, Inc. (http://www.zmanda.com)
657
658       Dustin J. Mitchell <dustin@zmanda.com>
659           Zmanda, Inc. (http://www.zmanda.com)
660
661       Paul Yeatman <pyeatman@zmanda.com>
662           Zmanda, Inc. (http://www.zmanda.com)
663
664
665
666Amanda 3.5.4                      07/27/2023                    AMANDA-AUTH(7)
Impressum