OpenSSH 3.5p1 Public/Private Key Authenction Problem
From: Kenneth R. Robinette (support@securenetterm.com)
Date: 11/20/02
- Next message: gobo: "Re: way too many sshd's running"
- Previous message: Jacob Nevins: "Re: putty, openssh and e-smith: key is wrong type...."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "Kenneth R. Robinette" <support@securenetterm.com> Date: 20 Nov 2002 19:10:23 GMT
Many of our clients which use our Windows based SSH-2 client use X-509
certificates for their public/private key authentication. These
certificates are typically stored on SmartCards/USB tokens or within the
Microsoft/Netscape browser certificate stores. In almost all cases, the
private key is protected, and cannot be
directly accessed (as it should be for proper security).
This technique only uses the public/private key of the certificates. That
is, the public key is exported from the certificate and stored on the host
in the SSH key file, in the required format. Then all SSH-2 server
public/private key authentication requests (challenges) utilize the private
key of the certificate to sign (private key encrypt) the SSH-2
authentication challenge.
Internally, our software makes use of an Microsoft/Netscape crypto API which
allows an authentication challenge from an SSH-2 server to be signed by the
private key using an CALG_SSL3_SHAMD5 hashing technique commonly used by all
www browsers. In the case of an SSL authentication, a 36 byte challenge in
presented to be signed with the private key. SSH-2 uses an 35 byte
challenge.
This technique worked well with all SSH Data Communication servers and all
OpenSSH SSH-2 servers up to OpenSSH release 3.5p1. It now fails in the
latest release of OpenSSH-3.5p1 due to some new code added to ssh-rsa.c,
function openssh_RSA_verify, in which three length checks are made against
the signed challenge returned by the client. The function checks the length
of the returned oid, hash and the total length. The first two pass, as they
should, however the total length check will fail since it will have a value
of 36, instead of the expected 35. If the total length checked is removed,
authentication will succeed, otherwise it will fail.
Since many companies have a policy against modifying server based vendor
code, is there another method by which we can sign the SSH-2 challenge
without having direct access to the private key? Direct private key
encryption is not an option since it is not supported by all smart cards/USB
vendors/browser vendors.
Ken
-- Support InterSoft International, Inc. Voice: 888-823-1541 Fax: 888-823-1542 support@securenetterm.com http://www.securenetterm.com
- Next message: gobo: "Re: way too many sshd's running"
- Previous message: Jacob Nevins: "Re: putty, openssh and e-smith: key is wrong type...."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
