[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] libvirt tls vnc

Michael Kress napsal(a):

Radek Hladik wrote:
Michael Kress napsal(a):
2009.02.26 19:09:44 LOG3[14644:3086588128 <http://www.snapanumber.com/>]: error stack: 140B3009 :
error:140B3009:SSL routines:SSL_CTX_use_RSAPrivateKey_file:PEM lib
2009.02.26 19:09:44 LOG3[14644:3086588128 <http://www.snapanumber.com/>]:
SSL_CTX_use_RSAPrivateKey_file: 906D06C: error:0906D06C:PEM
routines:PEM_read_bio:no start line
vncviewer: VNC server closed connection

the above error is gone now.

Stunnel can not find private key. It tries to locate it in
client-cert.pem (I do not know why). Either change this in
configuration   or appen client-key.pem to client-cert.pem. The PEM
file can contain both certificate and private key and stunnel will
handle it.

I did this now, i.e. I merged the client certificate and the private key
into one file called client-cert.pem, first the cert, then the key.

What I still had to do:
Check the (advanced) option "Server uses VeNCrypt SSL encryption",
because without it I got the following error:
"SSL_Connect: 1204F10B: error:1408F10B:SSL
routines:SSL3_GET_RECORD:wrong version number"

It works by executing these steps :
1) ./ssvnc -cacert cacert.pem -mycert client-cert.pem -ssl localhost:0
2) See the session fail
3) Check "Server uses VeNCrypt SSL encryption"
4) Reconnect

As soon as I stay here, it's ok, but when I close ssvnc, the above
setting won't get saved.

My questions:
1) Isn't there a more comfortable end user compatible method to connect
to the beast?
(Because with this method, users obviously are urged to have Linux on
the client side. Or would the purchase of real vnc enterprise edition
would be the solution there?)
2) I simulated an interested user owning a certificate and walked
through the different screens of the host (before, I created a few). I
could easily access them by just chosing to connect to "localhost:0"
"localhost:1" ... (given the requirement to have an ssh tunnel which the
client machine easily can build)
Is it possible to let him only view what he's supposed to? How?
3) Is there a way to stick one certificate to one virtual machine?
e.g. stick client-cert-user001.pem to /etc/libvirt-bin/qemu/user001-vm01.xml
(trying to find a solution to question 2) with this question).

Thanks very much for your help so far, I really appreciate it!
Kind Regards

O.K. I think we are mixing a few things here altogether.
The scenario I mentioned involves ssvnc as a client (linux or windows) connecting via SSL/TLS to a stunnel on the beast and this stunnel connecting to localhost-only-listening VNC server without encryption itself. It looks like ssvnc can store a profiles and run with such a profile from a script so it should be easy to provide script that runs it (although I haven't tested it yet). I did test this scenario and it works and on the client side (windows) it was rather user friendly. The drawback of this is an identification of the connecting client, you may end up with creating CA for every VM or with some certificate common name filtering. Stunnel can verify client's certificate against given CA certificate so it is definetly doable. And you can set VNC password, which should be sufficient as the valid certificate is needed for the brute force attack on the password. The other option is to use SSH for tunneling and connecting to the localhost-only-listening VNC server without encryption itself. Its almost the same as in the previous case only you do not use X509 certificates but SSH keys. And you do not limit your users by CA issuing the certificate but the user and key they are using. You can specify allowed port-forwards (ssh tunnels) in authorized_keys file on the server. On the other hand you need to create user for such logins. If you would like to have the VeNCrypt function, I think you need ssvnc running on linux. However I do not know about the commercial VNC clients. And I think that the two previous scenarios are more flexible.

The stunnel config used is:

client = no
cert = stunnel.pem

accept = 5901
connect = 5905

and I've made the stunnel.pem with (on Fedora 10)
#cd /etc/pki/tls/certs
#make stunnel.pem

The VM is configured to listen on 5905 bound to localhost without any encryption. You can disable any incoming connections in firewall just to be sure...

On the windows client I run ssvnc, using SSL/TLS connecting to port 5901. Prior a connection I've fetched the certificate and stored it as trusted.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]