Sorry for the late reply. I was busy with other work last week, and then I spent the weekend helping my grandmother move to a new appartment. And on the top of it all, I'm having my computer at work reinstalled (this time with Solaris-2.6). Balazs Scheidler <[EMAIL PROTECTED]> writes: > On 3 Feb 1999, Niels [ISO-8859-1] M�ller wrote: > > > Or have the keyexchange mechanism patch "ssh-dss"->"ssh-dss-kludge", > > and use this when selecting signer object. There ought to be support > > for some alist signature-algorithm -> signer object anyway. > > I don't understand this signature-algorithm->signer mapping. After the > SSH_MSG_KEXINIT message is processed, the selected hostkey algorithm is > passed to KEYEXCHANGE_INIT. We'd only have to call > MAKE_SIGNER(signature_algorithm), of course the host's private and public > keys are needed for this. So what is this mapping about? In that case you need to map the signature algorithm to the right key instead. But I think we should use the private host key(s) to create signer object(s) earlier, and use the same object(s) for all keyexchange handshakes. Perhaps you are thinking primarily of the client (where it seems impractical to create the needed verification objects early), while I am thinking primarily of the server? Let me take this again, a little more slowly, for those of you who are not as familiar with the code and protocol as Bazsi: If the server supports several signature algorithms, it needs one signer object for each algorithm. The choice between them depends on the negotiated value for the "host key algorithm". The current code, in the do_dh_init() functions in server_keyexchange.c and client_keyexchange.c, aborts if this value is anything but SSH_DSS. The proper behaviour would be for the server to use the value to look up a signer object using the right algorithm (and the right host key for that algorithm). That mapping from host key algorithm to signer object was what I was referring to. The client should do a similar lookup, but I don't know if it should be done before invoking the LOOKUP_VERIFIER function, or if we should pass the algorithm value along for proper processing by that function. The idea was that if we have the old-ssh-version-kludge modify the host-key-algorithm value, that may be a natural way to let the relevant functions know which flavour of of dss signatures to use. BTW, ssh-2.0.12 was released a week ago. Do you know if that release fixes this or some of the other bugs you have stumbled upon? /Niels
