Multiple auth requests?

Stathis Voukelatos Stathis.Voukelatos at linn.co.uk
Mon Mar 19 19:38:57 WST 2012


Hi Fabrizio,

 

Most clients will usually first send an auth.request message containing
just the public key and not a signature, to test that

their public key is acceptable by the server. If that 'test' request
succeeds then they will send a second auth request 

containing both the public key and the signature generated using the
client's private key. This is a strategy to save to client

some unnecessary processing for generating signatures. There is a
Boolean field in the body of the auth.request messages

to distinguish between the 'test' and the 'real' request.

If that's what is happening in your case then I believe you could still
cache the auth state of the public key from the first

request. However, when the second request comes in you also need to
verify the signature before allowing the client to

authenticate.

 

Cheers,

Stathis

 

 

Stathis Voukelatos

Senior Software Engineer

Linn Products Ltd.

Glasgow Road

Eaglesham, Glasgow

G76 0EQ, UK

Tel: +44 (0)141 3035191

Email: stathis.voukelatos at linn.co.uk

 

 

 

 

From: dropbear-bounces at ucc.asn.au [mailto:dropbear-bounces at ucc.asn.au]
On Behalf Of Fabrizio Bertocci
Sent: 16 March 2012 23:11
To: dropbear at ucc.asn.au
Subject: Multiple auth requests?

 

Hi guys,

I'm working on a project that uses dropbear, and I'm modifying the code
to add a custom lookup mechanism for pub/priv keys that uses a database
instead of a file.

While debugging it, I've noticed that the server sometimes receives
message type 50 (that I understand it means auth. request) more than
once. 

The server, every time it receives an auth request, always attempts to
authenticate the client like it's the first time. 

To limit the load on the server and reduce the number of calls to the
database, I was wondering if somebody (Matt?) can help me understanding
if it is safe to 'cache' the auth state (or, since it's already present
in ses.authstate, reuse that value) and send back immediately the
previous auth state.

 

Unfortunately right now I'm on dropbear 0.52 (it's very stable for me
and I'm not very motivated to upgrade to the latest version yet).

 

Any help is highly appreciated!!

Regards,

Fabrizio

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20120319/a2dcc9e2/attachment.htm 


More information about the Dropbear mailing list