Clients cannot establish connection

Learn how to troubleshoot client issues with connecting to HSTS .

Procedure

  1. Test SSH ports and HTTP/HTTPS ports.
    1. On the client computer, run the following command:
      # telnet server_ip_address port
      For example, to test connection to 10.0.1.1 through TCP/33001, you run the following command:
      # telnet 10.0.1.1 33001
    2. If the client cannot establish connections to the ports, verify the port number and the firewall configuration of HSTS. Also, make sure that the client firewall allows outbound connections.
  2. Test UDP ports.
    If you can establish an SSH connection but not run a FASP® file transfer, might be a firewall blockage of FASP UDP port.
  3. Verify SSH service status.
    If there is no firewall blockage between the client and HSTS, on the client machine, try establishing an SSH connection: (HSTS address: 10.0.1.1, TCP/33001)
    # ssh aspera_user_1@10.0.1.1 -p 33001

    If the SSH service runs normally, the client must see a message that prompts to continue the connection or for a password. However, if you see a Connection Refused message, which indicates that the SSH service isn't running, review your SSH service status. Ignore the permission denied message after the password is entered, which is discussed in next steps.

  4. Applied authentication method is enabled in SSH.
    If you can establish an SSH connection, but it returns permission denied message, the SSH Server on HSTS might have password authentication that is disabled:
    Permission denied (publickey,keyboard-interactive).

    Open your SSH Server configuration file with a text editor:

    /etc/ssh/sshd_config

    To allow public key authentication, add or uncomment the PubkeyAuthentication yes. To allow password authentication, add or uncomment PasswordAuthentication yes.

    Configuration example,
    ...
    PubkeyAuthentication yes
    PasswordAuthentication yes
    ...

    To activate your changes, restart the SSH server.

  5. Restart the SSH server to apply new settings.
    Restarting your SSH server does not affect currently connected users.
    # systemctl restart sshd.service
    or for Linux® systems that use init.d:
    # service sshd restart
  6. Verify that the user credentials are correct, and the user has sufficient access permissions to their docroot.
    1. Attempt to establish an SSH connection:
      # ssh username@server_ip_address -p  port
      For example,
      $ ssh aspera_user_1@10.0.1.1 -p 33001
    2. Enter the user's password.
      If you see Permission denied message, you might have a wrong user credentials, or the user doesn't have sufficient access permissions to its docroot.