gert at greenie.muc.de
Sun Nov 5 11:33:41 EST 2000
On Sat, Nov 04, 2000 at 08:05:24PM +0100, Markus Friedl wrote:
> > I use ssh protocol 1, which (from reading the source comments) *should*
> > permit it - either directly, or by entering "password: s/key", but both do
> > not happen.
> this has been disabled.
> ssh -o 'skeyauthentication=yes' -o 'passwordauthentication=no' host
Better - that is, the following happens:
debug1: rcvd SSH_CMSG_AUTH_TIS
debug1: generating fake skeyinfo for gd.
debug1: sending challenge 'otp-md5 58 hilb68813'
debug: Installing crc compensation attack detector.
debug: Received encrypted confirmation.
debug: Doing skey authentication.
otp-md5 58 hilb68813
- the thing that is now puzzling me is that it shouldn't be "58" here.
The skeys are freshly generated, the current challenge is #98:
(and subsequently it doesn't work if I feed the output of
"skey -md5 58 hilb68813" plus my pass phrase into ssh - always "denied"
on the client side and "Failed s/key ..." on the server side).
On the other hand, if I use the challenge that has "its turn" (in my
case, "98 hilb65361", instead of "58 hilb68813"), login works fine.
So I think there is some bug in the printing of the challenge, the "58"
in the challenge seems to be static, even though "skeyinfo" prints now
"95 hilb65361" (burned a few numbers in the meantime).
I cannot claim to understand what's going on inside auth-skey.c before
printing the "otp-..." stuff - it takes some bytes that and adds them
to create the sequence number, and those bytes have been massaged by SHA1
before. No idea what that does and whether that's the way it should
USENET is *not* the non-clickable part of WWW!
Gert Doering - Munich, Germany gert at greenie.muc.de
fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de
More information about the openssh-unix-dev