[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [K12OSN] NX
- From: Rob Owens <rowens ptd net>
- To: "Support list for open source software in schools." <k12osn redhat com>
- Subject: Re: [K12OSN] NX
- Date: Tue, 30 Oct 2007 14:53:53 -0400
I think CentOS (and probably Fedora) packages for nxserver automatically generate their own server key instead of using the default nomachine key. You can generate the nomachine key on the server by running "nxsetup --setup-nomachine-key".
This will make your client configuration simpler (they will by default have the correct key), but it's slightly less secure in that you cannot be positive that your client is communicating with *your* server (and not a man-in-the-middle server). On a small local network this isn't really an issue. Over the internet, though, it could be exploited.
-Rob
On Tue, Oct 30, 2007 at 11:22:43AM -0500, Daniel Kuecker wrote:
> I tried both keys and both failed. when I look at the client file it appears to be the nomachine key. is there a way to reset the keys?
>
> >>> Nils Breunese <nils breun nl> 10/29/07 4:51 PM >>>
> Craig White wrote:
>
> > protocol 1 would use authorized_keys
> > protocol 2 would use authorized_keys2
> >
> > I am no expert on this stuff but that is my understanding.
>
> This used to be the case, but is not generally true anymore. This
> depends on your distribution I believe. On Red Hat / CentOS / Fedora
> you can just use authorized_keys for protocol version 2. I don't know
> if you have to add the '2' on Debian / Ubuntu, but I usually see
> authorized_keys2 in howto's for Debian / Ubuntu. Maybe it works
> without the '2' on those distributions as well, I don't know.
>
> Nils Breunese.
>
>
>
>
>
> _______________________________________________
> K12OSN mailing list
> K12OSN redhat com
> https://www.redhat.com/mailman/listinfo/k12osn
> For more info see <http://www.k12os.org>
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]