November 17, 2013 at 00:11 #773
TL;DR – this may be procedural, but I cannot connect after the installation of the latest NoMachine client on Debian Wheezy right after the successful installation and services appear running normally.
I’ve used NoMachine in the past and the install was fairly easy from repo or download and run with the package manager. I never had to configure much, if at all for a few of the installations and I may be approaching this from a bias perspective. It was more like a ‘set it and forget it’ situation before for the last few weeks. Now with the newer version and a different distro, I’m not having such luck but I’m eager to get it working as I have homework to get completed within a month I need to do from outside of the home.
Installed latest NoMachine_4.0.366_1_amd64.deb package with the instructions on NoMachine’s site last night (this is the 3rd attempt). Worked like a charm and showed services were running, but I yet again failed to authenticate.
uname -a Linux LOCALHOST 3.2.0-4-<strong>amd64</strong> #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux
So my yes/no PEBCAK question: is the installation supposed to work “out of the box” after running the installation like in my past experiences? If yes: what logs do I need to gather and post. If no: then I need to read better documentation than the local READMEs and such on exactly what I’m doing wrong. This distro is freshly installed other than a few apps I got off of apt-get. I was running a bare metal hypervisor before and finally decided on Debian.
…After failing to find the right documentation to address the issue, I stated tinkering in the GUI, which was also having errors. Then I enabled upnp on the router (which I didn’t see as a prereq for the installation). Never liked upnp, but I need this to work. After that is enabled, NX is running. Then it check marks the box for the NX port that is active, but the SSH fails to configure with the above error in the gui. I tried searching Google and the forums and I’m honestly lost as I’m not finding the correct solution for Debian or like Debian distros. I tried tweaking the sshd conf and other stuff like cert gen, but nothing has worked, had to back out those bad changes, and I’ve been stuck for two weeks.
I am unable to establish a remote connection even with SSH enabled, with a non-root account, and it just fails right away (local LAN and Internet). I feel like I’m missing something obvious, but for the life of me I can’t find the most correct instructions for post installation configurations. Sort of stuck in a loop of scouring bing and google but no luck and the last several weeks I’ve spent most of my free time reading documentation, but it’s mostly not related to my single connection home environment.
*I’ve already uninstalled cleanly and reinstalled with a prior version as well. I thought it the moment to stopy wasting time and hopefully not waste other’s time and use the lastest.
Attempts to connect remotely result in the error “NX> 204 Authentication failed.” from Windows 7 machines. I have yet to test with another LInux or Mac device.
Occurs with the most recent NoMachine client for Windows 3.5.0_9.
Now, I believe I have a configuration error as the server appears to be running and the services are in the background, but I am not getting clear instructions when I search for post installations for Debian; instructions I have found were for the past versions of both nomachine (mostly the open source bit) and Debian (and not a mix of both) and the previous attempt to perform such actions in my install have resulted to a bunch of ssh keys being generated but never make a difference after sshd is updated. Plus the newer version likley works without much configs vs postings like this link here http://www.linuxquestions.org/questions/linux-software-2/a-guide-to-set-nomachine-nx-3-5-x-up-on-debian-wheezy-and-possibly-others-917816/
I’m attaching my sshd conf file and current gnome info (because it’s in what to include) – let me know if I can help fix this for myself and others by adding more logs to the fire. I’m hoping it’s something easy to correct.
Cheers!November 17, 2013 at 00:18 #774
Evidently, after looking at my post the attached files were blocked for security reasons.
The first one is the default config for SSHD on Debian Wheezy, or should be… I had to restore a few files:
# Package generated configuration file # See the sshd_config(5) manpage for details # What ports, IPs and protocols we listen for Port 22 # Use these options to restrict which interfaces/protocols sshd will bind to #ListenAddress :: #ListenAddress 0.0.0.0 Protocol 2 # HostKeys for protocol version 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_ecdsa_key #Privilege Separation is turned on for security UsePrivilegeSeparation yes # Lifetime and size of ephemeral version 1 server key KeyRegenerationInterval 3600 ServerKeyBits 768 # Logging SyslogFacility AUTH LogLevel INFO # Authentication: LoginGraceTime 120 PermitRootLogin yes StrictModes yes RSAAuthentication yes PubkeyAuthentication yes #AuthorizedKeysFile %h/.ssh/authorized_keys # Don't read the user's ~/.rhosts and ~/.shosts files IgnoreRhosts yes # For this to work you will also need host keys in /etc/ssh_known_hosts RhostsRSAAuthentication no # similar for protocol version 2 HostbasedAuthentication no # Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication #IgnoreUserKnownHosts yes # To enable empty passwords, change to yes (NOT RECOMMENDED) PermitEmptyPasswords no # Change to yes to enable challenge-response passwords (beware issues with # some PAM modules and threads) ChallengeResponseAuthentication no # Change to no to disable tunnelled clear text passwords #PasswordAuthentication yes # Kerberos options #KerberosAuthentication no #KerberosGetAFSToken no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes # GSSAPI options #GSSAPIAuthentication no #GSSAPICleanupCredentials yes X11Forwarding yes X11DisplayOffset 10 PrintMotd no PrintLastLog yes TCPKeepAlive yes #UseLogin no #MaxStartups 10:30:60 #Banner /etc/tissue.net # Allow client to pass locale environment variables AcceptEnv LANG LC_* Subsystem sftp /usr/lib/openssh/sftp-server # Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication and # PasswordAuthentication. Depending on your PAM configuration, # PAM authentication via ChallengeResponseAuthentication may bypass # the setting of "PermitRootLogin without-password". # If you just want the PAM account and session checks to run without # PAM authentication, then enable this but set PasswordAuthentication # and ChallengeResponseAuthentication to 'no'. UsePAM yes
The later is the same default config, but for gnome:
Occurs with the most recent NoMachine client for Windows 3.5.0_9
The most recent NoMachine client for Windows is probably a 4, not a 3.5, given that you say you have installed a 4.0.366 on Linux.
SSH connections are not supported in the free 4. This is stated in a multiple places in the docs, for example here:November 17, 2013 at 23:02 #780
Oh, so it’s not like the same connection type in the past? Aha – now that makes sense considering the NX protocol is not fully encrypted but optimized for speed. I failed to make that corelation before until now.
I also wasn’t aware that this was a 4 ‘free’ version linux and was quite a bit different from the past. I don’t need to use SSH. Thanks for clearing this up for me!
- This topic has 3 replies, 2 voices, and was last updated 9 years ago by .
Viewing 4 posts - 1 through 4 (of 4 total)
Viewing 4 posts - 1 through 4 (of 4 total)