Amanda-Users

Re: amanda over ssh : eureka!

2006-09-24 22:11:50
Subject: Re: amanda over ssh : eureka!
From: Steve Newcomb <srn AT coolheads DOT com>
To: Kevin Till <kevin.till AT zmanda DOT com>
Date: 24 Sep 2006 21:01:57 -0400
> > Amanda Backup Client Hosts Check
> > --------------------------------
> > Host key verification failed.
> > WARNING: dimanche.coolheads.com: selfcheck request failed: EOF on read from 
> > dimanche.coolheads.com
> > Client check: 1 host checked in 0.137 seconds, 1 problem found
> 
> does dimanche.coolheads.com (the fqdn version) in the server's 
> .ssh/known_hosts file?

Well, that didn't work, but it gave me an idea that did work.  I'm
writing it here in case others can use this information and avoid some
of the tedium I've just experienced.

Kevin, you were right all along: there was a bug in my ssh
configuration.  It's just unfortunate that none of the cheap ways of
debugging the ssh problem -- ways that I already knew -- worked.

So, here was the debugging strategy that actually worked:

(1) Stop the client's sshd.  This will not interrupt current ssh
    sessions.  (If the client is remote, don't end your own ssh
    session until you've restarted sshd with it!)

(2) sshd -d

    ...and watch the output as you run amcheck on the server.  "-d"
    means "non-forking debug mode".  It discloses everything it's
    hearing, and everything it's doing about it.  It's downright
    chatty, in fact.

(3) (Don't forget to restart sshd!)

>From the sshd debug output, I learned that I was sending a good host
key, but the name of the host wasn't the same as the name of the host
on the key.  The amanda server was identifying its host to the amanda
client as "localhost", which made sense because, in this particular
case, both client and server were running on the same machine.  With
the knowledge of how amanda server was identifying its host to the
client, it was easy to set up the client's authorized_keys file with a
key associated with both of its hostnames.

The whole thing makes perfect sense.  It even makes sense that ssh (as
opposed to sshd) is so unhelpful about communicating what's wrong
(after all, it's not supposed to help the gate-crashers), and that
amcheck has nothing to say about the problem other than that the
client sent an EOT and that was all.  After all, what else would
amcheck know?

But if other Amanda users have problems making auth="ssh" work, I
suggest they be informed about the sshd -d method of debugging an ssh
configuration.

By the way, I had to use the same technique on 2 of my 5 clients: one
because of the "localhost" thing, and the other because that was the
only way to discover that only at that particular client, the server
process was seen as running on a host identified only as an IP
address, and not as any sort of hostname or fqhn.

-- Steve

Steven R. Newcomb, Consultant
Coolheads Consulting

Co-editor, Topic Maps International Standard (ISO/IEC 13250)
Co-editor, draft Topic Maps -- Reference Model (ISO/IEC 13250-5)

srn AT coolheads DOT com
http://www.coolheads.com

direct: +1 540 951 9773
main:   +1 540 951 9774
fax:    +1 540 951 9775

208 Highview Drive
Blacksburg, Virginia 24060 USA


(Confidential to all US government personnel to whom this private
letter is not addressed and who are reading it in the absence of a
specific search warrant: You are violating the law and you are
co-conspiring to subvert the Constitution that you are sworn to
defend.  You can either refuse to commit this crime, or you can expect
to suffer criminal sanctions in the future, when the current
administration of the United States of America has been replaced by
one that respects the rule of law.  I do not envy you for having to
make this difficult choice, but I urge you to make it wisely.)


<Prev in Thread] Current Thread [Next in Thread>