Your browser does not allow storing cookies. We recommend enabling them.


Logging in with Command-Line sshg3

You can connect to a remote host by using sshg3 on the command line:

  1. Enter the sshg3 command using the following syntax:

    $ sshg3 <hostname>

    For example:

    $ sshg3

    The basic syntax is:

    $ sshg3 user@host#port


    • user - Enter a user name that is valid on the remote host. The user@ attribute is optional. If no user name is given, the local user name is assumed.

    • host - Enter the name of the remote host as an IP address, FQDN (fully qualified domain name), or short host name. The remote host must be running a Secure Shell version 2 server.

    • port - Enter the number of the Secure Shell listen port on the remote server. The #port attribute is optional. If no port is given, the default Secure Shell port 22 is assumed.

    If you have defined connection profiles in the ssh-broker-config.xml file, you can also connect by using the name of the connection profile, for example:

    $ sshg3 profile1

    In this case, the settings defined in the profile (host name, port, user name etc.) are used for the connection. For instructions on creating and editing the connection profiles, see the section called “The profiles Element”.

    For more information on the sshg3 commands and options, see sshg3(1).

  2. The server authentication phase starts. The server sends its public key to the client for validation (when server public-key authentication is used).

    Tectia Client checks if this key is already stored in your own host key directory. If not, the host key directory common to all users on your computer is checked next.

    If the host key is not found, you are asked to verify it.

    When Tectia Client receives a new host public key, a host identification message is displayed. For example:

    $ sshg3 user@host
    Host key not found from database.
    Key fingerprint:
    You can get a public key's fingerprint by running
    % ssh-keygen-g3 -F
    on the keyfile.
    Are you sure you want to continue connecting (yes/no)?

    The message shows the fingerprint of the host's public key in the SSH Babble format that is a series of pronounceable five-letter words in lower case and separated by dashes.

  3. Verify the validity of the fingerprint, preferably by contacting the administrator of the remote host computer by telephone.

    After the fingerprint has been verified and found to be correct, it is safe to save the key and continue connecting. You can also select to cancel the connection, or to proceed with the connection without saving the key.

    If you choose to save the server public key, relevant information about the key will be stored on the client host in directory $HOME/.ssh2/hostkeys on Unix or in %APPDATA%\SSH\HostKeys on Windows. After the first connection, the locally stored information about the server public key will be used in server authentication.

    For more information on server authentication, see Server Authentication with Public Keys.

  4. The user authentication phase starts. You will be prompted to authenticate yourself to the server with your password or with the passphrase of your private key (if your public key has already been uploaded to the server). The required authentication method depends on the server settings.

    After the server has successfully authenticated you, the Secure Shell connection to the server is opened.




What to read next:

  • Reduce Secure Shell risk. Get to know the NIST 7966.

    The NISTIR 7966 guideline from the Computer Security Division of NIST is a direct call to action for organizations regardless of industry and is a mandate for the US Federal government.
    Download now
  • ISACA Practitioner Guide for SSH

    With contributions from practitioners, specialists and SSH.COM experts, the ISACA “SSH: Practitioner Considerations” guide is vital best practice from the compliance and audit community.
    Download now