installed freenx server on CentOS 4 server installed nxclient from nomachine.com on workstation
so far so good.
following directions from web site... http://fedoranews.org/contributors/rick_stout/freenx/
where I tried both /etc/nxserver/client/client.id_dsa.key and /var/lib/nxserver/home/.ssh/client.id_dsa.key
copied them to my workstation and then used the 'import' function in nxclient to import the keys and try to connect and always get the following detail when I failed to connect...
NX> 203 NXSSH running with pid: 21106 NX> 285 Enabling check on switch command NX> 285 Enabling skip of SSH config files NX> 200 Connected to address: 192.168.2.1 on port: 22 NX> 202 Authenticating user: nx NX> 208 Using auth method: publickey NX> 204 Authentication failed.
what's the trick - there is obviously something very important missing from the web page.
Thanks
Craig
On Mon, 2006-01-23 at 16:35, Craig White wrote:
installed freenx server on CentOS 4 server installed nxclient from nomachine.com on workstation
so far so good.
following directions from web site... http://fedoranews.org/contributors/rick_stout/freenx/
where I tried both /etc/nxserver/client/client.id_dsa.key and /var/lib/nxserver/home/.ssh/client.id_dsa.key
copied them to my workstation and then used the 'import' function in nxclient to import the keys and try to connect and always get the following detail when I failed to connect...
Try pasting the text from /etc/nxserver/client/client.id_dsa.key into the nxclient key window and saving it instead of using the import function.
On Mon, 2006-01-23 at 16:42 -0600, Les Mikesell wrote:
On Mon, 2006-01-23 at 16:35, Craig White wrote:
installed freenx server on CentOS 4 server installed nxclient from nomachine.com on workstation
so far so good.
following directions from web site... http://fedoranews.org/contributors/rick_stout/freenx/
where I tried both /etc/nxserver/client/client.id_dsa.key and /var/lib/nxserver/home/.ssh/client.id_dsa.key
copied them to my workstation and then used the 'import' function in nxclient to import the keys and try to connect and always get the following detail when I failed to connect...
Try pasting the text from /etc/nxserver/client/client.id_dsa.key into the nxclient key window and saving it instead of using the import function.
scp /etc/nxserver/client/client.id_dsa.key then import it. works ok for me.
On Mon, 2006-01-23 at 16:42 -0600, Les Mikesell wrote:
On Mon, 2006-01-23 at 16:35, Craig White wrote:
installed freenx server on CentOS 4 server installed nxclient from nomachine.com on workstation
so far so good.
following directions from web site... http://fedoranews.org/contributors/rick_stout/freenx/
where I tried both /etc/nxserver/client/client.id_dsa.key and /var/lib/nxserver/home/.ssh/client.id_dsa.key
copied them to my workstation and then used the 'import' function in nxclient to import the keys and try to connect and always get the following detail when I failed to connect...
Try pasting the text from /etc/nxserver/client/client.id_dsa.key into the nxclient key window and saving it instead of using the import function.
---- that actually got me a lot further...I get 'authentication failed for user craig'
So back on the server, I tried...
nxserver --adduser craig
this seemed to create /home/craig/.ssh/authorized_keys2
nxserver --passwd craig
and set the password but still get the same 'authentication failed for user craig'
???
Craig
On Mon, 2006-01-23 at 15:53 -0700, Craig White wrote:
On Mon, 2006-01-23 at 16:42 -0600, Les Mikesell wrote:
On Mon, 2006-01-23 at 16:35, Craig White wrote:
installed freenx server on CentOS 4 server installed nxclient from nomachine.com on workstation
so far so good.
following directions from web site... http://fedoranews.org/contributors/rick_stout/freenx/
where I tried both /etc/nxserver/client/client.id_dsa.key and /var/lib/nxserver/home/.ssh/client.id_dsa.key
copied them to my workstation and then used the 'import' function in nxclient to import the keys and try to connect and always get the following detail when I failed to connect...
Try pasting the text from /etc/nxserver/client/client.id_dsa.key into the nxclient key window and saving it instead of using the import function.
that actually got me a lot further...I get 'authentication failed for user craig'
So back on the server, I tried...
nxserver --adduser craig
this seemed to create /home/craig/.ssh/authorized_keys2
nxserver --passwd craig
and set the password but still get the same 'authentication failed for user craig'
craig needs to be a real linux user with a passwd who can login via ssh.
On Mon, 2006-01-23 at 17:07 -0600, Johnny Hughes wrote:
On Mon, 2006-01-23 at 15:53 -0700, Craig White wrote:
On Mon, 2006-01-23 at 16:42 -0600, Les Mikesell wrote:
On Mon, 2006-01-23 at 16:35, Craig White wrote:
installed freenx server on CentOS 4 server installed nxclient from nomachine.com on workstation
so far so good.
following directions from web site... http://fedoranews.org/contributors/rick_stout/freenx/
where I tried both /etc/nxserver/client/client.id_dsa.key and /var/lib/nxserver/home/.ssh/client.id_dsa.key
copied them to my workstation and then used the 'import' function in nxclient to import the keys and try to connect and always get the following detail when I failed to connect...
Try pasting the text from /etc/nxserver/client/client.id_dsa.key into the nxclient key window and saving it instead of using the import function.
that actually got me a lot further...I get 'authentication failed for user craig'
So back on the server, I tried...
nxserver --adduser craig
this seemed to create /home/craig/.ssh/authorized_keys2
nxserver --passwd craig
and set the password but still get the same 'authentication failed for user craig'
craig needs to be a real linux user with a passwd who can login via ssh.
---- to answer both you and Les - craig is a real linux user and has a passwd and can login via ssh...
# ssh craig@srv1 craig@srv1's password: Last login: Sun Jan 22 07:31:34 2006 from win-workstation.azapple.com
this is exasperating to say the least.
# ls -l /var/log/nxserver.log -rw------- 1 nx root 0 Jan 23 15:54 /var/log/nxserver.log
since it's empty and /var/log/messages and /var/log/secure also give absolutely no hints
Thanks
Craig
why don't you try strace? It's able to examine running applications too. Try strace -p freenxpid -f -t -o /tmp/logfile
bye, Ago
On Tue, 2006-01-24 at 00:27 +0100, Deim Ágoston wrote:
why don't you try strace? It's able to examine running applications too. Try strace -p freenxpid -f -t -o /tmp/logfile
---- awesome idea...how do you figure out the pid when...
# ps aux|grep nx root 15218 0.0 0.1 4600 664 pts/5 S+ 16:32 0:00 grep nx
doesn't show a process id?
Craig
Try strace -p freenxpid -f -t -o /tmp/logfile
awesome idea...how do you figure out the pid when...
# ps aux|grep nx root 15218 0.0 0.1 4600 664 pts/5 S+ 16:32 0:00 grep nx
doesn't show a process id?
it doesn't show that freenx is running! Are you sure it's started? Try to start it manulay with strace -o /tmp/logfile -f -t /usr/sbin/freenx
(or wherever you installed the binaries)
bye, Ago
On Tue, 2006-01-24 at 00:49 +0100, Deim Ágoston wrote:
Try strace -p freenxpid -f -t -o /tmp/logfile
awesome idea...how do you figure out the pid when...
# ps aux|grep nx root 15218 0.0 0.1 4600 664 pts/5 S+ 16:32 0:00 grep nx
doesn't show a process id?
it doesn't show that freenx is running! Are you sure it's started? Try to start it manulay with strace -o /tmp/logfile -f -t /usr/sbin/freenx
(or wherever you installed the binaries)
---- # nxserver --status NX> 100 NXSERVER - Version 1.4.0-44 OS (GPL) NX> 110 NX Server is running NX> 999 Bye
(hey - I'm just the dummy that started fooling with it).
# strace -o /tmp/logfile -f -t /usr/sbin/nxserver --restart -bash: strace: command not found
I will figure out where it comes from and install it I guess
Craig
On Mon, 2006-01-23 at 16:54 -0700, Craig White wrote:
On Tue, 2006-01-24 at 00:49 +0100, Deim Ágoston wrote:
Try strace -p freenxpid -f -t -o /tmp/logfile
awesome idea...how do you figure out the pid when...
# ps aux|grep nx root 15218 0.0 0.1 4600 664 pts/5 S+ 16:32 0:00 grep nx
doesn't show a process id?
it doesn't show that freenx is running! Are you sure it's started? Try to start it manulay with strace -o /tmp/logfile -f -t /usr/sbin/freenx
(or wherever you installed the binaries)
# nxserver --status NX> 100 NXSERVER - Version 1.4.0-44 OS (GPL) NX> 110 NX Server is running NX> 999 Bye
(hey - I'm just the dummy that started fooling with it).
# strace -o /tmp/logfile -f -t /usr/sbin/nxserver --restart -bash: strace: command not found
I will figure out where it comes from and install it I guess
---- this was pointless - outside of the great log file it created...the trace was only of the nxserver -restart and nothing beyond that so no useful information could be derived. I haven't a clue on which process it would be - I presume that it all starts with an ssh connection...
Craig
this was pointless - outside of the great log file it created...the trace was only of the nxserver -restart and nothing beyond that so no useful information could be derived. I haven't a clue on which process it would be - I presume that it all starts with an ssh connection...
I find strace very useful, usually. It tells me lot of things. Try to look over for ENOENT and EACCESS.
Another question: did you enabled the key authentication in sshd_conf? If sshd didn't accept the connection with keys that could be a problem. Just an idea...
bye, Ago
On Tue, 2006-01-24 at 01:32 +0100, Deim Ágoston wrote:
this was pointless - outside of the great log file it created...the trace was only of the nxserver -restart and nothing beyond that so no useful information could be derived. I haven't a clue on which process it would be - I presume that it all starts with an ssh connection...
I find strace very useful, usually. It tells me lot of things. Try to look over for ENOENT and EACCESS.
---- leaving no stone unturned...
[root@srv1 etc]# grep ENOENT /tmp/logfile 15546 16:54:58 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) 15549 16:54:58 stat64("/usr/kerberos/sbin/dirname", 0xbfece320) = -1 ENOENT (No such file or directory) 15549 16:54:58 stat64("/usr/kerberos/bin/dirname", 0xbfece320) = -1 ENOENT (No such file or directory) 15549 16:54:58 stat64("/usr/local/sbin/dirname", 0xbfece320) = -1 ENOENT (No such file or directory) 15549 16:54:58 stat64("/usr/local/bin/dirname", 0xbfece320) = -1 ENOENT (No such file or directory) 15549 16:54:58 stat64("/sbin/dirname", 0xbfece320) = -1 ENOENT (No such file or directory) 15549 16:54:58 stat64("/bin/dirname", 0xbfece320) = -1 ENOENT (No such file or directory) 15549 16:54:58 stat64("/usr/sbin/dirname", 0xbfece320) = -1 ENOENT (No such file or directory) 15550 16:54:58 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) 15547 16:54:58 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) 15551 16:54:58 stat64("/usr/kerberos/sbin/hostname", 0xbfece930) = -1 ENOENT (No such file or directory) 15551 16:54:58 stat64("/usr/kerberos/bin/hostname", 0xbfece930) = -1 ENOENT (No such file or directory) 15551 16:54:58 stat64("/usr/local/sbin/hostname", 0xbfece930) = -1 ENOENT (No such file or directory) 15551 16:54:58 stat64("/usr/local/bin/hostname", 0xbfece930) = -1 ENOENT (No such file or directory) 15551 16:54:58 stat64("/sbin/hostname", 0xbfece930) = -1 ENOENT (No such file or directory) 15552 16:54:58 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) 15553 16:54:58 stat64("/usr/kerberos/sbin/uname", 0xbfece930) = -1 ENOENT (No such file or directory) 15553 16:54:58 stat64("/usr/kerberos/bin/uname", 0xbfece930) = -1 ENOENT (No such file or directory) 15553 16:54:58 stat64("/usr/local/sbin/uname", 0xbfece930) = -1 ENOENT (No such file or directory) 15553 16:54:58 stat64("/usr/local/bin/uname", 0xbfece930) = -1 ENOENT (No such file or directory) 15553 16:54:58 stat64("/sbin/uname", 0xbfece930) = -1 ENOENT (No such file or directory) 15554 16:54:59 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) 15546 16:54:59 stat64("/etc/nxserver/node.conf.d", 0xbfecee80) = -1 ENOENT (No such file or directory) 15546 16:54:59 stat64("/etc/nxserver/root.node.conf", 0xbfececf0) = -1 ENOENT (No such file or directory) 15546 16:54:59 stat64("/usr/kerberos/sbin/mv", 0xbfece770) = -1 ENOENT (No such file or directory) 15546 16:54:59 stat64("/usr/kerberos/bin/mv", 0xbfece770) = -1 ENOENT (No such file or directory) 15546 16:54:59 stat64("/usr/local/sbin/mv", 0xbfece770) = -1 ENOENT (No such file or directory) 15546 16:54:59 stat64("/usr/local/bin/mv", 0xbfece770) = -1 ENOENT (No such file or directory) 15546 16:54:59 stat64("/sbin/mv", 0xbfece770) = -1 ENOENT (No such file or directory) 15555 16:54:59 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) 15555 16:54:59 stat64("/var/lib/nxserver/home/.ssh/authorized_keys2.disabled", 0xbfeab4d0) = -1 ENOENT (No such file or directory) 15555 16:54:59 lstat64("/var/lib/nxserver/home/.ssh/authorized_keys2.disabled", 0xbfeab3c0) = -1 ENOENT (No such file or directory) 15546 16:54:59 stat64("/var/lib/nxserver/home/.ssh/authorized_keys2", 0xbfece5a0) = -1 ENOENT (No such file or directory) 15556 16:54:59 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) 15556 16:54:59 stat64("/var/lib/nxserver/home/.ssh/authorized_keys2", 0xbfe2f4d0) = -1 ENOENT (No such file or directory) 15556 16:54:59 lstat64("/var/lib/nxserver/home/.ssh/authorized_keys2", 0xbfe2f3c0) = -1 ENOENT (No such file or directory)
[root@srv1 etc]# grep EACCESS /tmp/logfile [root@srv1 etc]#
I still don't see how this issue matters since this is the nxserver startup strace - it dies after the server starts up but no trace of attempt to login occurs ----
Another question: did you enabled the key authentication in sshd_conf? If sshd didn't accept the connection with keys that could be a problem. Just an idea...
---- yes but I think by default, PubkeyAuthentication is on as I have been doing it with another machine since the day I set up the server. For S & G's though, I did remove the comment and restarted sshd service...
# grep Pubkey /etc/ssh/sshd_config PubkeyAuthentication yes
I don't think I am getting anywhere on this but thought I would fill in the replies just in case.
Thanks
Craig
On Mon, 2006-01-23 at 22:57, Craig White wrote:
15556 16:54:59 stat64("/var/lib/nxserver/home/.ssh/authorized_keys2", 0xbfe2f4d0) = -1 ENOENT (No such file or directory) 15556 16:54:59 lstat64("/var/lib/nxserver/home/.ssh/authorized_keys2", 0xbfe2f3c0) = -1 ENOENT (No such file or directory)
Doesn't that file exist? Or is this really a SELinux access error?
On Mon, 2006-01-23 at 23:33 -0600, Les Mikesell wrote:
On Mon, 2006-01-23 at 22:57, Craig White wrote:
15556 16:54:59 stat64("/var/lib/nxserver/home/.ssh/authorized_keys2", 0xbfe2f4d0) = -1 ENOENT (No such file or directory) 15556 16:54:59 lstat64("/var/lib/nxserver/home/.ssh/authorized_keys2", 0xbfe2f3c0) = -1 ENOENT (No such file or directory)
Doesn't that file exist? Or is this really a SELinux access error?
---- yes it exists. No - not an SELinux error. Just the nonsense from a useless strace.
I think I know the issue.
I copied client.id_dsa.key to lin-workstation:/home/craig/.ssh/authorized_keys2 and still can't use Pubkey authentication as user nx - which tells me that the underlying system on the server isn't getting the value of the public key from /var/lib/nxserver/home/.ssh/
I'm not sure how to handle this
Craig
On Mon, 2006-01-23 at 23:38, Craig White wrote:
15556 16:54:59 stat64("/var/lib/nxserver/home/.ssh/authorized_keys2", 0xbfe2f4d0) = -1 ENOENT (No such file or directory) 15556 16:54:59 lstat64("/var/lib/nxserver/home/.ssh/authorized_keys2", 0xbfe2f3c0) = -1 ENOENT (No such file or directory)
Doesn't that file exist? Or is this really a SELinux access error?
yes it exists. No - not an SELinux error. Just the nonsense from a useless strace.
It's not nonsense. The system call told the app the file doesn't exist.
I think I know the issue.
I copied client.id_dsa.key to lin-workstation:/home/craig/.ssh/authorized_keys2 and still can't use Pubkey authentication as user nx - which tells me that the underlying system on the server isn't getting the value of the public key from /var/lib/nxserver/home/.ssh/
That's not surprising if it is failing to read the files there. Are they owned by user nx?
On Mon, 2006-01-23 at 23:48 -0600, Les Mikesell wrote:
On Mon, 2006-01-23 at 23:38, Craig White wrote:
15556 16:54:59 stat64("/var/lib/nxserver/home/.ssh/authorized_keys2", 0xbfe2f4d0) = -1 ENOENT (No such file or directory) 15556 16:54:59 lstat64("/var/lib/nxserver/home/.ssh/authorized_keys2", 0xbfe2f3c0) = -1 ENOENT (No such file or directory)
Doesn't that file exist? Or is this really a SELinux access error?
yes it exists. No - not an SELinux error. Just the nonsense from a useless strace.
It's not nonsense. The system call told the app the file doesn't exist.
I think I know the issue.
I copied client.id_dsa.key to lin-workstation:/home/craig/.ssh/authorized_keys2 and still can't use Pubkey authentication as user nx - which tells me that the underlying system on the server isn't getting the value of the public key from /var/lib/nxserver/home/.ssh/
That's not surprising if it is failing to read the files there. Are they owned by user nx?
---- I've already posted the output. The files are there, they are readable by user nx - I've not mucked with any of the privileges of any of the files or subdirectories in the path. The permissions of everything seems fine.
This is a very clean install.
What I have discovered is this...
if I copy the file client.id_dsa.key to the client machine, and rename it - i.e. cp client.id_dsa.key ~/.ssh/id_dsa
and then on the server...
cp /var/lib/nxserver/home/.ssh/authorized_keys2 /var/lib/nxserver/home/.ssh/authorized_keys and chown nx /var/lib/nxserver/home/.ssh/authorized_keys
I can then login in from my client via ssh using pubkey (finally)
$ ssh nx@srv1.azapple.com HELLO NXSERVER - Version 1.4.0-44 OS (GPL) NX> 105 exit exit Exit NX> 999 Bye Connection to srv1.azapple.com closed.
I haven't translated this into a successful login from nxclient but I think this helps
Craig
On Mon, 2006-01-23 at 23:48 -0600, Les Mikesell wrote:
On Mon, 2006-01-23 at 23:38, Craig White wrote:
15556 16:54:59 stat64("/var/lib/nxserver/home/.ssh/authorized_keys2", 0xbfe2f4d0) = -1 ENOENT (No such file or directory) 15556 16:54:59 lstat64("/var/lib/nxserver/home/.ssh/authorized_keys2", 0xbfe2f3c0) = -1 ENOENT (No such file or directory)
Doesn't that file exist? Or is this really a SELinux access error?
yes it exists. No - not an SELinux error. Just the nonsense from a useless strace.
It's not nonsense. The system call told the app the file doesn't exist.
I think I know the issue.
I copied client.id_dsa.key to lin-workstation:/home/craig/.ssh/authorized_keys2 and still can't use Pubkey authentication as user nx - which tells me that the underlying system on the server isn't getting the value of the public key from /var/lib/nxserver/home/.ssh/
That's not surprising if it is failing to read the files there. Are they owned by user nx?
----- this is a debug - level 3 of ssh of an attempted login via nxclient - does this offer any clues?
Jan 23 23:01:32 srv1 sshd[20946]: debug3: fd 4 is not O_NONBLOCK Jan 23 23:01:32 srv1 sshd[21430]: debug1: rexec start in 4 out 4 newsock 4 pipe 6 sock 7 Jan 23 23:01:32 srv1 sshd[20946]: debug1: Forked child 21430. Jan 23 23:01:32 srv1 sshd[20946]: debug3: send_rexec_state: entering fd = 7 config len 430 Jan 23 23:01:32 srv1 sshd[20946]: debug3: ssh_msg_send: type 0 Jan 23 23:01:32 srv1 sshd[20946]: debug3: send_rexec_state: done Jan 23 23:01:32 srv1 sshd[21430]: debug1: inetd sockets after dupping: 3, 3 Jan 23 23:01:32 srv1 sshd[21430]: Connection from 192.168.2.10 port 49278 Jan 23 23:01:32 srv1 sshd[21430]: debug1: Client protocol version 2.0; client software version OpenSSH_3.9p1 Jan 23 23:01:32 srv1 sshd[21430]: debug1: match: OpenSSH_3.9p1 pat OpenSSH* Jan 23 23:01:32 srv1 sshd[21430]: debug1: Enabling compatibility mode for protocol 2.0 Jan 23 23:01:32 srv1 sshd[21430]: debug1: Local version string SSH-1.99-OpenSSH_3.9p1 Jan 23 23:01:32 srv1 sshd[21430]: debug2: fd 3 setting O_NONBLOCK Jan 23 23:01:32 srv1 sshd[21430]: debug2: Network child is on pid 21433 Jan 23 23:01:32 srv1 sshd[21430]: debug3: preauth child monitor started Jan 23 23:01:32 srv1 sshd[21430]: debug3: mm_request_receive entering Jan 23 23:01:32 srv1 sshd[21430]: debug3: monitor_read: checking request 0 Jan 23 23:01:32 srv1 sshd[21430]: debug3: mm_answer_moduli: got parameters: 1024 1024 8192 Jan 23 23:01:32 srv1 sshd[21430]: debug3: mm_request_send entering: type 1 Jan 23 23:01:32 srv1 sshd[21430]: debug2: monitor_read: 0 used once, disabling now Jan 23 23:01:32 srv1 sshd[21430]: debug3: mm_request_receive entering Jan 23 23:01:32 srv1 sshd[21430]: debug3: monitor_read: checking request 5 Jan 23 23:01:32 srv1 sshd[21430]: debug3: mm_answer_sign Jan 23 23:01:32 srv1 sshd[21430]: debug3: mm_answer_sign: signature 0x9c33058(143) Jan 23 23:01:32 srv1 sshd[21430]: debug3: mm_request_send entering: type 6 Jan 23 23:01:32 srv1 sshd[21430]: debug2: monitor_read: 5 used once, disabling now Jan 23 23:01:32 srv1 sshd[21430]: debug3: mm_request_receive entering Jan 23 23:01:32 srv1 sshd[21430]: debug3: monitor_read: checking request 7 Jan 23 23:01:32 srv1 sshd[21430]: debug3: mm_answer_pwnamallow Jan 23 23:01:32 srv1 sshd[21430]: debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1 Jan 23 23:01:32 srv1 sshd[21430]: debug3: mm_request_send entering: type 8 Jan 23 23:01:32 srv1 sshd[21430]: debug2: monitor_read: 7 used once, disabling now Jan 23 23:01:32 srv1 sshd[21430]: debug3: mm_request_receive entering Jan 23 23:01:32 srv1 sshd[21430]: debug3: monitor_read: checking request 46 Jan 23 23:01:32 srv1 sshd[21430]: debug1: PAM: initializing for "nx" Jan 23 23:01:32 srv1 sshd[21430]: debug3: Trying to reverse map address 192.168.2.10. Jan 23 23:01:32 srv1 sshd[21430]: debug1: PAM: setting PAM_RHOST to "lin-workstation.azapple.com" Jan 23 23:01:32 srv1 sshd[21430]: debug1: PAM: setting PAM_TTY to "ssh" Jan 23 23:01:32 srv1 sshd[21430]: debug2: monitor_read: 46 used once, disabling now Jan 23 23:01:32 srv1 sshd[21430]: debug3: mm_request_receive entering Jan 23 23:01:32 srv1 sshd[21430]: debug3: monitor_read: checking request 3 Jan 23 23:01:32 srv1 sshd[21430]: debug3: mm_answer_authserv: service=ssh-connection, style= Jan 23 23:01:32 srv1 sshd[21430]: debug2: monitor_read: 3 used once, disabling now Jan 23 23:01:32 srv1 sshd[21430]: debug3: mm_request_receive entering Jan 23 23:01:32 srv1 sshd[21430]: debug3: monitor_read: checking request 4 Jan 23 23:01:32 srv1 sshd[21430]: debug3: mm_answer_authrole: role= Jan 23 23:01:32 srv1 sshd[21430]: debug2: monitor_read: 4 used once, disabling now Jan 23 23:01:32 srv1 sshd[21430]: debug3: mm_request_receive entering Jan 23 23:01:32 srv1 sshd[21430]: debug1: do_cleanup Jan 23 23:01:32 srv1 sshd[21430]: debug1: PAM: cleanup Jan 23 23:01:32 srv1 sshd[21430]: debug3: PAM: sshpam_thread_cleanup entering
Craig
Doesn't that file exist? Or is this really a SELinux access error?
# ls -Zald / /var /var/lib /var/lib/nxserver \ /var/lib/nxserver/home /var/lib/nxserver/home/.ssh \ /var/lib/nxserver/home/.ssh/authorized_keys2
drwxr-xr-x 25 system_u:object_r:root_t root root / drwxr-xr-x 31 system_u:object_r:var_t root root /var drwxr-xr-x 29 system_u:object_r:var_lib_t root root /var/lib drwx------ 4 system_u:object_r:var_lib_t nx root /var/lib/nxserver drwx------ 4 root:object_r:var_lib_t nx root /var/lib/nxserver/home drwx------ 2 root:object_r:var_lib_t nx root /var/lib/nxserver/home/.ssh -rw-r----- 1 root:object_r:var_lib_t nx root /var/lib/nxserver/home/.ssh/authorized_keys2
Make sure all the permissions are correct...
Cheers, MaZe.
This is what worked for me on CentOS 4.2:
I followed the advice on Rick Stout's page after reading about problem's earlier with the CentOS freenx and nx packages: http://fedoranews.org/contributors/rick_stout/freenx/ and downloaded these packages from that site:
nx-1.5.0-4.FC3.1 freenx-0.4.4-1.fdr.0
Then, for testing I installed the Linux nxclient package from the nomachine.com site (nxclient-1.5.0-135) on the same system (server), imported the key and was able to connect and start a second X desktop. (This messes up some groupsettings on files in your home-dir so better use a testuser account.
I'm not sure if this will solve anything because at first I tested with the CentOS packages but with an older client and without importing keys (which should work with the included key from Nomachine.com, but didn't). Does anybody know how to get this working on CentOS ? It does work when trying to connect to a Knoppix-booted 'nx terminal server' system. It needs a system (default knoppix) user though.
Paul
On Tuesday 24 January 2006 10:41, Maciej Żenczykowski wrote:
Doesn't that file exist? Or is this really a SELinux access error?
# ls -Zald / /var /var/lib /var/lib/nxserver \ /var/lib/nxserver/home /var/lib/nxserver/home/.ssh \ /var/lib/nxserver/home/.ssh/authorized_keys2
drwxr-xr-x 25 system_u:object_r:root_t root root / drwxr-xr-x 31 system_u:object_r:var_t root root /var drwxr-xr-x 29 system_u:object_r:var_lib_t root root /var/lib drwx------ 4 system_u:object_r:var_lib_t nx root /var/lib/nxserver drwx------ 4 root:object_r:var_lib_t nx root /var/lib/nxserver/home drwx------ 2 root:object_r:var_lib_t nx root /var/lib/nxserver/home/.ssh -rw-r----- 1 root:object_r:var_lib_t nx root /var/lib/nxserver/home/.ssh/authorized_keys2
Make sure all the permissions are correct...
Cheers, MaZe. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Tue, 2006-01-24 at 13:29 +0100, Paul Schoonderwoerd wrote:
This is what worked for me on CentOS 4.2:
I followed the advice on Rick Stout's page after reading about problem's earlier with the CentOS freenx and nx packages: http://fedoranews.org/contributors/rick_stout/freenx/ and downloaded these packages from that site:
nx-1.5.0-4.FC3.1 freenx-0.4.4-1.fdr.0
Then, for testing I installed the Linux nxclient package from the nomachine.com site (nxclient-1.5.0-135) on the same system (server), imported the key and was able to connect and start a second X desktop. (This messes up some groupsettings on files in your home-dir so better use a testuser account.
I'm not sure if this will solve anything because at first I tested with the CentOS packages but with an older client and without importing keys (which should work with the included key from Nomachine.com, but didn't). Does anybody know how to get this working on CentOS ? It does work when trying to connect to a Knoppix-booted 'nx terminal server' system. It needs a system (default knoppix) user though.
There was a problem a long time ago with one version of nx/freenx for CentOS ... it now works OK.
I will verify that I am using the latest clients from nomachine. I was earlier this month
ok ... all these connecting clients connecting to a CentOS-4 freenx/nx server via port 22 and encrypt traffic mode on the client:
Windows version of client 1.5.0-138 (on WinXP) ... works perfect
Windows version of client 1.5.0-138 (on Win2000) ... works perfect
Windows version of client 1.5.0-138 (on Win2003 Server) ... works perfect
Linux version of client 1.5.0-135 (on CentOS-3) ... works perfect
Linux version of client 1.5.0-135 (on CentOS-4) ... works perfect
Linux version of client 1.5.0-135 (on FedoraCore-3) ... works perfect
On Tue, 2006-01-24 at 10:41 +0100, Maciej Żenczykowski wrote:
Doesn't that file exist? Or is this really a SELinux access error?
# ls -Zald / /var /var/lib /var/lib/nxserver \ /var/lib/nxserver/home /var/lib/nxserver/home/.ssh \ /var/lib/nxserver/home/.ssh/authorized_keys2
drwxr-xr-x 25 system_u:object_r:root_t root root / drwxr-xr-x 31 system_u:object_r:var_t root root /var drwxr-xr-x 29 system_u:object_r:var_lib_t root root /var/lib drwx------ 4 system_u:object_r:var_lib_t nx root /var/lib/nxserver drwx------ 4 root:object_r:var_lib_t nx root /var/lib/nxserver/home drwx------ 2 root:object_r:var_lib_t nx root /var/lib/nxserver/home/.ssh -rw-r----- 1 root:object_r:var_lib_t nx root /var/lib/nxserver/home/.ssh/authorized_keys2
Make sure all the permissions are correct...
---- # ls -Zald /var /var/lib /var/lib/nxserver/home /var/lib/nxserver/home/.ssh drwxr-xr-x 26 system_u:object_r:var_t root root 4096 Sep 11 06:09 /var drwxr-xr-x 26 system_u:object_r:var_lib_t root root 4096 Jan 24 08:03 /var/lib drwx------ 4 root:object_r:var_lib_t nx root 4096 Jan 24 08:03 /var/lib/nxserver/home drwx------ 2 root:object_r:var_lib_t nx root 4096 Jan 24 08:03 /var/lib/nxserver/home/.ssh
# ls -Zl /var/lib/nxserver/home/.ssh/ total 32 -rw-r----- 1 root:object_r:var_lib_t nx root 611 Jan 24 08:03 authorized_keys2 -rw------- 1 root:object_r:var_lib_t nx root 668 Jan 24 08:03 client.id_dsa.key -rw-r--r-- 1 root:object_r:var_lib_t nx root 220 Jan 24 08:03 known_hosts -rw------- 1 root:object_r:var_lib_t nx root 611 Jan 24 08:03 server.id_dsa.pub.key
Looks OK to me
Craig
On Mon, 2006-01-23 at 17:07 -0700, Craig White wrote:
On Mon, 2006-01-23 at 16:54 -0700, Craig White wrote:
On Tue, 2006-01-24 at 00:49 +0100, Deim Ágoston wrote:
Try strace -p freenxpid -f -t -o /tmp/logfile
awesome idea...how do you figure out the pid when...
# ps aux|grep nx root 15218 0.0 0.1 4600 664 pts/5 S+ 16:32 0:00 grep nx
doesn't show a process id?
it doesn't show that freenx is running! Are you sure it's started? Try to start it manulay with strace -o /tmp/logfile -f -t /usr/sbin/freenx
(or wherever you installed the binaries)
# nxserver --status NX> 100 NXSERVER - Version 1.4.0-44 OS (GPL) NX> 110 NX Server is running NX> 999 Bye
(hey - I'm just the dummy that started fooling with it).
# strace -o /tmp/logfile -f -t /usr/sbin/nxserver --restart -bash: strace: command not found
I will figure out where it comes from and install it I guess
this was pointless - outside of the great log file it created...the trace was only of the nxserver -restart and nothing beyond that so no useful information could be derived. I haven't a clue on which process it would be - I presume that it all starts with an ssh connection...
OK ... lets start over :)
remove everything on the server and then do this on the server:
yum install nx freenx
Then download and install the latest client from nomachine.org on the client.
then ssh into the server from the client and on the server edit the file:
/etc/nxserver/client.id_dsa.key and copy/paste it into the Window that shows up when you press the "Key" button, then press "Save".
Make sure to check the box that says "Enable encryption of all traffic"
That should do it...
On Mon, 2006-01-23 at 18:46 -0600, Johnny Hughes wrote:
On Mon, 2006-01-23 at 17:07 -0700, Craig White wrote:
On Mon, 2006-01-23 at 16:54 -0700, Craig White wrote:
On Tue, 2006-01-24 at 00:49 +0100, Deim Ágoston wrote:
Try strace -p freenxpid -f -t -o /tmp/logfile
awesome idea...how do you figure out the pid when...
# ps aux|grep nx root 15218 0.0 0.1 4600 664 pts/5 S+ 16:32 0:00 grep nx
doesn't show a process id?
it doesn't show that freenx is running! Are you sure it's started? Try to start it manulay with strace -o /tmp/logfile -f -t /usr/sbin/freenx
(or wherever you installed the binaries)
# nxserver --status NX> 100 NXSERVER - Version 1.4.0-44 OS (GPL) NX> 110 NX Server is running NX> 999 Bye
(hey - I'm just the dummy that started fooling with it).
# strace -o /tmp/logfile -f -t /usr/sbin/nxserver --restart -bash: strace: command not found
I will figure out where it comes from and install it I guess
this was pointless - outside of the great log file it created...the trace was only of the nxserver -restart and nothing beyond that so no useful information could be derived. I haven't a clue on which process it would be - I presume that it all starts with an ssh connection...
OK ... lets start over :)
remove everything on the server and then do this on the server:
yum install nx freenx
Then download and install the latest client from nomachine.org on the client.
then ssh into the server from the client and on the server edit the file:
/etc/nxserver/client.id_dsa.key and copy/paste it into the Window that shows up when you press the "Key" button, then press "Save".
Make sure to check the box that says "Enable encryption of all traffic"
That should do it...
---- [root@srv1 nxserver]# yum install nx freenx Setting up Install Process Setting up repositories dag 100% |=========================| 1.1 kB 00:00 update 100% |=========================| 951 B 00:00 rpmforge 100% |=========================| 1.1 kB 00:00 base 100% |=========================| 1.1 kB 00:00 addons 100% |=========================| 951 B 00:00 extras 100% |=========================| 1.1 kB 00:00 Reading repository metadata in from local files Parsing package install arguments Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package nx.i386 0:1.5.0-1.centos4 set to be updated ---> Package freenx.noarch 0:0.4.4-1.centos4 set to be updated --> Running transaction check
Dependencies Resolved
============================================================================= Package Arch Version Repository Size ============================================================================= Installing: freenx noarch 0.4.4-1.centos4 extras 53 k nx i386 1.5.0-1.centos4 extras 2.5 M
Transaction Summary ============================================================================= Install 2 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 2.5 M Is this ok [y/N]: y Downloading Packages: Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Installing: nx ######################### [1/2] Installing: freenx ######################### [2/2] Stopping sshd:[ OK ] Starting sshd:[ OK ]
Installed: freenx.noarch 0:0.4.4-1.centos4 nx.i386 0:1.5.0-1.centos4 Complete! [root@srv1 nxserver]# cat /etc/nxserver/client.id_dsa.key -----BEGIN DSA PRIVATE KEY----- MIIBugIBAAKBgQDBskKR9sORJnvfaapZj9WTx4qtxqG7/EkGGK3xXsps7O1EWGY0 SZOmWByUndSJrubi9xD7yU+m7t6gs7ryh3n9MilekLdAH6LoeNqLY9k3s0DAykBA LXWUA5DSfZ+rYL+AbQutw0VQhfXxC5XCrc1sOgaOPrXPRkUxMATbw1I8SwIVAJNT oQef7sTe4IoaCAi0piUxcUQzAoGARC0uLYlLcZUJ8Td2uu8COHuq8M+xnj2h7aD+ wVrvNQhwvSfTuBf4KUEoLX8Y0rHNA/lFtjO0cg0JXUA1apXSUJAbfFmQBK1MWk8L rOlecL0dUt+6Yv5HMFvbmUH25y1phKfQclZOFCYTVE824EoQQSpLSAtBFAFb+rQK 09MdltACgYB4FtfLpqWAII19htxZrasQD6XPE625u1koLjopitaU3aSlinmdAzuh novwgc9iOLguWd1QU7+NOkmdfcy6iYkHtzMDa+oqDtTkEd+tXhPTVQEUS4sEEtAb 4pwPlIlnXiwSb01encGg3W0FrJyEFd2644rBeDqr5RYPx/UIylTuGwIUWYS+lZgb XvkxbNEuY5Qk6gnkKUc= -----END DSA PRIVATE KEY-----
You will have to trust that I...
copied the above key (that which was between the ----BEGIN and -----END but not including those lines) and pasted into the key section and that I also went into 'configure -> advanced' and checked the box 'enable SSL traffic for communication' and I also made sure that...
# grep Pubkey /etc/ssh/sshd_config PubkeyAuthentication yes
prior to restarting SSHD on the server which happens automatically when you install freenx.
No change - unable to authenticate user craig though clearly I can authenticate as user craig from console...
[root@lin-workstation opt]# ssh craig@srv1 craig@srv1's password: Last login: Mon Jan 23 17:03:14 2006 from localhost.localdomain [craig@srv1 ~]$
as for the client... # rpm -q nxclient nxclient-1.5.0-135
that's on FC-4 though
Thanks - no workee
and by the way...2 things really bother me but since I can't make it work as it is, I'm not changing them...
1 - there is no /etc/nxserver/node.conf #only node.conf.sample
2 - the pub key I listed above apparently is the one distributed with the binary and that would seem to be a security issue
Craig
Craig
On Mon, 2006-01-23 at 20:53, Craig White wrote:
and by the way...2 things really bother me but since I can't make it work as it is, I'm not changing them...
1 - there is no /etc/nxserver/node.conf #only node.conf.sample
That's normal.
2 - the pub key I listed above apparently is the one distributed with the binary and that would seem to be a security issue
It is only used for the initial connection so the real login and password are sent over an encrypted channel. You can't do anything else with the nx user login - and you could generate new keys if you wanted. But, you should be seeing sshd[18876]: Accepted publickey for nx ... entries in /var/log/secure if the key is working.
On Mon, 2006-01-23 at 21:19 -0600, Les Mikesell wrote:
On Mon, 2006-01-23 at 20:53, Craig White wrote:
and by the way...2 things really bother me but since I can't make it work as it is, I'm not changing them...
1 - there is no /etc/nxserver/node.conf #only node.conf.sample
That's normal.
2 - the pub key I listed above apparently is the one distributed with the binary and that would seem to be a security issue
It is only used for the initial connection so the real login and password are sent over an encrypted channel. You can't do anything else with the nx user login - and you could generate new keys if you wanted. But, you should be seeing sshd[18876]: Accepted publickey for nx ... entries in /var/log/secure if the key is working.
---- clearly I am not getting anything in /var/log/secure (on the server) that says anything about nx user except when the nx user was created the first time I installed freenx/nx
;-(
Craig
On Mon, 2006-01-23 at 21:27, Craig White wrote:
and by the way...2 things really bother me but since I can't make it work as it is, I'm not changing them...
1 - there is no /etc/nxserver/node.conf #only node.conf.sample
That's normal.
2 - the pub key I listed above apparently is the one distributed with the binary and that would seem to be a security issue
It is only used for the initial connection so the real login and password are sent over an encrypted channel. You can't do anything else with the nx user login - and you could generate new keys if you wanted. But, you should be seeing sshd[18876]: Accepted publickey for nx ... entries in /var/log/secure if the key is working.
clearly I am not getting anything in /var/log/secure (on the server) that says anything about nx user except when the nx user was created the first time I installed freenx/nx
I think you have a problem with the client or key. If I alter the key I don't see any log entry for the failure.
On Mon, 2006-01-23 at 21:42 -0600, Les Mikesell wrote:
On Mon, 2006-01-23 at 21:27, Craig White wrote:
and by the way...2 things really bother me but since I can't make it work as it is, I'm not changing them...
1 - there is no /etc/nxserver/node.conf #only node.conf.sample
That's normal.
2 - the pub key I listed above apparently is the one distributed with the binary and that would seem to be a security issue
It is only used for the initial connection so the real login and password are sent over an encrypted channel. You can't do anything else with the nx user login - and you could generate new keys if you wanted. But, you should be seeing sshd[18876]: Accepted publickey for nx ... entries in /var/log/secure if the key is working.
clearly I am not getting anything in /var/log/secure (on the server) that says anything about nx user except when the nx user was created the first time I installed freenx/nx
I think you have a problem with the client or key. If I alter the key I don't see any log entry for the failure.
---- I might be inclined to agree with you but
# diff /etc/nxserver/client.id_dsa.key /var/lib/nxserver/home/.ssh/client.id_dsa.key [root@srv1 nxserver]#
so either key that I copy from the server, the result is the same.
I have spent the entire day on this - and gotten nowhere. I started at my clients system and was so frustrated, I decided to get a fresh start on my server and my workstation and got to the same place nowhere fast.
I find it hard to believe that anyone actually has made it work.
Craig
On Mon, 2006-01-23 at 21:06 -0700, Craig White wrote:
On Mon, 2006-01-23 at 21:42 -0600, Les Mikesell wrote:
On Mon, 2006-01-23 at 21:27, Craig White wrote:
and by the way...2 things really bother me but since I can't make it work as it is, I'm not changing them...
1 - there is no /etc/nxserver/node.conf #only node.conf.sample
That's normal.
2 - the pub key I listed above apparently is the one distributed with the binary and that would seem to be a security issue
It is only used for the initial connection so the real login and password are sent over an encrypted channel. You can't do anything else with the nx user login - and you could generate new keys if you wanted. But, you should be seeing sshd[18876]: Accepted publickey for nx ... entries in /var/log/secure if the key is working.
clearly I am not getting anything in /var/log/secure (on the server) that says anything about nx user except when the nx user was created the first time I installed freenx/nx
I think you have a problem with the client or key. If I alter the key I don't see any log entry for the failure.
I might be inclined to agree with you but
# diff /etc/nxserver/client.id_dsa.key /var/lib/nxserver/home/.ssh/client.id_dsa.key [root@srv1 nxserver]#
so either key that I copy from the server, the result is the same.
I have spent the entire day on this - and gotten nowhere. I started at my clients system and was so frustrated, I decided to get a fresh start on my server and my workstation and got to the same place nowhere fast.
I find it hard to believe that anyone actually has made it work.
---- also to the point - I have long had a pubkey authentication between the 2 machines for 'root' which has always and still works (permits me to as root@lin-workstation login as root@srv1 without a password).
Craig
On Mon, 2006-01-23 at 22:06, Craig White wrote:
I think you have a problem with the client or key. If I alter the key I don't see any log entry for the failure.
I might be inclined to agree with you but
# diff /etc/nxserver/client.id_dsa.key /var/lib/nxserver/home/.ssh/client.id_dsa.key [root@srv1 nxserver]#
I'm not quite sure what you are comparing here. The installed key on the client ends up in $HOME/.nx/config/server_name.nxs along with some other stuff. It's text - compare the key entry to the current one on the server in /etc/nxserver/client.id_dsa.key.
I find it hard to believe that anyone actually has made it work.
I've had no problem other than having to paste the correct key for each server and having some sessions that look like they should resume but won't. I've only run the client on FC1 and windows and the server on Centos and FC4. Maybe there is something odd about a client on FC4.
On Mon, 2006-01-23 at 22:38 -0600, Les Mikesell wrote:
On Mon, 2006-01-23 at 22:06, Craig White wrote:
I think you have a problem with the client or key. If I alter the key I don't see any log entry for the failure.
I might be inclined to agree with you but
# diff /etc/nxserver/client.id_dsa.key /var/lib/nxserver/home/.ssh/client.id_dsa.key [root@srv1 nxserver]#
I'm not quite sure what you are comparing here. The installed key on the client ends up in $HOME/.nx/config/server_name.nxs along with some other stuff. It's text - compare the key entry to the current one on the server in /etc/nxserver/client.id_dsa.key.
I find it hard to believe that anyone actually has made it work.
I've had no problem other than having to paste the correct key for each server and having some sessions that look like they should resume but won't. I've only run the client on FC1 and windows and the server on Centos and FC4. Maybe there is something odd about a client on FC4.
---- made a great deal of sense to me...
downloaded and installed nxclient on my WinXP desktop
opened up putty, connected to srv1 and copied contents of /etc/nxserver/client.id_dsa.key to the key inside of the nxclient application configuration on the Windows system and then checked the 'enable SSL encryption for all traffic' (just like I did for nxclient on Linux) and had the same connection issue and of course, nothing logged.
The issue has to be with the freenx package.
Craig
On Mon, 2006-01-23 at 22:38 -0600, Les Mikesell wrote:
On Mon, 2006-01-23 at 22:06, Craig White wrote:
I think you have a problem with the client or key. If I alter the key I don't see any log entry for the failure.
I might be inclined to agree with you but
# diff /etc/nxserver/client.id_dsa.key /var/lib/nxserver/home/.ssh/client.id_dsa.key [root@srv1 nxserver]#
I'm not quite sure what you are comparing here. The installed key on the client ends up in $HOME/.nx/config/server_name.nxs along with some other stuff. It's text - compare the key entry to the current one on the server in /etc/nxserver/client.id_dsa.key.
I find it hard to believe that anyone actually has made it work.
I've had no problem other than having to paste the correct key for each server and having some sessions that look like they should resume but won't. I've only run the client on FC1 and windows and the server on Centos and FC4. Maybe there is something odd about a client on FC4.
I run nxclient on multiple fc4 desktops which connect to multiple centos 4 servers and all work all the time. That isn't an issue..
I can't think of what it could be... when ever I set up freenx on a machine for remote access.
I install the rpms on the host. then copy the /etc/nxserver/client.id_dsa.key as hostname.id_dsa.key then scp it to the client machine. I also copy the .key to a flash drive for further importing to other clients.
I install the nxclient rpm on the client machine. Configure a new connection. click on the import key button.. point to the key either scp'd or on the flash drive... save it and it's always worked.
I too have a couple machines that have root ssh cert's between the two and I still had no problems.
On Tue, 2006-01-24 at 00:24 -0600, Jaymz Ringler wrote:
On Mon, 2006-01-23 at 22:38 -0600, Les Mikesell wrote:
On Mon, 2006-01-23 at 22:06, Craig White wrote:
I think you have a problem with the client or key. If I alter the key I don't see any log entry for the failure.
I might be inclined to agree with you but
# diff /etc/nxserver/client.id_dsa.key /var/lib/nxserver/home/.ssh/client.id_dsa.key [root@srv1 nxserver]#
I'm not quite sure what you are comparing here. The installed key on the client ends up in $HOME/.nx/config/server_name.nxs along with some other stuff. It's text - compare the key entry to the current one on the server in /etc/nxserver/client.id_dsa.key.
I find it hard to believe that anyone actually has made it work.
I've had no problem other than having to paste the correct key for each server and having some sessions that look like they should resume but won't. I've only run the client on FC1 and windows and the server on Centos and FC4. Maybe there is something odd about a client on FC4.
I run nxclient on multiple fc4 desktops which connect to multiple centos 4 servers and all work all the time. That isn't an issue..
I can't think of what it could be... when ever I set up freenx on a machine for remote access.
I install the rpms on the host. then copy the /etc/nxserver/client.id_dsa.key as hostname.id_dsa.key then scp it to the client machine. I also copy the .key to a flash drive for further importing to other clients.
I install the nxclient rpm on the client machine. Configure a new connection. click on the import key button.. point to the key either scp'd or on the flash drive... save it and it's always worked.
I too have a couple machines that have root ssh cert's between the two and I still had no problems.
---- I appreciate everyone's help on this (thanks Les)
It's either my setup, my methodology or the packaging as it currently sits...current clients from nomachine.com connecting to current server packages nx/freenx from CentOS...that doesn't work.
Since I have never made it work before, I am more likely to believe that it is me but I have documented all my steps and tried to incorporate everyone's advice on this and am shifting my thinking that it isn't me - that someone else would not be able to make it work installing freenx/nx from CentOS and current clients from nomachine.com (I've tried Windows and Linux).
Craig
2 - the pub key I listed above apparently is the one distributed with the binary and that would seem to be a security issue
It is only used for the initial connection so the real login and password are sent over an encrypted channel. You can't do anything else with the nx user login - and you could generate new keys if you wanted. But, you should be seeing sshd[18876]: Accepted publickey for nx ... entries in /var/log/secure if the key is working.
Which is of course totally screwed in the NX protocol. What the hell for does it need an nx user for? Pretty much nothing. Indeed nothing at all. It could just as well ssh directly into your account via ssh user@host /usr/bin/nxserver.
But so much on bad design decisions.
Cheers, MaZe.
On Tue, 2006-01-24 at 03:36, Maciej Żenczykowski wrote:
It is only used for the initial connection so the real login and password are sent over an encrypted channel. You can't do anything else with the nx user login - and you could generate new keys if you wanted. But, you should be seeing sshd[18876]: Accepted publickey for nx ... entries in /var/log/secure if the key is working.
Which is of course totally screwed in the NX protocol. What the hell
for
does it need an nx user for? Pretty much nothing. Indeed nothing at
all.
I'd say it is much, much better than trying to re-invent a different secure connection protocol.
It could just as well ssh directly into your account via ssh
user@host
/usr/bin/nxserver.
The real login does not have to run over ssh or use encryption. That is optional and a waste of CPU if not needed.
But so much on bad design decisions.
It's not that bad compared to a lot of other ways they might have tried to ensure that the real user password exchange is encrypted. The nomachine server always uses the same key for for the nx user and trusts the shell program to not permit anything but the next stage login to happen. That eliminates the key-setup issue that you have with the freenx variation which builds new keys during the install on each server.
Which is of course totally screwed in the NX protocol. What the hell for does it need an nx user for? Pretty much nothing. Indeed nothing at all.
I'd say it is much, much better than trying to re-invent a different secure connection protocol.
Okay: let's evalute what it does and what it could do and explain to me how the current situation is better.
It currently logs in via ssh and privatekey to nx@servermachine, after which it takes the user supplied user/password combo and passes it to the nxserver which uses them to ssh user@localhost and passes the password. Effectively we're logged in as user@servermachine. Furthermore sometimes the freenx server makes a mess of things and leaves around files which only nx (thus root) can delete making further use of nx impossible without root intervention.
Why can't we have: the client gets user/password combo (or even a privatekey for the user!) and ssh's directly into user@servermachine. Effectively we've achieved the same thing, except we've no need for an nx account and if freenx makes a booboo a user can clean out it's temporary files by himself.
It could just as well ssh directly into your account via ssh user@host /usr/bin/nxserver.
The real login does not have to run over ssh or use encryption. That is optional and a waste of CPU if not needed.
I don't get this comment? We're running ssh on top of ssh - isn't that wasteful in and of itself? (is this only in freenx?)
The only use the 'nx' account design decision has is making stuff harder for the administrator.
But so much on bad design decisions.
It's not that bad compared to a lot of other ways they might have tried to ensure that the real user password exchange is encrypted.
Sure they could have screwed up worse, but normal ssh already allows a user to login with user/password combo - and everything is encrypted.
And of course they could have used a different protocol or designed their own instead of ssh - that would have been a bigger mess.
The nomachine server always uses the same key for for the nx user and trusts the shell program to not permit anything but the next stage login to happen. That eliminates the key-setup issue that you have with the freenx variation which builds new keys during the install on each server.
OK, truthfully I don't trust the shell program to not permit anything else. Why can't we leave authentication up to ssh? Stop all the already ironed out bugs out of ssh from having an opportunity to show up in the nxserver shell? Again what do we gain?
I'm lost... is there something I'm not seeing? Maybe this is partly due to being freenx and not the nomachine server. But frankly I still don't see why the NX server - which _DOES_ not require any special priveledges can't run as the user you want to log in as. Does it require special priveledges (which? what for?)
Enlighten me, please.
Cheers, MaZe.
On Tue, 2006-01-24 at 15:15, Maciej Żenczykowski wrote:
I'd say it is much, much better than trying to re-invent a different secure connection protocol.
Okay: let's evalute what it does and what it could do and explain to me how the current situation is better.
It's really too long to describe here but there is one at: http://www.linuxjournal.com/article/8477#comment-122110 (and the rest of the article is good for those who don't know about NX - just scroll up to the top).
I'm lost... is there something I'm not seeing? Maybe this is partly due to being freenx and not the nomachine server. But frankly I still don't see why the NX server - which _DOES_ not require any special priveledges can't run as the user you want to log in as. Does it require special priveledges (which? what for?)
And indeed even if we need special priveledges couldn't we have:
The client gets a servermachine/user/(password|privatekey) triple. Uses "ssh user@servermachine /usr/bin/nxserver" to login, passing either the cleartext password (which ssh will encrypt) or the privatekey (via -i) - thus getting an encrypted connection to the nxserver. The nxserver binary could be setuid and/or setgid 'nx' thus granting it the necessary rights, it could grab whatever special stuff nx is allowed to do and drop them or fork to a child without them to allow the parent to clean up afterwards.
Again - no need for the current key mess. Do you feel safe having anybody capable of ssh'ing into nx@yourmachine? You sure there are no bugs to exploit in the nxserver 'shell' (not to mention potential DoS by opening too many connections...)? Not to mention once logged in via ssh there are potentially even more bugs in ssh which might be exploited (not saying they are there but we've just dramatically increased the code lines in which such a bug might be hidden - now it's not only in the authorization code but in pretty much the entire sshd server...).
And:
The privatekey is _PUBLIC_ - it's available in the standard nomachine client (if you're using the standard configuration). Furthermore - again correct me if I'm wrong (I'm not an rsa/ssh expert and I may be way off base here) - but if I know the privatekey of the client - can't I decode the entire protocol stream by merely sniffing it? Are you sure I can't? Has this been tested/analysed? Are you a security expert in ssh? Do you believe nomachine has people who are good enough to make such a decision? I haven't deeply analysed this - but it's not obvious to me in the first 5 minutes. I expect it can't be trivially compromised, but I do expect security suffers. After spending 10 minutes thinking about this - in the end I do think it is secure, but - what's the point of this entire mess?
Cheers, MaZe.
On Tue, 2006-01-24 at 15:34, Maciej Żenczykowski wrote:
The nxserver binary could be setuid and/or setgid 'nx' thus granting it the necessary rights, it could grab whatever special stuff nx is allowed to do and drop them or fork to a child without them to allow the parent to clean up afterwards.
...
Do you feel safe having anybody capable of ssh'ing into nx@yourmachine? You sure there are no bugs to exploit in the nxserver 'shell'
Wasn't this the same binary you just suggested making setuid - but now you don't trust it ??? Please comment again after reading the link I just posted.
Do you feel safe having anybody capable of ssh'ing into nx@yourmachine? You sure there are no bugs to exploit in the nxserver 'shell'
Wasn't this the same binary you just suggested making setuid - but now you don't trust it ??? Please comment again after reading the link I just posted.
Yes this was the same binary, but only real users could exploit the setuid binary instead of anybody on earth in case of allowing anonymous logins to nx@server. Furthermore, note that I stated that I don't see any need for making the binary setuid, but it could be done if there was some drastic need - not to mention the binary could drop these priviledges before reading any input.
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? 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.
Cheers, MaZe.
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.
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. 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.
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@server nxserver" ==OR EVEN== e) a patched ssh client with special commandline switch which would allow "ssh -NX user@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@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.
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.
Note: I know this can be turned of in the sshd_config file for all users - but that limits usability of the ssh server. Normal users should normally be allowed to do port-forwarding (they can do it anyway if they have shell access).
Note also that the authorized_keys file can contain appropriate keywords (no-port-forwarding, no-X11-forwarding, no-agent-forwarding) (see man sshd_config) to make the above fail, but is your server configured properly?
Cheers, MaZe.
On Tue, 2006-01-24 at 17:57, Maciej Żenczykowski wrote:
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.
Note: I know this can be turned of in the sshd_config file for all users - but that limits usability of the ssh server. Normal users should normally be allowed to do port-forwarding (they can do it anyway if they have shell access).
Note also that the authorized_keys file can contain appropriate keywords (no-port-forwarding, no-X11-forwarding, no-agent-forwarding) (see man sshd_config) to make the above fail, but is your server configured properly?
I'd agree that the nx user's authorized_keys file should contain this directive by default if it isn't needed by the protocol. Do you know the right place to post a bug?
I'd agree that the nx user's authorized_keys file should contain this directive by default if it isn't needed by the protocol. Do you know the right place to post a bug?
I do, but this is something I only now realized. Still experimenting with how to fix this...
I think the following in /var/lib/nxserver/home/.ssh/authorized_keys2 works correctly and only leaves a resource DoS (while fixing the port forwarding and other issues):
for each (client host,key) pair enter:
from="client.fqdn",command="/usr/bin/nxserver",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-dss AAAA...== anyone@client.fqdn
[you can also use an ip instead of client.fqdn]
for each global key enter (ie a key which works from any ip):
command="/usr/bin/nxserver",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-dss AAAA...== anyone@anywhere
using ssh-dss for dsa keys and ssh-rsa for rsa keys (I think rsa is better if I recall latest discussions)
Cheers, MaZe.
On Tue, 2006-01-24 at 17:50, 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?
It is, but you may not want to let real users log in directly on an exposed interface. Even if the nx user managed to break out of the shell program that isn't supposed to do anything else, it would be as a user that didn't own anything useful.
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.
I believe the commercial server may have a modified ssh that does not permit tunnels or other unneeded operations.
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
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.
You are talking to the stock sshd here, not something that came with freenx. If you want port forwarding turned off, you can turn it off.
Is the nomachine server vulnerable? don't know - but the freenx server IS.
Don't think so. It might be wise to turn it off, but note that the freenx server generates new keys when installed so you are only exposed to the extent that you give away the keys. If you don't let them get out to anyone that didn't have an ssh login already you are in about the same shape.
Where does the problem come from? It comes from reinventing the wheel...
It doesn't reinvent anything - it just uses an extra login.
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?
It is, but you may not want to let real users log in directly on an exposed interface. Even if the nx user managed to break out of the shell program that isn't supposed to do anything else, it would be as a user that didn't own anything useful.
You've lost me here. If I can log in as nx via ssh then I can log in as a normal user anyway on that exposed interface. I haven't gained anything except added complexity by adding the extra 'nx' user.
You are talking to the stock sshd here, not something that came with freenx. If you want port forwarding turned off, you can turn it off.
Of course, but the only reason we have this problem is because of the two-stage authentication - if we used ssh to authenticate as the user and not as nx than this wouldn't happen.
Where does the problem come from? It comes from reinventing the wheel...
It doesn't reinvent anything - it just uses an extra login.
It's reinventing authorization, for no fathomable reason - that's all I'm claiming.
Cheers, MaZe.
copied the above key (that which was between the ----BEGIN and -----END but not including those lines) and pasted into the key section and that
why without the --begin-- --end-- lines? I always copy with'em.
1 - there is no /etc/nxserver/node.conf #only node.conf.sample
well, you should probably make a node.conf and allow all users to login...
my /etc/nxserver/node.conf has: ENABLE_USERMODE_AUTHENTICATION="1" ENABLE_FORCE_ENCRYPTION="1" SSHD_CHECK_IP="1" DISPLAY_BASE=20 SESSION_LIMIT=50 SESSION_USER_LIMIT=10 NX_LOG_LEVEL=7 NX_LOG_SECURE=0 DEFAULT_X_WM="twm" EXPORT_USERIP="1" EXPORT_SESSIONID="1" ENABLE_USESSION="1" COMMAND_SESSREG="/usr/X11R6/bin/sessreg" APPLICATION_LIBRARY_PATH="/usr/lib/NX/lib"
2 - the pub key I listed above apparently is the one distributed with the binary and that would seem to be a security issue
Agreed and that's why I don't use it.
I generate keys using ssh-keygen, and stick them into: /var/lib/nxserver/home/.ssh/authorized_keys2 (or without the '2' depends on sshd server setup) [in one line] and the entire private key into the client.
Basically:
# ssh-keygen -t dsa -f key <enter: empty passphrase> <enter again> # cat key.pub >> /var/lib/nxserver/home/.ssh/authorized_keys2 { you might want to actually prefix the key with from="ip.ip.ip.ip" or from="fully.qualified.domain.name" to further restrict logins to valid IPs only but do this only once everything is working... } < copy "key" into the client >
# cat /etc/passwd | grep nx nx:x:110:110:NX Remote Access:/var/lib/nxserver/home:/usr/bin/nxserver # cat /etc/shadow | grep nx nx:!!:13002:::::: # cat /etc/group | grep nx utmp:x:22:nx nx:x:110: # cat /etc/gshadow | grep nx utmp:x::nx nx:!::
Make sure that sshd is configured to let in user NX via pubkey from all important IP addresses (ssh -i key nx@serverip)
Make sure that sshd is configured to let in other users with password from localhost (ssh craig@serverip <type in password>)
Might still be missing something, but any other problems should show up as errors in /var/log/secure or /var/log/messages or the nx logs.
Oh, make sure bash-completion is _NOT_ installed.
Cheers, MaZe.
On Tue, 2006-01-24 at 10:33 +0100, Maciej Żenczykowski wrote:
copied the above key (that which was between the ----BEGIN and -----END but not including those lines) and pasted into the key section and that
why without the --begin-- --end-- lines? I always copy with'em.
YES ... leave the begin and end lines ON THE KEY ... they are part of the key.
On Tue, 2006-01-24 at 05:16 -0600, Johnny Hughes wrote:
On Tue, 2006-01-24 at 10:33 +0100, Maciej Żenczykowski wrote:
copied the above key (that which was between the ----BEGIN and -----END but not including those lines) and pasted into the key section and that
why without the --begin-- --end-- lines? I always copy with'em.
YES ... leave the begin and end lines ON THE KEY ... they are part of the key.
---- makes sense - but if I leave those lines in, I ALWAYS get the first error that I reported last night - NX> 203 NXSSH running with pid: 32108 NX> 285 Enabling check on switch command NX> 285 Enabling skip of SSH config files NX> 200 Connected to address: 192.168.2.1 on port: 22 NX> 202 Authenticating user: nx NX> 208 Using auth method: publickey NX> 204 Authentication failed.
If I don't have them in, I ALWAYS get the second error that I reported last night - 'authentication failed for user craig'
If nothing else, it made me feel as though I got closer
This is current nxclient config [craig@lin-workstation ~]$ cat .nx/config/srv1.nxs <!DOCTYPE NXClientSettings> <NXClientSettings application="nxclient" version="1.3" > <group name="Advanced" > <option key="Cache size" value="8" /> <option key="Cache size on disk" value="32" /> <option key="Current keyboard" value="true" /> <option key="Custom keyboard layout" value="us" /> <option key="Disable TCP no-delay" value="false" /> <option key="Disable ZLIB stream compression" value="false" /> <option key="Enable SSL encryption" value="true" /> <option key="Restore cache" value="true" /> <option key="StreamCompression" value="" /> </group> <group name="Environment" > <option key="CUPSD path" value="/usr/sbin/cupsd" /> </group> <group name="General" > <option key="Automatic reconnect" value="false" /> <option key="Backingstore" value="when_requested" /> <option key="Command line" value="" /> <option key="Custom Unix Desktop" value="console" /> <option key="Desktop" value="kde" /> <option key="Link speed" value="lan" /> <option key="Remember password" value="true" /> <option key="Resolution" value="available" /> <option key="Resolution height" value="600" /> <option key="Resolution width" value="800" /> <option key="Server host" value="srv1.azapple.com" /> <option key="Server port" value="22" /> <option key="Session" value="unix" /> <option key="Use default image encoding" value="0" /> <option key="Use render" value="true" /> <option key="Use taint" value="true" /> <option key="Virtual desktop" value="true" /> <option key="XAgent encoding" value="true" /> <option key="displaySaveOnExit" value="true" /> <option key="xdm broadcast port" value="177" /> <option key="xdm list host" value="localhost" /> <option key="xdm list port" value="177" /> <option key="xdm mode" value="server decide" /> <option key="xdm query host" value="localhost" /> <option key="xdm query port" value="177" /> </group> <group name="Images" > <option key="Disable JPEG Compression" value="0" /> <option key="Disable all image optimisations" value="false" /> <option key="Image Compression Type" value="0" /> <option key="Image Encoding Type" value="0" /> <option key="Image JPEG Encoding" value="false" /> <option key="JPEG Quality" value="6" /> <option key="RDP optimization for low-bandwidth link" value="false" /> <option key="Reduce colors to" value="" /> <option key="Use PNG Compression" value="true" /> <option key="VNC images compression" value="0" /> <option key="Windows Image Compression" value="1" /> </group> <group name="Login" > <option key="Auth" value="EMPTY_PASSWORD" /> <option key="Public Key" value="-----BEGIN DSA PRIVATE KEY----- MIIBugIBAAKBgQCYhmXqqt+r8L/+JCOk8HrnR276ZI3rSTUx8cvQc2Z46h+EIneV lDYa0Bx0QDS4cVWiZgelgPeHjXc9waLKUjjZv0SDQ1RX9P0dQxNPac1JY2Is8HpW eljpSdfQFy3Gbb3vLHLTwX30LIZi91u0QSmrIgarC4Nmcg2veS84DgIqIQIVAK6Y nIySJyDPgA3u+cimJb3UegR/AoGAQ7l4ucKX2W/fUCtfTEp9rRChAvLCTkw82Au3 WMuu2c10ufQjS0txjZ9jKGKq50HtXmtEn5wcYKjlvEwi2KZIP7wpkFA7Lnrr/T7E n+cPPjI/SGFGmzFD9NBKFY9nMVnAoLMnQs/Gb8Ejs7q/c6WK1W4pOaAmPqq2QrDW OhL94ScCgYB0p+uF3X8rWTXkYkXaAqC217/D9hqU82GaOWye22Lv617mN/TTw4gR wQ8AgnnoBzLKkguiJVUNltSskmhR3Bx+KsakX6vSIX5glJtOyKFDlAYujqbiKf0n OrDed3ISCyP5tyywwUlkcasPryP3TCORHDAO9SX8qkdcZUUSK47RAQIUcylxt32d 30CRX0RVk588Lue4d1g= -----END DSA PRIVATE KEY-----" /> <option key="User" value="craig" /> </group> <group name="Services" > <option key="Audio" value="false" /> <option key="IPPPort" value="631" /> <option key="IPPPrinting" value="false" /> <option key="Shares" value="false" /> </group> <group name="VNC Session" > <option key="Display" value="0" /> <option key="Remember" value="false" /> <option key="Server" value="" /> </group> <group name="Windows Session" > <option key="Application" value="" /> <option key="Authentication" value="2" /> <option key="Color Depth" value="8" /> <option key="Domain" value="" /> <option key="Image Cache" value="true" /> <option key="Password" value="EMPTY_PASSWORD" /> <option key="Remember" value="true" /> <option key="Run application" value="false" /> <option key="Server" value="" /> <option key="User" value="" /> </group> <group name="share chosen" > <option key="Share number" value="0" /> </group> </NXClientSettings> [craig@lin-workstation ~]$
On Tue, 2006-01-24 at 10:33 +0100, Maciej Żenczykowski wrote:
copied the above key (that which was between the ----BEGIN and -----END but not including those lines) and pasted into the key section and that
why without the --begin-- --end-- lines? I always copy with'em.
----- Yeah - I think I needed them too. I was unsure which is why I posted up about copying the key with/without them. Turned out 'importing' probably would have worked just fine too - have to check on that. ----
I generate keys using ssh-keygen, and stick them into: /var/lib/nxserver/home/.ssh/authorized_keys2 (or without the '2' depends on sshd server setup) [in one line] and the entire private key into the client.
---- This little nugget combined with what I learned last night was the key and I probably would have stumbled into last night had I had the ----BEGIN & -----END lines.
turns out that install will create
/var/lib/nxserver/home/.ssh/authorized_keys2
but sshd on CentOS 4 doesn't look there.
so I merely
cd /var/lib/nxserver/home/.ssh cp authorized_keys2 authorized_keys chown nx authorized_keys
et voila - login
Thanks for everyone's help
I can't believe that people didn't stumble into this installing freenx on CentOS as it simply cannot work out of the box without doing this or some other change in /etc/ssh/sshd_config
Craig
On Tue, 2006-01-24 at 09:25, Craig White wrote:
but sshd on CentOS 4 doesn't look there.
so I merely
cd /var/lib/nxserver/home/.ssh cp authorized_keys2 authorized_keys chown nx authorized_keys
et voila - login
Thanks for everyone's help
I can't believe that people didn't stumble into this installing freenx on CentOS as it simply cannot work out of the box without doing this or some other change in /etc/ssh/sshd_config
I'm pretty sure I have not changed anything related to sshd_config or the freenx setup, and mine has no authorized_keys and after a login I can see the access time has changed on /var/lib/nxserver/home/.ssh/authorized_keys2. # rpm -q openssh openssh-3.9p1-8.RHEL4.9 # rpm -q freenx freenx-0.4.4-1.centos4 I may have installed earlier versions and updated on this machine but I doubt if that matters. I'm still curious about that strace showing that /var/lib/nxserver/home/.ssh/authorized_keys2 did not exist from the app's perspective. Strace doesn't lie.
On Tue, 2006-01-24 at 10:02 -0600, Les Mikesell wrote:
On Tue, 2006-01-24 at 09:25, Craig White wrote:
but sshd on CentOS 4 doesn't look there.
so I merely
cd /var/lib/nxserver/home/.ssh cp authorized_keys2 authorized_keys chown nx authorized_keys
et voila - login
Thanks for everyone's help
I can't believe that people didn't stumble into this installing freenx on CentOS as it simply cannot work out of the box without doing this or some other change in /etc/ssh/sshd_config
I'm pretty sure I have not changed anything related to sshd_config or the freenx setup, and mine has no authorized_keys and after a login I can see the access time has changed on /var/lib/nxserver/home/.ssh/authorized_keys2. # rpm -q openssh openssh-3.9p1-8.RHEL4.9 # rpm -q freenx freenx-0.4.4-1.centos4 I may have installed earlier versions and updated on this machine but I doubt if that matters. I'm still curious about that strace showing that /var/lib/nxserver/home/.ssh/authorized_keys2 did not exist from the app's perspective. Strace doesn't lie.
---- run the command on your system...
strace -p freenxpid -f -t -o /tmp/logfile
I would expect that you would get very similar results so you can satisfy your curiosity. Thankfully, I didn't travel down the path since it wouldn't have led to the solution of my problem.
as for authorized_keys v. authorized_keys2...
I am not an sshd expert, but clearly on my systems (2), it wants authorized_keys and both of these were clean installs of CentOS 4.1 and ultimately updated to CentOS 4.2 before I ever attempted freenx.
Craig
On Tue, 2006-01-24 at 09:12 -0700, Craig White wrote:
On Tue, 2006-01-24 at 10:02 -0600, Les Mikesell wrote:
On Tue, 2006-01-24 at 09:25, Craig White wrote:
but sshd on CentOS 4 doesn't look there.
so I merely
cd /var/lib/nxserver/home/.ssh cp authorized_keys2 authorized_keys chown nx authorized_keys
et voila - login
Thanks for everyone's help
I can't believe that people didn't stumble into this installing freenx on CentOS as it simply cannot work out of the box without doing this or some other change in /etc/ssh/sshd_config
I'm pretty sure I have not changed anything related to sshd_config or the freenx setup, and mine has no authorized_keys and after a login I can see the access time has changed on /var/lib/nxserver/home/.ssh/authorized_keys2. # rpm -q openssh openssh-3.9p1-8.RHEL4.9 # rpm -q freenx freenx-0.4.4-1.centos4 I may have installed earlier versions and updated on this machine but I doubt if that matters. I'm still curious about that strace showing that /var/lib/nxserver/home/.ssh/authorized_keys2 did not exist from the app's perspective. Strace doesn't lie.
run the command on your system...
strace -p freenxpid -f -t -o /tmp/logfile
I would expect that you would get very similar results so you can satisfy your curiosity. Thankfully, I didn't travel down the path since it wouldn't have led to the solution of my problem.
as for authorized_keys v. authorized_keys2...
I am not an sshd expert, but clearly on my systems (2), it wants authorized_keys and both of these were clean installs of CentOS 4.1 and ultimately updated to CentOS 4.2 before I ever attempted freenx.
---- duh - the command I used was...
strace -o /tmp/logfile -f -t nxserver --restart
anyway, thanks for all the help last night Les
Craig
On Tue, 2006-01-24 at 10:18, Craig White wrote:
duh - the command I used was...
strace -o /tmp/logfile -f -t nxserver --restart
Oh - the start/stop/restart commands really just rename /var/lib/nxserver/home/.ssh/authorized_keys2 back and forth to /var/lib/nxserver/home/.ssh/authorized_keys2.disabled so your strace caught it when it really didn't exist. The next step should have been to rename it back.
turns out that install will create
/var/lib/nxserver/home/.ssh/authorized_keys2
but sshd on CentOS 4 doesn't look there.
so I merely
cd /var/lib/nxserver/home/.ssh cp authorized_keys2 authorized_keys chown nx authorized_keys
et voila - login
Thanks for everyone's help
I can't believe that people didn't stumble into this installing freenx on CentOS as it simply cannot work out of the box without doing this or some other change in /etc/ssh/sshd_config
Okay, weird:
# cat /etc/ssh/sshd_config | grep -v "^#" | grep -v "^$" SyslogFacility AUTHPRIV PermitRootLogin without-password PasswordAuthentication yes GSSAPIAuthentication yes GSSAPICleanupCredentials yes UsePAM yes X11Forwarding yes AllowGroups root users nx Subsystem sftp /usr/libexec/openssh/sftp-server
# strace -ff -s 2048 -p [main_sshd_pid] 2>&1 | grep -i authorized_k [pid 2216] stat64("/var/lib/nxserver/home/.ssh/authorized_keys", 0xbfe63c20) = -1 ENOENT (No such file or directory) [pid 2216] stat64("/var/lib/nxserver/home/.ssh/authorized_keys2", {st_mode=S_IFREG|0640, st_size=16192, ...}) = 0 [pid 2216] open("/var/lib/nxserver/home/.ssh/authorized_keys2", O_RDONLY|O_LARGEFILE) = 4 [pid 2216] lstat64("/var/lib/nxserver/home/.ssh/authorized_keys2", {st_mode=S_IFREG|0640, st_size=16192, ...}) = 0
while "ssh -i client.key nx@server" is run.
So the CentOS42 up2date server with no special (?) configuration is checking both auth_key2 and auth_key files...
Weird,
MaZe.
On Tue, 2006-01-24 at 08:25 -0700, Craig White wrote:
On Tue, 2006-01-24 at 10:33 +0100, Maciej Żenczykowski wrote:
copied the above key (that which was between the ----BEGIN and -----END but not including those lines) and pasted into the key section and that
why without the --begin-- --end-- lines? I always copy with'em.
Yeah - I think I needed them too. I was unsure which is why I posted up about copying the key with/without them. Turned out 'importing' probably would have worked just fine too - have to check on that.
I generate keys using ssh-keygen, and stick them into: /var/lib/nxserver/home/.ssh/authorized_keys2 (or without the '2' depends on sshd server setup) [in one line] and the entire private key into the client.
This little nugget combined with what I learned last night was the key and I probably would have stumbled into last night had I had the ----BEGIN & -----END lines.
turns out that install will create
/var/lib/nxserver/home/.ssh/authorized_keys2
but sshd on CentOS 4 doesn't look there.
so I merely
cd /var/lib/nxserver/home/.ssh cp authorized_keys2 authorized_keys chown nx authorized_keys
et voila - login
Thanks for everyone's help
I can't believe that people didn't stumble into this installing freenx on CentOS as it simply cannot work out of the box without doing this or some other change in /etc/ssh/sshd_config
OK, I have just done a brand new install of CentOS just to test this issue on a blank machine.
It is a standard server install with no packages from outside the CentOS repositories.
First thing i did after running yum upgrade is this:
yum install freenx nx
Then I went to a client and imported the key ...
I have what you said ... authorized_keys2 in /var/lib/nxserver/home/.ssh/ (which is exactly what I would expect).
connection from the client worked perfectly ... I had zero issues.
Craig ... please look in your /etc/ssh/sshd_conf file and see if you have a:
Protocol 1
in there ... because with the standard config, both Protocol 2 and 1 are authorized. What you are describing suggests that only ssl protocol 1 is enabled on your sshd.
I can absolutely say that with no modifications to sshd_conf, pam authentication, or other changes that nx/freenx works perfectly out of the box.
On Tue, 2006-01-24 at 19:34 -0600, Johnny Hughes wrote:
On Tue, 2006-01-24 at 08:25 -0700, Craig White wrote:
On Tue, 2006-01-24 at 10:33 +0100, Maciej Żenczykowski wrote:
copied the above key (that which was between the ----BEGIN and -----END but not including those lines) and pasted into the key section and that
why without the --begin-- --end-- lines? I always copy with'em.
Yeah - I think I needed them too. I was unsure which is why I posted up about copying the key with/without them. Turned out 'importing' probably would have worked just fine too - have to check on that.
I generate keys using ssh-keygen, and stick them into: /var/lib/nxserver/home/.ssh/authorized_keys2 (or without the '2' depends on sshd server setup) [in one line] and the entire private key into the client.
This little nugget combined with what I learned last night was the key and I probably would have stumbled into last night had I had the ----BEGIN & -----END lines.
turns out that install will create
/var/lib/nxserver/home/.ssh/authorized_keys2
but sshd on CentOS 4 doesn't look there.
so I merely
cd /var/lib/nxserver/home/.ssh cp authorized_keys2 authorized_keys chown nx authorized_keys
et voila - login
Thanks for everyone's help
I can't believe that people didn't stumble into this installing freenx on CentOS as it simply cannot work out of the box without doing this or some other change in /etc/ssh/sshd_config
OK, I have just done a brand new install of CentOS just to test this issue on a blank machine.
It is a standard server install with no packages from outside the CentOS repositories.
First thing i did after running yum upgrade is this:
yum install freenx nx
Then I went to a client and imported the key ...
I have what you said ... authorized_keys2 in /var/lib/nxserver/home/.ssh/ (which is exactly what I would expect).
connection from the client worked perfectly ... I had zero issues.
Craig ... please look in your /etc/ssh/sshd_conf file and see if you have a:
Protocol 1
in there ... because with the standard config, both Protocol 2 and 1 are authorized. What you are describing suggests that only ssl protocol 1 is enabled on your sshd.
I can absolutely say that with no modifications to sshd_conf, pam authentication, or other changes that nx/freenx works perfectly out of the box.
---- thanks for checking...it remains untouched from distribution
# grep Protocol /etc/ssh/sshd_config #Protocol 2,1
Obviously, I had one issue and it was a real problem identifying it.
Thanks for checking - I'm glad that I got it working before you said that because I would have really been freaked out.
I can tell you for sure though that I did this on 2 different CentOS 4 installs - and the same solution applied made things work fine. I am presently doing the ruby thing via nx and I'm pretty happy (especially once I worked out the stupid 'mouseover' pop-ups that were most painful via remote terminal).
Craig
On Tue, 2006-01-24 at 21:35, Craig White wrote:
thanks for checking...it remains untouched from distribution
# grep Protocol /etc/ssh/sshd_config #Protocol 2,1
Obviously, I had one issue and it was a real problem identifying it.
But it still doesn't make any sense. Installing freenx should put the key in authorized_keys2 and sshd should use it from there.
I can tell you for sure though that I did this on 2 different CentOS 4 installs - and the same solution applied made things work fine.
You must be doing something else that affects sshd. It should default to protocol 2 and prefer the authorized_keys2 file.
On Tue, 2006-01-24 at 22:08 -0600, Les Mikesell wrote:
On Tue, 2006-01-24 at 21:35, Craig White wrote:
thanks for checking...it remains untouched from distribution
# grep Protocol /etc/ssh/sshd_config #Protocol 2,1
Obviously, I had one issue and it was a real problem identifying it.
But it still doesn't make any sense. Installing freenx should put the key in authorized_keys2 and sshd should use it from there.
I can tell you for sure though that I did this on 2 different CentOS 4 installs - and the same solution applied made things work fine.
You must be doing something else that affects sshd. It should default to protocol 2 and prefer the authorized_keys2 file.
---- To be honest - I have other fish to fry and working is good.
As for doing something else that affects sshd...
It's possible - I did change one setting - trying to fix the issue...
# grep Pubkey /etc/ssh/sshd_config PubkeyAuthentication yes
which previously had been commented out - this was a desperation move and I never set it back. If this would cause this behavior, then I can rectify it (later).
Thanks
Craig
On Tue, 2006-01-24 at 21:18 -0700, Craig White wrote:
On Tue, 2006-01-24 at 22:08 -0600, Les Mikesell wrote:
On Tue, 2006-01-24 at 21:35, Craig White wrote:
thanks for checking...it remains untouched from distribution
# grep Protocol /etc/ssh/sshd_config #Protocol 2,1
Obviously, I had one issue and it was a real problem identifying it.
But it still doesn't make any sense. Installing freenx should put the key in authorized_keys2 and sshd should use it from there.
I can tell you for sure though that I did this on 2 different CentOS 4 installs - and the same solution applied made things work fine.
You must be doing something else that affects sshd. It should default to protocol 2 and prefer the authorized_keys2 file.
To be honest - I have other fish to fry and working is good.
As for doing something else that affects sshd...
It's possible - I did change one setting - trying to fix the issue...
# grep Pubkey /etc/ssh/sshd_config PubkeyAuthentication yes
which previously had been commented out - this was a desperation move and I never set it back. If this would cause this behavior, then I can rectify it (later).
the next option down is this:
AuthorizedKeysFile .ssh/authorized_keys
it is normally remarked out .. if that is set, you can only have .ssh/authorized_keys and .ssh/authorized_keys2 won't work.
On Tue, 2006-01-24 at 22:45 -0600, Johnny Hughes wrote:
On Tue, 2006-01-24 at 21:18 -0700, Craig White wrote:
On Tue, 2006-01-24 at 22:08 -0600, Les Mikesell wrote:
On Tue, 2006-01-24 at 21:35, Craig White wrote:
thanks for checking...it remains untouched from distribution
# grep Protocol /etc/ssh/sshd_config #Protocol 2,1
Obviously, I had one issue and it was a real problem identifying it.
But it still doesn't make any sense. Installing freenx should put the key in authorized_keys2 and sshd should use it from there.
I can tell you for sure though that I did this on 2 different CentOS 4 installs - and the same solution applied made things work fine.
You must be doing something else that affects sshd. It should default to protocol 2 and prefer the authorized_keys2 file.
To be honest - I have other fish to fry and working is good.
As for doing something else that affects sshd...
It's possible - I did change one setting - trying to fix the issue...
# grep Pubkey /etc/ssh/sshd_config PubkeyAuthentication yes
which previously had been commented out - this was a desperation move and I never set it back. If this would cause this behavior, then I can rectify it (later).
the next option down is this:
AuthorizedKeysFile .ssh/authorized_keys
it is normally remarked out .. if that is set, you can only have .ssh/authorized_keys and .ssh/authorized_keys2 won't work.
---- trust me when I tell you this is unchanged from distribution
[root@srv2 ~]# grep AuthorizedKeys /etc/ssh/sshd_config #AuthorizedKeysFile .ssh/authorized_keys
Craig
On Mon, 2006-01-23 at 18:46 -0600, Johnny Hughes wrote:
On Mon, 2006-01-23 at 17:07 -0700, Craig White wrote:
On Mon, 2006-01-23 at 16:54 -0700, Craig White wrote:
On Tue, 2006-01-24 at 00:49 +0100, Deim Ágoston wrote:
Try strace -p freenxpid -f -t -o /tmp/logfile
awesome idea...how do you figure out the pid when...
# ps aux|grep nx root 15218 0.0 0.1 4600 664 pts/5 S+ 16:32 0:00 grep nx
doesn't show a process id?
it doesn't show that freenx is running! Are you sure it's started? Try to start it manulay with strace -o /tmp/logfile -f -t /usr/sbin/freenx
(or wherever you installed the binaries)
# nxserver --status NX> 100 NXSERVER - Version 1.4.0-44 OS (GPL) NX> 110 NX Server is running NX> 999 Bye
(hey - I'm just the dummy that started fooling with it).
# strace -o /tmp/logfile -f -t /usr/sbin/nxserver --restart -bash: strace: command not found
I will figure out where it comes from and install it I guess
this was pointless - outside of the great log file it created...the trace was only of the nxserver -restart and nothing beyond that so no useful information could be derived. I haven't a clue on which process it would be - I presume that it all starts with an ssh connection...
OK ... lets start over :)
remove everything on the server and then do this on the server:
yum install nx freenx
Then download and install the latest client from nomachine.org on the client.
then ssh into the server from the client and on the server edit the file:
/etc/nxserver/client.id_dsa.key and copy/paste it into the Window that shows up when you press the "Key" button, then press "Save".
Make sure to check the box that says "Enable encryption of all traffic"
That should do it...
---- and a for what it's worth commentary here...(perhaps a suggestion for the post-remove script for nx package)
yum remove freenx nx
removes the packages but leaves /etc/nxserver /var/lib/nxserver/home/.ssh/ # a bunch of files here
and the user nx also remains in the system though the user was created in the post-install script.
I therefore - to achieve a clean install...
yum remove freenx nx userdel nx rm -fr /etc/nxserver rm -fr /var/lib/nxserver
and then did an install yum install freenx nx
to make sure the cruft was gone....
then re-imported client.id_dsa.key into the nxclient application on my workstation before trying to connect
Still the same issue
Craig
it doesn't show that freenx is running! Are you sure it's started? Try to start it manulay with strace -o /tmp/logfile -f -t /usr/sbin/freenx
That's because nxserver doesn't run unless someone is either logging in or logged in - it's started automatically by ssh - remember that nx's login shell is nxserver?
Cheers, MaZe.
On Mon, 2006-01-23 at 16:53, Craig White wrote:
copied them to my workstation and then used the 'import' function in nxclient to import the keys and try to connect and always get the following detail when I failed to connect...
Try pasting the text from /etc/nxserver/client/client.id_dsa.key into the nxclient key window and saving it instead of using the import function.
that actually got me a lot further...I get 'authentication failed for user craig'
So back on the server, I tried...
nxserver --adduser craig
This shouldn't be necessary. If you can log in as yourself with ssh and a password, nxclient should work. What is supposed to happen is that it logs in first as the 'nx' user with ssh and the client key and uses this only for an encrypted path to pass the real username and password - which should only need to be normal users. Installing the freenx rpm should have created the nx user. The rest should happen like you logged into the console.
On Mon, 2006-01-23 at 17:07 -0600, Les Mikesell wrote:
On Mon, 2006-01-23 at 16:53, Craig White wrote:
copied them to my workstation and then used the 'import' function in nxclient to import the keys and try to connect and always get the following detail when I failed to connect...
Try pasting the text from /etc/nxserver/client/client.id_dsa.key into the nxclient key window and saving it instead of using the import function.
that actually got me a lot further...I get 'authentication failed for user craig'
So back on the server, I tried...
nxserver --adduser craig
This shouldn't be necessary. If you can log in as yourself with ssh and a password, nxclient should work. What is supposed to happen is that it logs in first as the 'nx' user with ssh and the client key and uses this only for an encrypted path to pass the real username and password - which should only need to be normal users. Installing the freenx rpm should have created the nx user. The rest should happen like you logged into the console.
---- I think the user nx is alive and well...
# getent passwd |grep nx nx:x:102:103::/var/lib/nxserver/home:/usr/bin/nxserver
# ls -al /var/lib/nxserver/home total 80 drwx------ 4 nx root 4096 Jan 23 15:16 . drwx------ 4 nx root 4096 Jan 23 15:16 .. -rw-r--r-- 1 nx root 304 Jan 23 15:16 .bash_logout -rw-r--r-- 1 nx root 191 Jan 23 15:16 .bash_profile -rw-r--r-- 1 nx root 124 Jan 23 15:16 .bashrc -rw-r--r-- 1 nx root 383 Jan 23 15:16 .emacs -rw-r--r-- 1 nx root 120 Jan 23 15:16 .gtkrc drwx------ 2 nx root 4096 Jan 23 16:11 .ssh drwxr-xr-x 2 nx root 4096 Jan 23 15:16 .xemacs -rw-r--r-- 1 nx root 658 Jan 23 15:16 .zshrc
# ls -al /var/lib/nxserver/home/.ssh total 48 drwx------ 2 nx root 4096 Jan 23 16:11 . drwx------ 4 nx root 4096 Jan 23 15:16 .. -rw-r----- 1 nx root 611 Jan 23 15:16 authorized_keys2 -rw------- 1 nx root 668 Jan 23 15:16 client.id_dsa.key -rw-r--r-- 1 nx root 220 Jan 23 15:16 known_hosts -rw------- 1 nx root 611 Jan 23 15:16 server.id_dsa.pub.key
# diff /var/lib/nxserver/home/.ssh/client.id_dsa.key \ /etc/nxserver/client.id_dsa.key #
exasperation...
Thanks
Craig
On Mon, 2006-01-23 at 17:21, Craig White wrote:
# diff /var/lib/nxserver/home/.ssh/client.id_dsa.key \ /etc/nxserver/client.id_dsa.key #
exasperation...
Can you log in at the console and with ssh using the login and password as you are giving nxclient? /var/log/secure should show the nx public key login for nx if you are getting that far.
On Mon, 2006-01-23 at 17:54 -0600, Les Mikesell wrote:
On Mon, 2006-01-23 at 17:21, Craig White wrote:
# diff /var/lib/nxserver/home/.ssh/client.id_dsa.key \ /etc/nxserver/client.id_dsa.key #
exasperation...
Can you log in at the console and with ssh using the login and password as you are giving nxclient?
---- # ssh craig@localhost craig@localhost's password: Last login: Mon Jan 23 16:16:47 2006 from lin-workstation.azapple.com ----
/var/log/secure should show the nx public key login for nx if you are getting that far.
---- Jan 23 15:16:03 srv1 useradd[13734]: new group: name=nx, gid=103 Jan 23 15:16:03 srv1 useradd[13734]: new user: name=nx, uid=102, gid=103, home=/var/lib/nxserver/home, shell=/usr/bin/nxserver Jan 23 16:16:47 srv1 sshd[14960]: Accepted password for craig from 192.168.2.10 port 34700 ssh2 Jan 23 16:16:47 srv1 sshd[14960]: nss_ldap: reconnecting to LDAP server... Jan 23 16:16:47 srv1 sshd[14960]: nss_ldap: reconnected to LDAP server after 1 attempt(s) Jan 23 17:03:14 srv1 sshd[15703]: Accepted password for craig from 127.0.0.1 port 58445 ssh2
shows my installation of freenx (hence creation of user/group nx) shows sshd connection per 1st example that I could login as craig from lin-workstation via ssh shows sshd connection from above example that I could login as craig from localhost via ssh
nowhere does it ever show user nx getting authenticated via public key.
Craig
On Mon, 2006-01-23 at 15:35 -0700, Craig White wrote:
installed freenx server on CentOS 4 server installed nxclient from nomachine.com on workstation
so far so good.
following directions from web site... http://fedoranews.org/contributors/rick_stout/freenx/
where I tried both /etc/nxserver/client/client.id_dsa.key and /var/lib/nxserver/home/.ssh/client.id_dsa.key
copied them to my workstation and then used the 'import' function in nxclient to import the keys and try to connect and always get the following detail when I failed to connect...
NX> 203 NXSSH running with pid: 21106 NX> 285 Enabling check on switch command NX> 285 Enabling skip of SSH config files NX> 200 Connected to address: 192.168.2.1 on port: 22 NX> 202 Authenticating user: nx NX> 208 Using auth method: publickey NX> 204 Authentication failed.
what's the trick - there is obviously something very important missing from the web page.
---- just out of curiosity...does anyone actually have freenx server working on CentOS 4 and have clients connecting to it?
Craig
On Mon, 2006-01-23 at 18:33 -0600, Jaymz Ringler wrote:
just out of curiosity...does anyone actually have freenx server working on CentOS 4 and have clients connecting to it?
I have about 12 centos 4 servers which I use freenx on daily.
---- thanks - I just wanted to make sure that I wasn't wasting my time. Out of the box, it simply doesn't work and I wouldn't mind it so much but nothing gets logged anywhere making debugging a real problem.
Craig
On Mon, 2006-01-23 at 16:41 -0700, Craig White wrote:
On Mon, 2006-01-23 at 15:35 -0700, Craig White wrote:
installed freenx server on CentOS 4 server installed nxclient from nomachine.com on workstation
so far so good.
following directions from web site... http://fedoranews.org/contributors/rick_stout/freenx/
where I tried both /etc/nxserver/client/client.id_dsa.key and /var/lib/nxserver/home/.ssh/client.id_dsa.key
copied them to my workstation and then used the 'import' function in nxclient to import the keys and try to connect and always get the following detail when I failed to connect...
NX> 203 NXSSH running with pid: 21106 NX> 285 Enabling check on switch command NX> 285 Enabling skip of SSH config files NX> 200 Connected to address: 192.168.2.1 on port: 22 NX> 202 Authenticating user: nx NX> 208 Using auth method: publickey NX> 204 Authentication failed.
what's the trick - there is obviously something very important missing from the web page.
just out of curiosity...does anyone actually have freenx server working on CentOS 4 and have clients connecting to it?
I use it every day :)
On 23/01/06, Craig White craigwhite@azapple.com wrote:
just out of curiosity...does anyone actually have freenx server working on CentOS 4 and have clients connecting to it?
I got it working on WBEL4 but I had to use an older version of the client.
On the server I have:
freenx-0.4.1-1.fdr.0.noarch nx-1.4.9.3-1.FC4.0.i386
And I'm running NX Client for Windows - version 1.4.0-92.
I'd set it up with the latest client and I'm convinced everything was spot-on configuration-wise. Some Googling for whatever error I was getting (this was a few months back) led me to trying an older client.
I should still have the installer lying about if you need it.
Will.
-
Craig White -
Deim Ágoston -
Jaymz Ringler -
Johnny Hughes -
Les Mikesell -
Maciej Żenczykowski -
Paul Schoonderwoerd -
Will McDonald