Connection
/ SSH1
The SSH1 category of the Session Options
dialog allows you to configure your SSH1 The first version of the SSH protocol which provides a way to encrypt network traffic between a client and a server.
connection A data path or circuit between two computers over a phone line, network cable, or other means. . The SSH1
category only appears when you have selected SSH1 as your
Protocol.
SSH1 Overview
Port forwarding The concept of connecting a logical port on a local machine to a port on a remote machine over a secure (encrypted) channel. All requests for services sent to the local port are then forwarded across the secure channel to the corresponding port on the remote machine. is another feature based on SSH security. See Port Forwarding with SSH to learn more about encrypting connections for other applications (such as IMAP) that are not secure by default.
SSH1 connection settings include hostname, port, username, authentication The process of verifying that an individual truly is who he or she claims to be. Supplying a password is a very common method of authentication. The most secure method of authentication supported in SecureCRT is public-key authentication. See also: identity file, public-private key pair., and key exchange.
Hostname
The hostname or IP address of the remote machine that provides the SSH1 service.
Port
The port number of the SSH1 service on the remote machine. For SSH1,
the default port is 22.
Firewall
If your connection involves a firewall, select your firewall from the list of firewalls that have been configured in the Global Options/Firewall dialog.
Note: You can also select an SSH2 session to be used as a firewall. When a session is specified as a firewall, the firewall session will be connected first.
Username
The username used to log on to the remote machine.
Authentication
SecureCRT supports three types of authentication for connecting to SSH1 servers: password, RSA, and TIS.
Password authentication
transmits the user's password to the server to authenticate the connection.
The transmitted password is protected from network eavesdropping, due
to the cipher encryption of the data channel. For this reason, some SSH1
servers reject the use of password authentication if the cipher is set
to None.
RSA authentication uses a public/private key pair to authenticate the connection. The general mechanism behind RSA authentication is that the SSH1 server "challenges" the client A computer or application that uses services provided by a server. to decrypt a message encoded using the user's public key stored on the server. Upon connecting, the SSH1 server generates a random value, encrypts the value using the user's public key and sends the encrypted challenge to the client. The client authenticates the connection by successfully decrypting the challenge using the user's private key. The security of the mechanism requires that no one but the owner have access to the private key. The private key is stored locally in an identity file Identity files are two files containing the public-private key pair used to connect to an SSH server using RSA or DSA authentication. The Identity file contains the public and private key pair and is used by SecureCRT. The Identity.pub file contains only the public key which is usually appended to the authorized_keys file. . The first time you connect to an SSH1 server using RSA authentication, SecureCRT will prompt you for the location of this file. Also, prior to using RSA authentication, the public key must be made available to the SSH1 server.
TIS firewall authentication uses the TIS firewall server to provide a challenge phrase / response combination. SSH1 servers must be configured to offer TIS authentication.
Key exchange group
Key exchange is part of establishing trust between a client and a Secure Shell server. SecureCRT supports several algorithms for doing key exchange and will attempt to use them in the order that you specify.
Diffie-Hellman key exchange algorithms are common cryptographic protocols which are supported by Secure Shell servers.
GSSAPI key exchange algorithms can be used to connect to SSH2 servers that support GSSAPI. When a GSSAPI key exchange algorithm is specified and the server supports it, further authentication is not needed if you already have GSSAPI credentials (e.g., by logging onto a Windows machine that is part of an Active Directory domain).
If a GSSAPI key exchange algorithm is specified and is not supported by the server, there could be a delay during connection because the server is waiting to time out. To prevent this delay, uncheck the GSSAPI key exchange algorithms.