amandad-path in the dumptype was the last requirement. amcheck works now. That was what was blocking
the ssh connection, because the authorized_key was locked down to only allow the one command and no
other:
from="wahoo.server.isb.nsm,172.30.144.37",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/usr/lib/amanda/amandad
-auth=ssh amdump" ssh-rsa . . . . (the key)
Thank you, Jean-Louis! Also, Charles Curley.
It turns out that it is necessary to have a valid shell for ssh-auth. I tried changing it back to
nologin after amcheck worked, and the result was that amcheck failed, indicating "This account is
currently not available."
Steps required to get the amanda client (with the Debian/Ubuntu 16.04 amanda 3.3.6 pkg) running,
assuming I'm using ssh-auth and have a server with amanda built from source with user and group amanda:
==============
Start on the client (this is after having done the `aptitude install
amanda-client`),
1. Change backup user's shell from /usr/sbin/nologin to /bin/bash in
/etc/passwd.
2. Change ownership of backup user's home directory from root:root to backup:backup (assume root
will still manage its cron jobs that backup other stuff into /var/backups).
3. `sudo su - backup`
4. `mkdir .ssh`
5. `ssh amanda.server` <-- to set up known_hosts entry
6. `cd .ssh` and then `vi authorized_keys` and put in the correct public key entry for the amanda
server.
On the server (where amanda is already set up and working for itself and other
clients),
1. `sudo su - amanda`
2. `ssh amanda.client` <-- to set up known_hosts entry for the new client
3. `vi daily/disklist` and set up disklist entries for client, e.g.
kilgore.server.isb.nsm /home {
comp-user-tar
client-username "backup"
amandad-path "/usr/lib/amanda/amandad"
} 001 server-rm
where the client-username and amandad-path are specified because they differ on the client
build of amanda compared to the server build. Of course, those could also have been entered in a
specific dumptype in amanda.conf and then that dumptype could have been used here. That would be the
easier route if there were lots of DLEs on this client.
4. `amcheck daily` to see that everything works.
Along the way, look at log files and debug files at /tmp/amanda/server/daily/ on the server (I
start with `ls -lt | head` so that I get the most recent) and /var/log/auth.log on the client.
I think that's it. Relatively simple once you get it. Hope I didn't miss
documenting any steps.
On 4/14/17 1:39 PM, Jean-Louis Martineau wrote:
On 14/04/17 01:33 PM, Chris Hoogendyk wrote:
> Close to working, but not quite.
>
> Here is the line from
> /tmp/amanda/server/daily/amcheck.20170414130845.debug on the server:
>
> Fri Apr 14 13:08:45 2017: thd-0x2383200: amcheck-clients: exec:
> /usr/bin/ssh -x -o BatchMode=yes -o PreferredAuthentications=publickey
> -l backup -i /usr/local/etc/amanda/.ssh/id_rsa_daily_config
> kilgore.server.isb.nsm /usr/local/libexec/amanda/amandad -auth=ssh
>
> The key is that it is asking to execute
> /usr/local/libexec/amanda/amandad on the client, but amandad is at
> /usr/lib/amanda/amandad. I had changed that in the authorized_keys
> file on the client, but where is the server getting that in the first
> place? How do I change it for this client, short of setting up that
> directory with a symlink? And, would a symlink even work? Or would the
> security checks disallow a symlink?
Set the amandad-path in the dumptype.
>
> At the moment, I'm getting "Permission denied (publickey,password)."
> during amcheck.
Something is not correctly set for ssh, check ssh and sshd logs files.
Run the ssh command from the command line
Jean-Louis
>
>
> On 4/14/17 12:07 PM, Jean-Louis Martineau wrote:
>> Chris,
>>
>> The home directory is not important, but you must put the .amandahosts
>> and .ssh there.
>>
>> In the dle, you must set client-username and probably amandad-path (but
>> it is better to set it in the client .ssh/authorized_keys for security.
>>
>> According to
>>
https://unix.stackexchange.com/questions/184031/can-a-command-be-executed-over-ssh-with-a-nologin-user,
>>
>> the nologin shell should not be a problem.
>> But you can set it to valid shell if you want to connect to the client
>>
>> Try to ssh the client from the server to accept the server keys
>> (known_hosts),a valid might be required here, I'm not sure.
>> Then run amcheck.
>>
>> Jean-Louis
>>
>> On 14/04/17 11:46 AM, Chris Hoogendyk wrote:
>> > Thank you, Jean-Louis,
>> >
>> > It's not so much a question of what doesn't work as it is of where to
>> > start.
>> >
>> > There doesn't seem to be any documentation of how the Debian/Ubuntu
>> > package was built or what steps should be required to implement a
>> client.
>> >
>> > Typically, when I build Amanda on a client, I build it with ssh-auth
>> > and user and group amanda. After the client is built and installed, I
>> > manually ssh back and forth to set up the known_hosts, transfer the
>> > public key to the new client, set up .amandahosts, and maybe a couple
>> > of other steps. Then I edit the disklist and add entries for the new
>> > client, run amcheck, and work out any remaining glitches, but usually
>> > it just works at this point.
>> >
>> > With the Debian/Ubuntu 3.3.6 package on Ubuntu 16.04, as I tried to
>> > figure out what had been done, I started out by running `dpkg-query -L
>> > amanda-client`. Since there was no amanda user or amandbackup user
>> > installed, I began looking at user backup. But its home directory,
>> > /var/backups, seemed weird, and its shell was /usr/sbin/nologin. So
>> > then what? Is it assumed that I will manually edit known_hosts and so
>> > on? And will the ssh-auth connection work when the client user has a
>> > shell of /usr/sbin/nologin? Or should I change that shell to something
>> > that works? And then just start hacking through with my normal
>> > procedures, but with a special dumptype that incorporates
>> > client-username "backup"?
>> >
>> > I'd prefer to do it as intended rather than hacking. One would presume
>> > that should be smoother, assuming the intended setup is known
>> > (documented).
>> >
>> >
>> > On 4/14/17 8:29 AM, Jean-Louis Martineau wrote:
>> >> Chris,
>> >>
>> >> We could help if you tell us what doesn't work.
>> >>
>> >> Jean-Louis
>> >>
>> >> On 13/04/17 03:53 PM, Chris Hoogendyk wrote:
>> >> > I have a group of amanda servers and clients that are all Ubuntu
>> 14.04
>> >> > with amanda 3.3.6 installed from source with ssh config and user
>> >> amanda.
>> >> >
>> >> > Now I'm trying to set up a new client that is Ubuntu 16.04. I
>> saw that
>> >> > the aptitude had amanda 3.3.6, common, server, and client packages.
>> >> > So, I thought, hey, that will make things easy.
>> >> >
>> >> > Not.
>> >> >
>> >> > So, it seems they built the package with user backup, home
>> directory
>> >> > /var/backups, and shell /usr/sbin/nologin. There doesn't seem to be
>> >> > any readme or install or configure instructions anywhere explaining
>> >> > how it has been built and how it has to be set up to function. I
>> had
>> >> > assumed it would be largely ready to go, with instructions on what
>> >> > configuration remained to be done.
>> >> >
>> >> > I also haven't been able to find much of anything through google.
>> >> >
>> >> > Does anyone have any guidance on this? Or should I just rip it
>> out and
>> >> > build from source? Amanda is one of the few things that I have
>> >> > continued to build from source since I switched from Solaris to
>> Ubuntu
>> >> > several years ago. All the other major packages get patches and
>> >> > security updates fairly regularly, so it pays to stick with
>> aptitude.
>> >> >
>> >> >
>> >>
>> >>
>> >> *Disclaimer*
>> >>
>> >> This message is the property of *CARBONITE, INC.*
>> >> <http://www.carbonite.com> and may contain confidential or privileged
>> >> information.
>> >>
>> >> If this message has been delivered to you by mistake, then do not
>> >> copy or deliver this message to anyone. Instead, destroy it and
>> >> notify me by reply e-mail.
>> >>
>> >
>>
>>
>> *Disclaimer*
>>
>> This message is the property of *CARBONITE, INC.*
>> <http://www.carbonite.com> and may contain confidential or privileged
>> information.
>>
>> If this message has been delivered to you by mistake, then do not
>> copy or deliver this message to anyone. Instead, destroy it and
>> notify me by reply e-mail.
>>
>
*Disclaimer*
This message is the property of *CARBONITE, INC.* <http://www.carbonite.com> and may contain
confidential or privileged information.
If this message has been delivered to you by mistake, then do not copy or deliver this message to
anyone. Instead, destroy it and notify me by reply e-mail.
--
---------------
Chris Hoogendyk
-
O__ ---- Systems Administrator
c/ /'_ --- Biology & Geosciences Departments
(*) \(*) -- 315 Morrill Science Center
~~~~~~~~~~ - University of Massachusetts, Amherst
<[email protected]>
---------------
Erdös 4
