Referring to these scripts: https://gist.github.com/dcommander/fc608434735026dd8215
It also occurs to me that you might be able to set up a separate fake CA for every user. Then the CA file would effectively become the client certificate. On 7/22/19 3:09 PM, DRC wrote: > It really sounds like you're going down the road of trying to reinvent > SSH. Can you just use SSH tunneling instead? In TurboVNC 3.0, the > Session Manager feature implements automatic authentication + > encryption, which seems to be what you're trying to achieve, but it uses > SSH in order to do so, not VeNCrypt. It basically opens an SSH > connection to the server, starts a new TurboVNC Server session or > generates a new one-time password (OTP) for an existing session by way > of that SSH connection, transmits the OTP to the viewer through the SSH > connection, then re-uses the SSH connection to tunnel the RFB > connection. I don't know how to achieve the same thing with VeNCrypt, > because in VeNCrypt, the encryption layer is fully initialized prior to > authentication. What you basically want is a separate X.509 certificate > to be used for encryption vs. authentication (which I guess would be an > X509X509 security type, using VeNCrypt terminology.) It's technically > feasible. It would involve setting up the encryption layer, then > transmitting the client certificate through that layer to the server for > authentication. However, that functionality doesn't exist in any > current VeNCrypt implementations, nor do I know of any other remote > desktop software that does that. > > Take a look at OTP authentication and see if that might solve some > problems for you. Depending on how you are starting the TurboVNC Server > session, it may be possible for you to transmit the OTP securely to the > viewer, much like the next-gen TurboVNC Session Manager will do. > > On 7/22/19 12:29 PM, Andy wrote: >> Well darn >> >> Basically we have many (15+) servers and many different clients (15+). >> >> We want to allow each one to log in automatically, but have the >> centralized security of the CA so that only known hosts (signed by the >> CA) are able to connect instead of just sharing the password file. >> >> Also we were hoping to keep our authentication consistent - so just be >> able to manage certificates instead of certificates and a password file. >> >> >> >> On Monday, July 22, 2019 at 11:58:41 AM UTC-4, DRC wrote: >> >> That is not possible, and I don't know of any way to make it possible >> without some fairly deep modifications to the VeNCrypt extensions, >> and >> possibly even some deep modifications to the RFB authentication >> protocol >> itself (which would necessitate a new version of that protocol.) >> >> What are you ultimately trying to achieve with this? >> >> On 7/22/19 8:00 AM, Andy wrote: >> > Is it possible to configure it so that the client and the server >> can >> > authenticate via x509 certificates? >> > >> > Currently i have it set up so that the Client validates the servers >> > cert, and then the server validates the client with a password >> file. >> > What I would like to do would be set the client up with its own >> cert and >> > password signed by the same CA instead of using the password file >> > >> > *Server * >> > /opt/TurboVNC/bin/vncserver -SecurityTypes X509Vnc -x509cert >> > /home/csof/ca/certs/localhost.cert.pem -x509key >> > /home/csof/ca/certs/localhost.key.pem -rfbauth /home/csof/ca/t.file >> > >> > * >> > * >> > *Client * >> > /opt/TurboVNC/bin/vncviewer -x509ca /home/csof/ca/certs/CA.cert.pem >> > -passwd /home/csof/ca/t.file -loglevel 100 localhost:1 >> > >> > <what I would like to do> /opt/TurboVNC/bin/vncviewer -x509ca >> > /home/csof/ca/certs/CA.cert.pem -x509cert >> > /home/csof/ca/certs/client.cert.pem -x509key >> > /home/csof/ca/certs/client.key.pem </> >> > I would also need to give the vncserver the CA cert too. >> > >> > Thanks! >> >> -- >> You received this message because you are subscribed to the Google >> Groups "TurboVNC User Discussion/Support" group. >> To unsubscribe from this group and stop receiving emails from it, send >> an email to [email protected] >> <mailto:[email protected]>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/turbovnc-users/4c9ae163-ed29-4d43-b5fa-a1af8498e2e8%40googlegroups.com >> <https://groups.google.com/d/msgid/turbovnc-users/4c9ae163-ed29-4d43-b5fa-a1af8498e2e8%40googlegroups.com?utm_medium=email&utm_source=footer>. > -- You received this message because you are subscribed to the Google Groups "TurboVNC User Discussion/Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/942761d1-ee40-4727-f2c5-7cc6261b186b%40virtualgl.org.
