[unisog] SSH postponed public key....

Tom Throckmorton throck at duke.edu
Wed Oct 3 18:29:35 GMT 2007

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: 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 :)



> 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 at lists.dshield.org
> https://lists.sans.org/mailman/listinfo/unisog

Tom Throckmorton
Duke University

More information about the unisog mailing list