EldoS | Feel safer!

Software components for data protection, secure storage and transfer

SSH Public key authentication With X509

Also by EldoS: Solid File System
A virtual file system that offers a feature-rich storage for application documents and data with built-in compression and encryption.
Posted: 01/17/2008 07:27:42
by Santiago Castaño (Standard support level)
Joined: 04/16/2006
Posts: 155


I'm trying to make a program that can connect to a ssh server (openssh) with X509 Certificates. I've done this in the past but with a program that extract the private key, converts it and loads into an TElSSHKey.

But now, I've seen that TElSSHKey has an .Import procedure; I'm calling it, the certificate is correctly imported, but it seems that FCert in SBSSHKeyStorage isn't of any use... It doesn't call RegenerateSSHBlob or anything and i can't connect. My last hope is to be able to use certificates from CryptoAPI also, and get rid of the extract privatekey process etc...

So the question is... is it possible? What does .Import in SBSSHKeyStorage do?

Posted: 01/17/2008 07:41:30
by Santiago Castaño (Standard support level)
Joined: 04/16/2006
Posts: 155

By the way, the code I'm using is:

      Key.Import(FLCertPFX); //FLCertPFX is a TElX509Certificate with privatekey=true
      FSftpClient.AuthenticationTypes := FSftpClient.AuthenticationTypes or SSH_AUTH_TYPE_PUBLICKEY;

And I'm getting that Authentication with public key has failed.

If I change it for:

I'm connecting successfully, and that PathPVK file is simply the private key of the FLCertPFX exported with SaveKeyToStreamPEM.

So the question is... do we have to create temporary stream to feed SSHKey with private key from a X509 or the .Import(X509Certificate) has sense?

Using lastest SBB VCL Edition over Delphi 7

Posted: 01/17/2008 08:22:56
by Ken Ivanov (EldoS Corp.)

Software products supporting X.509-based authentication can be divided into two big groups: (a) the ones that support it correctly, and (b) the ones that don't.

Products belonging to the first group operate with X.509 certificates, while products belonging to the second group operate with keys contained in them (i.e. no certificate is actually transferred during negotiation, its public key is transferred instead). The first chunk of code will work for the products from the first group, while the second chunk will work for the products from second group.

BTW, as far as I know, OpenSSH does not support X.509 authentication. Are you sure that it's OpenSSH who runs on a server side?

Just to ensure that you did everything right:
1. Please check that SSH_PK_X509_SIGN_RSA and SSH_PK_X509_SIGN_DSS algorithms are enabled,
2. Please try to load the certificate from file (not from the Windows certificate store). This will help to exclude potential problems that might be caused by CryptoAPI.
Posted: 01/17/2008 08:57:18
by Santiago Castaño (Standard support level)
Joined: 04/16/2006
Posts: 155

Yes, I'm using OpenSSH_3.6.1p2, the version may vary, but all our clients use OpenSSH as far as I know, or at least most of them.

The server returns SSH_PK_RSA; and i've googled a little bit, and found that openssh doesn't support it but there's a patch to be able to support it (I didn't know anything about that), so I'll take a look at it.

Do you know any free server that supports it on Linux to test it if I fail to patch openssh? I'm not a good linux knower.
Posted: 01/17/2008 09:12:19
by Ken Ivanov (EldoS Corp.)

Unfortunately, all the servers supporting X.509 authentication correctly are Windows-based commercial products. We also know nothing about OpenSSH patch, so you have a chance to be the first person who attempts to collaborate it with SBB.

Posted: 01/17/2008 17:10:32
by Santiago Castaño (Standard support level)
Joined: 04/16/2006
Posts: 155

Ok, here's my contribution for OpenSSH X509 Certificate Authentication with SBB.

I'll try to make it easy... but if there's any step missing, just tell it.

Patch and rebuild OpenSSH
- First of all, we have to patch OpenSSH. We'll patch it from here (http://roumenpetrov.info/openssh/). I've previously downloaded OpenSSH 4.7p1 from the OpenSSH webpage. Untar and ungzip OpenSSH4.7p1 and copy there the diff file downloaded from the webpage of roumenpetrov.
- Execute "zcat diff_file | patch -p 1" as the above webpage says...
- Do a "./configure " (for configuring OpenSSH)
- Do a "./make"
- Do a "./make install" (maybe you'll need to delete sshd_config file and backup it for sshd_config being updated with new parameters)
- Notes: During "./make", on my computer it lacks of krb5.h and two more header files, I found that they were inside a "Kerberos" directory, simply do a symbolink link to were it lacks (the lack is in include directory of OpenSSL). You may use a "find" to know where those header files are...

Configure OpenSSH
- You'll see that you've got a new sshd_config file (maybe at /etc/ssh?)
- I think the configuration is just fine, anyway, I told where the ca-bundle.crt file was, and I uncoment some parameters... just do a man on sshd_config for the common parameters (a webadmin knows more than me about this)
- I uploaded the public key of my certificate to my ~/.ssh/authorized_keys and do a "chmod 400 authorized_keys". I made the public key compatible with openssh with a small private program; but I think Eldos has a good example on SSHKeys nowadays...

¿Patch SBB?
- Well, this isn't really a needed patch, but I've made it because it's more transparent... You know that SBB has a CertAuthMode Property for both SSH and SFTP. It's defaulted to camAuto, but if you leave it in camAuto, it won't work. I spent half an hour trying to figure why OpenSSH wasn't working properly. The thing is that it NEEDS TO BE SET TO camTectia. The patch is simply detect OpenSSH:
//no more clues... It's Eldos code, if you have it, you know where the changes goes...
  FIsOpenSSH := (Pos(OPENSSH_ID, FServerSoftwareName) <> 0);
    else if (((FIsTectia or FIsOpenSSH) and (FCertAuthMode = camAuto)) or (FCertAuthMode = camTectia)) and
      (not FWrkArdCerts) and (KeyIndex = FKeyStorage.Count) then

Make your application work
- You know how to work with "identity" public keys. For working with certificates, just create a TElSSHKey, do a .Import(Your_TElX509Certificate) and add that key to your TElSSHMemoryKeyStorage.

YOU'RE IN!!!, the stability of linux and openssh working in SBB with X509 Certificates from wherever you want (CryptoAPI -tested-, PKCS#12 -tested-, PKCS#11 -still not tested-, ...)

Of course, many thanks to Eldos for making this possible and giving always tips or the solution.

P.S.: maybe we can see a camAuto to recognize OpenSSH in the trunk code?

Posted: 01/18/2008 04:12:52
by Ken Ivanov (EldoS Corp.)

Santiago, thank you very much for your *very detailed and useful* guide! We will consider adding it to the SBB FAQ.

maybe we can see a camAuto to recognize OpenSSH in the trunk code?

Sure. We will implement the necessary fixes for the future build update. Would you be so kind to check if ServerSoftwareName property for the "patched" OpenSSH contains some text that might help detecting it? If it doesn't (i.e., ServerSoftwareName is the same for both patched and unpatched OpenSSH), we will use other means for detecting the patched server.
Posted: 01/18/2008 06:02:26
by Santiago Castaño (Standard support level)
Joined: 04/16/2006
Posts: 155


Would you be so kind to check if ServerSoftwareName property for the "patched" OpenSSH contains some text that might help detecting it?

No :(, it doesn't says anything...

ServerSoftwareName is always 'OpenSSH'+'_'+(version of OpenSSH installed). The patch seems to not change it.
Posted: 01/19/2008 07:35:41
by Ken Ivanov (EldoS Corp.)

As the patch you have found seems to be the only way to make OpenSSH understand X.509 certificates at the moment, we implemented a workaround in exactly the same way you have done it (detecting OpenSSH by its software name). The fix will be included to the future build update.

Thank you for your help.
Also by EldoS: MsgConnect
Cross-platform protocol-independent communication framework for building peer-to-peer and client-server applications and middleware components.



Topic viewed 3629 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!