A reply from another list that describes what is actually going on.
Hopefully this will get archived and the next person who asks this
question will find it with google before posting...
Russell
-------- Original Message --------
Subject: Re: [unisog] SSH postponed public key....
Date: Wed, 03 Oct 2007 14:29:35 -0400
From: Tom Throckmorton <throck@duke.edu>
Reply-To: UNIversity Security Operations Group <unisog@lists.dshield.org>
To: UNIversity Security Operations Group <unisog@lists.dshield.org>
References: <4702CB5A.6040405@auckland.ac.nz>
On 10/02/2007 06:51 PM, Russell Fulton wrote:
Hi
This isn't a big deal but I hate things I can't account for...
Going through the logs for a couple of Linux boxes (RHE if it matters) I
find that there are lots of
sshd[xxx]: 'Postponed publickey for oracle from ::ffff:130.216.249.147 port
9348 ssh2'
Russell (et. al.),
I don't believe this is a permissions issue at all - ssh is just
stepping through the client-configured authentication types (enabled in
either ssh_config or ~/.ssh/config) and trying them in turn, but
acknowledging that a publickey was presented, and postponing its use
until after trying the first auth type. If you 'ssh -v somehost',
you'll see which types are being tried, and in which order:
...
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering public key:....
So, in this case it's trying gssapi-mic, then publickey, and would
presumably fall through to password, assuming a key wasn't accepted -
and this also triggered the 'Postponed publickey' syslog message. If I
had disabled either gssapi or publickey auth for this session, no
'Postponed' message appears.
So, you could eliminate the messages by identifying the unwanted auth
type(s) being tried before publickey and disable them, either globally,
in your local ~/.ssh/config, or on the command line (e.g. 'ssh -o
GSSAPIAuthentication=no). Or, just safely ignore them :)
Cheers,
-tt
These two boxes form a cluster and apparently use ssh to constantly check on
each other. I have logged on the the boxes and su'ed to the oracle account
and done a manual ssh to the other machine and got the same message in
/var/log/secure.
The two oracle account have a normal set up with authorized keys file, the
only slightly odd thing is that someone has generated both dsa and rsa keys
on both machines but only the rsa key is in the authorized keys file.
If these were any 'ordinary' systems I would simply start fiddling but they
are part of our oracle cluster upon which everything else depends.
I've tried replicating the set up on another system but don't get the odd log
messages.
I have also spent some time googling around this without coming up with a
good explanation of what causes the postponed message
Any ideas?
Russell
_______________________________________________
unisog mailing list
unisog@lists.dshield.org
https://lists.sans.org/mailman/listinfo/unisog
--
Tom Throckmorton
OIT - CSI
Duke University
_______________________________________________
unisog mailing list
unisog@lists.dshield.org
https://lists.sans.org/mailman/listinfo/unisog
