Open the SSVNC client and, within the main SSVNC client window, fill in the required fields.
SSVNC is supported by Windows and Linux operating systems. One example is SSVNC which, while basic, will tunnel over SSH before making a VNC connection. Other VNC clients, however, do include SSH tunneling within the client itself. While TightVNC is a popular Windows client for VNC connections, it doesn’t support SSH tunneling within the client itself, requiring you to use PuTTY to make the connection. Then finally, if you are logging onto a machine remotely via some NAT setup, make sure that the port/port range forwarding is pointing you to the correct machine.If your SSH connection is working correctly, TightVNC should load your remote VNC desktop window, ready for you to use. If it works as localhost, see if there is some weird restriction on /etc/ssh/sshd_config that allow logins only from certain hostmasks. To verify that it is set as permissive, then try again.ĭ) Check /etc/ssh/sshd_config - did someone addīecause that will totally cause headaches.Į) When in doubt, change passwords as root, then test it on the SuSE box by logging in as localhost.
Received disconnect from 10.0.1.234 port 22:2: Too many authentication failures for nickĬlick to expand.Don't comment out UsePAM - it doesn't explicitly set that as a no, and besides, even that is a bad move - disabling PAM will disallow password logins altogether.Ī) Did you enable NIS+/YP or Kerberos SSO authentication on that machine, did you? If you did, local passwords are ignored.ī) Did someone mess with nf to effectively block yourself from logging in?Ĭ) What about SELinux? Did someone mess with the rules? If not sure, get in as root, and run:
Debug1: Reading configuration data /etc/ssh/ssh_configĭebug1: /etc/ssh/ssh_config line 48: Applying options for *ĭebug1: Connecting to 10.0.1.234 port 22.ĭebug1: key_load_public: No such file or directoryĭebug1: identity file /Users/nick/.ssh/id_rsa type -1ĭebug1: identity file /Users/nick/.ssh/id_rsa-cert type -1ĭebug1: identity file /Users/nick/.ssh/id_dsa type -1ĭebug1: identity file /Users/nick/.ssh/id_dsa-cert type -1ĭebug1: identity file /Users/nick/.ssh/id_ecdsa type -1ĭebug1: identity file /Users/nick/.ssh/id_ecdsa-cert type -1ĭebug1: identity file /Users/nick/.ssh/id_ed25519 type -1ĭebug1: identity file /Users/nick/.ssh/id_ed25519-cert type -1ĭebug1: Local version string SSH-2.0-OpenSSH_7.6ĭebug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1ĭebug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000ĭebug1: Authenticating to 10.0.1.234:22 as 'nick'ĭebug1: kex: algorithm: kex: host key algorithm: ecdsa-sha2-nistp256ĭebug1: kex: server->client cipher: MAC: compression: noneĭebug1: kex: client->server cipher: MAC: compression: noneĭebug1: expecting SSH2_MSG_KEX_ECDH_REPLYĭebug1: Server host key: ecdsa-sha2-nistp256 SHA256:+oqECzMl38RtReemyOUl+p9pPcljMnoC/Deyq3mc2awĭebug1: Host '10.0.1.234' is known and matches the ECDSA host key.ĭebug1: Found key in /Users/nick/.ssh/known_hosts:1ĭebug1: Authentications that can continue: publickey,password,keyboard-interactiveĭebug1: Next authentication method: publickeyĭebug1: Trying private key: /Users/nick/.ssh/id_rsaĭebug1: Trying private key: /Users/nick/.ssh/id_dsaĭebug1: Trying private key: /Users/nick/.ssh/id_ecdsaĭebug1: Trying private key: /Users/nick/.ssh/id_ed25519ĭebug1: Next authentication method: keyboard-interactiveĭebug1: Next authentication method: password: