Backup Central

I am having the following message emailed to me by my server

<snip>
Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey).
Fatal Error: Truncated header string (problem probably originated remotely)

Couldn't start up the remote connection by executing

ssh -C 192.168.0.253 rdiff-backup --server

Remember that, under the default settings, rdiff-backup must be
installed in the PATH on the remote system. See the man page for more
information on this. This message may also be displayed if the remote
version of rdiff-backup is quite different from the local version (0.12.6).
<snip>

Both versions of rdiff-backup are the same 0.12.6. I have reset the keys and
am still being denied permission. Maybe I did not do this correctly. One
machine is running Debian the other redhook (er red hat, obviously my mind
is else where). I am able to ssh from one to the other and back, so these
machines are not denying login permission. I'm stuck , I need this back up
to be working.

Any clues

paul ackerman

On Tue, 21 Sep 2004 13:54:27 -0600
"Paul Ackerman" <paul < at > steamboatarchitectural.com> wrote:

Permission denied (publickey).

Despite your assertion that you can ssh from one machine to another, this
error is an ssh error. So:

- when you ssh from one machine to another, do you do it as the user which
runs rdiff-backup?

- do you have any settings in the ~/.ssh/config file of the account that
rdiff-backup is running under?

- exactly what command line are you using?

- what happens (again as the user rdiff-backup runs under) when you execute
"rdiff-backup --test-server remoteserver::/put/anything/here ?

Keith

Keith,
thanks for the prompt response. I pretty newbie to this stuff so i'll have
to stumble through answering you questions. i appreciate your help. This may
take a little time, but I want to be accurate and not waste your time. here
we go



Permission denied (publickey).

Despite your assertion that you can ssh from one machine to another, this
error is an ssh error. So:

- when you ssh from one machine to another, do you do it as the user which
runs rdiff-backup?

I belive so I don't login as anything other that root to either machine.



- do you have any settings in the ~/.ssh/config file of the account that
rdiff-backup is running under?

all that's in my .ssh folder is

authorized_keys known_hosts




- exactly what command line are you using?
I made a script and used crontab. the script contains this

#run rdiff-backup from debian to backup Data on fileserver full backup

rdiff-backup 192.168.0.253::/samba/Data /samba-saa

it's called rdiffcron

this is setup to lauch the rdiff on the RedHat from the Debian and place the
files on the Debian.

FYI this was funning fine for a while


- what happens (again as the user rdiff-backup runs under) when you
execute
"rdiff-backup --test-server remoteserver::/put/anything/here ?



mail-fw:~# rdiff-backup --test-server 192.168.0.253::/put/anything/here
root at 192.168.0.253's password:
Testing server started by: ssh -C 192.168.0.253 rdiff-backup --server
Server OK
mail-fw:~#

Keith

On Tue, 21 Sep 2004 15:22:58 -0600
"Paul Ackerman" <paul < at > steamboatarchitectural.com> wrote:

mail-fw:~# rdiff-backup --test-server 192.168.0.253::/put/anything/here
root at 192.168.0.253's password:
Testing server started by: ssh -C 192.168.0.253 rdiff-backup --server

This is both good and bad - good because it shows everything is working,
and bad because it is NOT using ssh keys (because you've been prompted for
a password, which won't happen if keys are set up correctly). We should be
able to prove that with:

$ ssh 192.168.0.253

- if that prompts you for a password then that is the problem we need to
solve. Assuming it does, what you should have done is to generate an ssh
key without a passphrase, and copy the public key to the
~/.ssh/authorized_keys file on the remote system, ideally editing it first
so that only rdiff-backup can be run from that login. This is described in
some detail at http://arctic.org/~dean/rdiff-backup/unattended.html, so you
may like to review that page and see if it helps.

If it doesn't, come back here and let us know what the problem is.

Keith

--
----------------------------------------------------------------------
Small business computer support: http://www.tiger-computing.co.uk
Linux consultancy: http://www.TheLinuxConsultancy.co.uk
----------------------------------------------------------------------
)

Excellant Keith,
I'm following you. I'll read up and try to get the keys straight and get
back to the list. This will most likely happen tommorow as I'm running out
of day, and brain power.
Thanks again.

paul


----- Original Message -----
From: "Keith Edmunds" <keith < at > midnighthax.com>
To: "Paul Ackerman" <paul < at > steamboatarchitectural.com>
Cc: <rdiff-backup-users < at > nongnu.org>
Sent: Tuesday, September 21, 2004 3:49 PM
Subject: Re: [rdiff-backup-users] remote rdiff-backup refused connection


On Tue, 21 Sep 2004 15:22:58 -0600
"Paul Ackerman" <paul < at > steamboatarchitectural.com> wrote:

mail-fw:~# rdiff-backup --test-server 192.168.0.253::/put/anything/here
root at 192.168.0.253's password:
Testing server started by: ssh -C 192.168.0.253 rdiff-backup --server

This is both good and bad - good because it shows everything is working,
and bad because it is NOT using ssh keys (because you've been prompted
for
a password, which won't happen if keys are set up correctly). We should be
able to prove that with:

$ ssh 192.168.0.253

- if that prompts you for a password then that is the problem we need to
solve. Assuming it does, what you should have done is to generate an ssh
key without a passphrase, and copy the public key to the
~/.ssh/authorized_keys file on the remote system, ideally editing it first
so that only rdiff-backup can be run from that login. This is described in
some detail at http://arctic.org/~dean/rdiff-backup/unattended.html, so
you
may like to review that page and see if it helps.

If it doesn't, come back here and let us know what the problem is.

Keith

--
----------------------------------------------------------------------
Small business computer support: http://www.tiger-computing.co.uk
Linux consultancy: http://www.TheLinuxConsultancy.co.uk
----------------------------------------------------------------------
)


_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL:
http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

PS
Doh!
ssh 192.168.0.253 does prompt for a password..
so it's the keys

paul

Keith,
I followed the instructions on the unattened link that you gave me. A
couple times now. It has been to no avail. I am still being asked for a
password.

I made a /root/.ssh/config file as follows

host 192.168.0.253-backup
hostname 192.168.0.253
identityfile /root/.ssh/id_rsa_backup
protocol 2

as instructed, minus the optional lines.

I have cut and pasted the results of "cat /root/.ssh/id_rad_backup.pub" from
my mirror (192.168.0.254 aka mail-fw) into the authorized_keys and
authorized_keys2( I tried both) files on my primary (192.168.0.253 aka
samba-saa)

and fianlly I applied the chmod commands as suggested. I did try to
rdiff-backup test before I changed the permissions, it asked for passwords
both ways.

Can't quite figure this one out.


thanks again

paul

On Wed, 22 Sep 2004 15:38:10 -0600
"Paul Ackerman" <paul < at > steamboatarchitectural.com> wrote:

host 192.168.0.253-backup
hostname 192.168.0.253
identityfile /root/.ssh/id_rsa_backup
protocol 2

Two things. Firstly, given the above entry, are you trying the following
(you should be):

rdiff-backup --test-server 192.168.0.253-backup::/anything/here

I ask only because that's an unusual name to give to a host. However, if
you are doing that and you're being prompted for a password, it could be a
permissions/ownership issue for the authorized_keys file (and all
directories on the path to it) on the remote server. The easiest way of
troubleshooting that is to edit /etc/ssh/sshd_config and change the line
the LogLevel line to:

LogLevel DEBUG

and then restart ssh. Then try the remote supposedly-passwordless login
again, and see what is reported in your logfile (the exact file depends on
how you have logging set up, but it's probably /var/log/auth or
/var/log/secure or similar). Let us know how you get on...

--
----------------------------------------------------------------------
Small business computer support: http://www.tiger-computing.co.uk
Linux consultancy: http://www.TheLinuxConsultancy.co.uk
----------------------------------------------------------------------