SSH2 login and X509 certificates

[Richard W Hunt]

I opened a thread about this some time ago and closed it because the initiative was pushed back by other priorities. But I'm back, now with more specific problems.

We have OpenVMS 7.3-2 and TCPIP Services for OpenVMS, v 5.4 ECO 7. Also we have OpenSSL for OpenVMS 1.3 = OpenSSL 0.9.7.e. Our users are on Windows boxes using Reflections 14.0.2.

I can get SSH2 logins via Reflections when I allow username and password. What I would like to do is get a non-challenge login (OR it would be OK to demand the PIN associated with the certificate being used).

The certificates we are using are in X509 format, which I can export in any of three formats. Problem is, none of them work. My choices for output are DER, Base 64, or PKCS 7. If I export them, OpenSSL can read them using the "OpenSSL X509" options - but SSH2 does not like them.

I know of one case that WILL work but it is a server-to-server key that isn't X509 format. It is a DSA 2048-bit key, but it is a special case and has a waiver that won't apply to my general user base.

So... has anyone managed to get SSH2/X509 certificate logins to work?

I've checked with our security people. If there is another format I can use to convert the certificate, I am allowed to do that. But if it isn't a DoD approved certificate, I can't use it.

Does anyone have any helpful hints? The meager documentation I found in the updated Guide to SSH doesn't really help.

[Steven Schweda]

I know precious little about any of this
stuff, but a Google search for
ssh x509
found things like:

http://www1.tools.ietf.org/html/draft-saarenmaa-ssh-x509-00

which suggests that it was in "draft" status
in 2007, so I would be a little amazed if it
was available in TCPIP already.

Normal public-key SSH isn't good enough?

[Richard Whalen]

MultiNet's & TCPware's SSH has configuration mentions X.509 keys, though I have always used public key authentication. See http://www.process.com/tcpip/mndocs52/ADMIN_GUIDE/Ch30.htm#E29E31 and look for HostCertificateFile and Pki. Though there are some differences between the SSH that is in TCP/IP Services and MultiNet/TCPware, they share a common ancestry and generally have more in common than they have differences.

[Hoff]

OpenSSH in its most current 5.0p1 does not appear to have X.509, though there is a patch available. OpenSSH is the basis for the OpenVMS ssh mechanism.

Contact HP and ask for X.509 support, or ask for the source code and apply the patch. Or work with one of the Process IP stacks. Or your own ssh port.

http://www.openssh.com/
http://www.roumenpetrov.info/openssh/

Or get an exception.

Stephen Hoffman
HoffmanLabs LLC

[Richard W Hunt]

Thanks for the links. I've got some reading to do.

Unfortunately, "ordinary" PKI isn't the problem. It's the SOURCE of the key that is the issue. And no, I cannot get a waiver for that one. U.S. Dept. of Defense absolutely does a screaming howler-monkey dance on your desk if you violate that rule. I'd say you get handed your head, but that ain't true. They keep it and send the rest of you home.

When I download keys exported using IE, that doesn't work. My copy of OpenSSL can read the keys correctly and can identify the issuer, demographic data, and organizational data. But SSH doesn't use OpenSSL directly, and THAT is part of the problem. It is so frustrating to be that close and yet not be where I need to be.

I won't close this thread right away, just in case I figure out how to make it work. I've seen other posters talk about their VMS and Reflections issues, so if I develop any answer I'll share it.

[Richard W Hunt]

Update: After working with my security guys, I got a clarification.

The problem (as noted in another thread) is strictly the extraction of the RSA-1024 key that is embedded in the X509v3 certificate. Since I am not doing anything web-oriented, the certificate really isn't the issue. It is simply the extraction of that key so that the initial SSH "handshake" (DH Key Exchange Dialog) can occur using PKI rules.

I've worked with the Attachmate folks who supply our workstation terminal emulators. The point where it all locks up is that attempt to somehow get the public key out of the public certificate.

So close yet so far.

Since I have another thread open on this one, I'm going to close it and defer further references to that thread.

Thanks for all your help, gang!

[Richard W Hunt]

Thread closed due to presence of another more recent thread on the same subject.

[Dennis Handly]

>more recent thread on the same subject.

That would be:
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1278615