SItescope can't connect to Linux host

Hi,

 

I'm having trouble setting up a Linux monitor from Sitescope.

Connecting using Putty from the Sitescope server works fine.

From Sitescope web it does not.

Sitescope v11.22

 

Error message:: 
Attempting SSH V1 connect.
SSH V1 connect failed
Attempting SSH V2 connect
SSH V2 connect failed

remote command error (-1)
remote command error (-1)

 

 

Here's the sshd_config of the Debian Linux server I want to monitor:

 

#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/issue.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

 

Attached is a screenshot of the settings in Sitescope.

 

Any ideas how to get this working?

 

Thanks

Parents Reply Children
  • Thanks for your reply Kenneth,

     

    Default shell for the user is Bash. (chsh -s /bin/bash)

    Connecting using Putty and the sitescope credentials to the target machine, I can run echo-commands.

     

    The error in the SiS log says Key Exchange failed for SSH v2 (which is the only one configured on the Linux sshd).

    2015-10-28 14:11:20,862 [http-8080-Processor9] (RemoteCommandLine.java:263) INFO - rem: t_Staging <--internalConnect: Attemting SSH v1 connect

    2015-10-28 14:11:22,445 [http-8080-Processor9] (RemoteCommandLine.java:263) INFO - rem: t_Staging <--internalConnectV1: Failed SSH V1 connect

    2015-10-28 14:11:22,460 [http-8080-Processor9] (SSHV1Connector.java:126) ERROR - internalConnectV1: Connection error occurred(V1): com.mercury.sitescope.util.ssh.SSHConnectionException: Couldn't start terminal!, Couldn't start terminal! connecting to host 64.18.215.174

    2015-10-28 14:11:22,460 [http-8080-Processor9] (RemoteCommandLine.java:263) INFO - rem: t_Staging <--internalConnectV1: Failed SSH V1 connect Couldn't start terminal!

    2015-10-28 14:11:22,569 [http-8080-Processor9] (RemoteCommandLine.java:263) INFO - rem: t_Staging -->close ssh connection

    2015-10-28 14:11:22,569 [http-8080-Processor9] (RemoteCommandLine.java:263) INFO - rem: t_Staging <--SSHV2Connector: Attempting SSH V2 connect.

    2015-10-28 14:11:22,819 [http-8080-Processor9] (RemoteCommandLine.java:263) INFO - rem: t_Staging <--internalConnectV2: Failed SSH V2 connect Key exchange failed: I/O error3: unknown error (uc) dI <I/O error3: unknown error> dI.notify false <null> wFKC.waited false true wFKC.done <false>

    2015-10-28 14:11:22,819 [http-8080-Processor9] (RemoteCommandLine.java:263) INFO - rem: t_Staging -->close ssh connection

    2015-10-28 14:11:22,819 [http-8080-Processor9] (RemoteCommandLine.java:128) ERROR - list of SSH retries -->

    2015-10-28 14:11:22,819 [http-8080-Processor9] (RemoteCommandLine.java:129) ERROR - Wed Oct 28 14:11:22 CET 2015 SSH internalConnectV2: A Connection error occurred: Key exchange failed: I/O error3: unknown error (uc) dI <I/O error3: unknown error> dI.notify false <null> wFKC.waited false true wFKC.done <false> connecting to host 64.18.215.174

    2015-10-28 14:11:22,819 [http-8080-Processor9] (RemoteCommandLine.java:130) ERROR - <-- list of SSH retries

     

    Found this KB https://softwaresupport.hp.com/group/softwaresupport/search-result/-/facetsearch/document/KM1315376?lang=en&cc=us&hpappid=202392_OSP_PRO_HPE 

     

    This key exchange failure might be related to a corrupted key assigned to SiteScope server IP in the target side. These SSH keys are stored normally in /etc/ssh/ssh_known_hosts or, more likely, /home/<your username>/.ssh/known_hosts   (for OpenSSH software).  All SSH software providers should have equivalent files, as per the key exchange process is part of the SSH protocol. 
    Removing the whole file or just the line assigned to the SiteScope server IP or hostname will force a new key exchange as in the first time attempted.

     

    But where does Sitescope store these ssh-keys on a WIndows host?

    The Sitescope service on the Windows host is running as SYSTEM and no specific user.

     

     

  • Hi,

     

    SSH key based authentication is configured as part of the remote setup “Advanced Settings”.

     

    Here you specify the (private) keyfile location. The public key must be added to the “authorized_hosts” file on your Linux system.

     

    I also recommend to check the “SSH version 2 only” option in the advanced settings. This avoids the attempts and failures connecting with SSH v1.

     

    Best Regards

                     Bernhard

  • Thanks for your reply Bernhard.

    I agree using the SSH v2 only option.

    It still gives the error:

    2015-10-28 15:32:57,834 [http-8080-Processor8] (RemoteCommandLine.java:263) INFO - rem: t_Staging <--SSHV2Connector: Attempting SSH V2 connect.

    2015-10-28 15:32:58,115 [http-8080-Processor8] (RemoteCommandLine.java:263) INFO - rem: t_Staging <--internalConnectV2: Failed SSH V2 connect Key exchange failed: I/O error3: unknown error (uc) dI <I/O error3: unknown error> dI.notify false <null> wFKC.waited false true wFKC.done <false>

    2015-10-28 15:32:58,115 [http-8080-Processor8] (RemoteCommandLine.java:263) INFO - rem: t_Staging -->close ssh connection

     

    I want to use the simple password authentication. 

    The key exchange seems to be the problem. PuTTy places its keys under HKEY_CURRENT_USER\SoftWare\SimonTatham\PuTTY\SshHostKeys

     

    But where does SiS store its SSH Host Keys?

     

     

  • This had helped me once, may be this would be helpfull

     

     

    SSETUP SSH DIRECTORY

    1. su - <Account>
    2. mkdir /home/<Account>/.ssh
    3. mv /tmp/<Account>.pub /home/<Account>/.ssh/authorized_keys2
    4. chmod 400 authorized_keys2
    5. chown –R <Account> /home/<Account>

    MODIFY SSHD SETTINGS

    1. Edit /etc/ssh/sshd_config
    2. Change and uncomment the following entries

    • AuthorizedKeysFile .ssh/authorized_keys2

    3. /etc/init.d/sshd stop
    4. /etc/init.d/sshd start

     

    Sandeep

  • Thanks for your reply Sandeep.

     

    You think it's the remote Linux host causing the problem?

    I'm able to connect using Putty from the Sitescope Windows 2008-server and able to ssh using terminal on my OSX-machine.

     

    The file: /tmp/sitescope.pub does not exist on the linux host.

    Should that have been created when I use Putty from the Sitescope host to connect to the Linux host?

     

  • Sandeeps procedure is referring to key based authentication (authorized_hosts).

    As of your previous post this does not seem to be your issue.

     

    The initial key exchange refers to the host keys, which allows the ssh client to verify the identity of the ssh server by comparing to a previously stored key (known_hosts file). SIS does not store the ssh server keys.

     

    One possible issue could be that your SSH client is using ECDSA host keys instead of providing RSA based keys. Afaik, SiteScope currently does not support ECDSA host keys.

    The host keys on your Linux system should be stored under /etc/ssh. If ECDSA based keys are used, try reconfiguring your system to use RSA based keys instead.

  • Thanks Bkappler, that sounds like it could be the issue.

     

    Below is the sshd_config file on the server. 

    It does have the ssh_host_rsa_key in the list of host_keys.

    And RSAAuthentication set to Yes.

     

    Can you see any other settings that would prevent SiS ssh from working?

     

     

    # 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

    HostKey /etc/ssh/ssh_host_ed25519_key

    #Privilege Separation is turned on for security

    UsePrivilegeSeparation yes

     

    # Lifetime and size of ephemeral version 1 server key

    KeyRegenerationInterval 3600

    ServerKeyBits 1024

     

    # Logging

    SyslogFacility AUTH

    LogLevel INFO

     

    # Authentication:

    LoginGraceTime 120

    PermitRootLogin without-password

    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/issue.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

  • Hi,

     

    Your sshd_config looks good to me. Please double check that the RSA hosts keys on your Linux system exist (/etc/ssh/ssh_host_rsa_key). If not you need to create RSA host keys (ssh-keygen).

     

    You could also try uncommenting the two lines

     

    HostKey /etc/ssh/ssh_host_ecdsa_key

    HostKey /etc/ssh/ssh_host_ed25519_key

     

    from your config file, restart sshd and try again. But, as long as you have valid RSA host keys SiteScope should be able to connect.

     

    If it still doesn’t work please contact me through a private message and I’ll have a look at your system.

     

    Best Regards

                Bernhard

  • Verified Answer

    Hi,

    In an online session with Soderborg, we were able to identify and resolve the ssh connection issue.

    Here’s a summary of our findings:

    Looking at /var/log/auth.log on the Linux system, we found:

                    sshd[…]: fatal: Unable to negotiate a key exchange method [preauth]

    We enabled SSH debugging for SiteScope

          …\conf\core\Tools\log4j\PlainJava\log4j.properties

             log4j.category.com.mercury.sitescope.util.ssh=DEBUG, monitors.appender

             log4j.category.SSHTrace=DEBUG, monitors.appender

    This confirmed that the key exchange algorithms offered by the Linux system (SSH-2.0-OpenSSH_6.7p1) “peer kex algorithms” and the algorithms offered by SiteScope “our kex algorithms”, did not match.

    After updating the “KexAlgorithms “ in /etc/ssh/sshd_config on the Linux system adding a kex algorithm supported by SiteScope and restarting sshd, ssh connections from SiteScope to the Linux system succeeded.

    We plan to update the key exchange algorithms offered by SiteScope in a future release.

    Best Regards

                    Bernhard

     

     

     

  • hello Advisor

    i have same problem with ssh 6.7. Please tell me how to updating---"

    After updating the “KexAlgorithms “ in /etc/ssh/sshd_config on the Linux system adding a kex algorithm supported by SiteScope and restarting sshd, ssh connections from SiteScope to the Linux system succeeded.---"

    best regards

    vincent chen