On Fri, 14 Apr 2017 15:41:32 -0400
Chris Hoogendyk wrote:
> I didn't.
Ah, thanks for clarifying.
And thanks for the writeup.
--
The right of the people to be secure in their persons, houses, papers,
and effects, against unreasonable searches and seizures, shall not be
violated, and no Warran
I didn't.
I have the server's public key on the client.
When I ssh'd from the client to the server, I only got the known_hosts and then terminated the
connection. In retrospect, I'm not sure I even needed that. I should try setting aside known_hosts
on the client and see if amcheck on the serv
On Fri, 14 Apr 2017 14:37:17 -0400
Chris Hoogendyk wrote:
> I think that's it. Relatively simple once you get it. Hope I didn't
> miss documenting any steps.
Looks good. I like locking down the keys to a specific executable.
I don't see where you generated the client's keys, or copied its publi
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
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 PreferredAuthentication
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/
On Fri, 14 Apr 2017 12:07:03 -0400
Jean-Louis Martineau wrote:
> 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 c
On Fri, 14 Apr 2017 11:46:46 -0400
Chris Hoogendyk wrote:
> 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 lookin
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/questio
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
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
On 13/04/17 07:38 PM, Charles Curley wrote:
> On Thu, 13 Apr 2017 22:42:06 +
> Debra S Baddorf wrote:
>
>> Q to others: does the client have to have the same username and
>> locations as the server?
No, they do not need to be the same.
Jean-Louis
This message is the property of CARBONITE,
from the man page for amanda-auth, there is a client-usaername that can be defined in a dumptype. I
haven't tried it yet, but . . .
On 4/13/17 7:38 PM, Charles Curley wrote:
On Thu, 13 Apr 2017 22:42:06 +
Debra S Baddorf wrote:
Q to others: does the client have to have the same userna
13 matches
Mail list logo
