Logging in with Command-Line sshg3

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

Enter the sshg3 command using the following syntax:

$ sshg3 <hostname>

For example: $ sshg3 abc.example.com.

The basic syntax is:

$ sshg3 user@host#port

where:

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

host - Enter the name of the remote host as an IP address, FQDN, or short hostname. 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 (hostname, port, username 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 command-line commands and options, see Appendix C.

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

Tectia ConnectSecure 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 ConnectSecure 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:
xecic-fifub-kivyh-kohag-zedyn-logum-pycuz-besug-galoh-gupah-xaxby
You can get a public key's fingerprint by running
% ssh-keygen-g3 -F publickey.pub
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.

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 connecting 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.

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.

Copyright 2012 Tectia Corporation This software is protected by international copyright laws. All rights reserved.Contact Information

Highlights from the SSH.COM blog:

Cryptomining with the SSH protocol: what big enterprises need to know about it

Cryptomining malware is primarily thought of as targeting desktops and laptops and is used to hijack system resources to mine cryptocurrency. Read more

SLAM the door shut on traditional privileged access management

Did you know that something as trivial-sounding as granting access for your developers or third parties to a product development environment can throw a gorilla-sized monkey wrench into your operations and productivity? Read more

We broke the IT security perimeter

Everyone understands the concept of a security perimeter. You only gain access if you are identified and authorized to do so. Read more

SSH Webinar:

The evolution of 3rd party access – four use cases

Join Ubisecure and SSH.COM webinar on Tuesday 22 January to learn how cloudification has changed the rules of mission-critical access.