The individual owning this blog works for Oracle in Germany. The opinions expressed here are his own, are not necessarily reviewed in advance by anyone but the individual author, and neither Oracle nor any other party necessarily agrees with them.
Monday, September 30. 2013
Since Solaris 11.1 the ssh implementation of Solaris supports the usage of X.509 certificates. There is a tutorial of a colleague that explains the setup however when i linked to it a while ago, i got some mails telling me, that it was a little bit on the hard side to understand. So i thought it would be a nice idea to explain the stuff Hai-May Chao wrote in her article on OTN the LKSF way.
However there are a few differences: I won't explain that much about command lines and - more important - i'm using
Why using certificates
The basic idea of using certificates for ssh is quite simple. In order to get rid of passwords, you have to distribute public keys to the
This issue can be nicely solved by certificate. The system doesn't check if you are for example user
When we want to use certificates, we have to create them. We need a Certificate Authority. When you want to do this for more than just playing around, you have to spend some thoughts about the physical security of the system. May be purchasing a cheap notebook or netbook would be a good idea. A system small enough to put it in a safe. Never attach it to the network. Disable WiFi by hardware so you don't go into the network accidentally. Perhaps by using a wire cutter. Don't leave it alone outside the safe. This notebook is the anchor of trust in your network and you have to trust it that it isn't compromised without a doubt, because with this system you can basically create certificates to be any user in you network. The whole concept is based on concept that this anchor isn't compromised. Perhaps it's even a good idea to protect the system by an RBAC configuration that enforces a two-person-rule so a rogue employee can't make it's own certificates. Glenn Brunette wrote a nice example back in 2005 how to do this and he is even configuring it for a script we will use later on. Perhaps you should even use auditing of the system to the max.
Okay, for this tutorial i won't go into that part. That's to a part because i'm lazy, however it's more about the fear that when i'm missing something in such a part it would be my fault
Okay, let's start with the tutorial.
At first we have to create a Certificate Authority and a certificate for a host and a user.
At first we have to create our Certificate Authority (CA). This will be our anchor of trust. The configuration described in the rest of the document assumes, that when you are able to use the private key of the CA, you are authorised to give a user access to a system by signing the public key of a user or host.
Please keep the password you have just set in mind. You will need it every time when you sign a certificate request in order to create a certificate.
Now we create the server certificate. This certificate will be used by the host to identify towards a client as being really the host the client wants to connect to. For the configuration i will show in this blog entry only one parameter is really important: The common name has to be equal to the hostname. It's the red part in the following output.
Now we sign the certificate request. You will need the password for the private key of the CA here.
Now we have signed certificate for the host.
We have to do pretty much the same for our users. Important for this kind of certificate: The common name in the certificate has to be equal to the username of the user. Again it's the red part in the following output.
We have to sign this certificate request as well. You will need the password for the private key of the CA here, again.
Okay, we have now the certificates we need. Of course other users need their own certificates as well as other hosts need their own certificate. But that should be obvious.
I assume in the tutorial that a user
At first on
We repeat the same on the client.
Futhermore you have to ensureproper resolution of the host names. In this example i will just use
Now repeat the same on the client system
Distributing the keys and certificates
The keys and certificate we created are without use when we do not distribute them. I will to this with scp and use another already existing account on the system.
On the server we need the key file and the certificate for the common name
On the client we need the key and the certificate for the common name
Now we have the certificates we need. Next step is the configuration of the ssh and sshd.
On the server
After the transfer of the keys and certificates by
The next step is changing the PIN of the keystone of the root user.:
This password is needed whenever you want to access keys in the Solaris keystone.
However: As the
The access to keys and certificates is handled by the Solaris Key Management Framework. We need a policy file for
This command leads to a policy file:
Okay, essentially this file is telling you "Don't do a validation of the certificate by using CRL (certificate revocation lists) or OCSP (Online certificate Status Protocol). Search for a matching issuer certificate (the certificate of the CA) in the key store for such certificates (which is a directory) and the mapping from cert to name is done with
Now we add a few lines of configuration to
Okay, the meaning of this statements is quite straight forward: The store of the certificates of the trusted CA is in
But how do we get the private key into the pkcs#11 keystone? That's quite easy. You use the
Why do you need to enter two passwords? The first one is the password to access the key store. The second one is the password protecting the key. The second is stripped off while importing it.
Just one tip: The
I just removed the stuff by using
Now you should be able to import the certificate:
That's all for the moment on the server.
On the client
Your home directory should look like this when using the
We will do some steps as root first. Again we create a policy file for the Key Management Framework of Solaris and put the certificate of the certificate authority in a central directory.
Get back to the normal user privileges by leaving your root shell and change the password of the keystone for user
Now we have to import the key and the certificate for the common name
Okay, that's all on
Please note that i din't imported the host keys and certificates to the client machine or the user certificates and keys to the server machine. Just the certificate of the CA is on both server and it's the piece of information that creates trust between both parties.
There could be hundreds or thousands of servers. As long as you have a certificate with a username in it and there is a user account with that name on the system (locally or by LDAP for example), you can log in to the system with your certificate on your client without a question for a password. This has an important implication. The user
I'm not a fan of testing an ssh configuration just by kicking the
Important to know …
Right after startup you should see something like that:
As soon you see
Now try to log into my server with the X.509:
It's a rather complex and long command line. However it tells ssh a lot of import information. You know most of the statements. We just added the satement
You should see in the client's debug output the check for the host certificate.
Back on the server you should see something like that in the debugging output of the
At the end of it all you should see a nice shell on your system.
Neat works as designed.
Of course it's a little bit cumbersome to type in all this stuff for each login into the system.
If you prefer to type in your key store password every time you log in (as i do), just leave out the
Afterwards you can log into the other server with public key authentication.
Do you want to learn more
OTN: How to Set Up X.509 Support for SunSSH on Oracle Solaris 11
(by Hai-May Chao)
Posted by Joerg Moellenkamp in English, Security, Solaris at 20:25 | Comments (0) | Trackbacks (0)
Related entries by tags:
Display comments as (Linear | Threaded)
The LKSF book
The book with the consolidated Less known Solaris Tutorials is available for download here
Joerg Moellenkamp about tar -x and NFS - or: The devil in the details
Fri, 28.04.2017 13:47
At least with ZFS this isn't c orrect. A rmdir for example do esn't trigger a zil_commit, as long as you don't speci [...]
Thu, 27.04.2017 22:31
You say: "The following dat a modifying procedures are syn chronous: WRITE (with stable f lag set to FILE_SYNC), C [...]
Filip Hristovski about Empty homes
Thu, 23.03.2017 16:00
Great post! As always. What about this situation: a leaf with only memory resource, wit hout a CPU lgroup 2 ( [...]
Tiago Rodrigues Eckhardt about Less known Solaris features: Getting rid of Zombies
Thu, 13.10.2016 15:51
Funny thing, I just found out that there is no equivalent co mmand for Linux.
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Germany License