SSH Communications Security
Index
SSH Home page
Previous Next Up [Contents] [Index]

    Introduction >>
    Configuration >>
    Connecting >>
    Terminal Window >>
    File Transfer >>
    Toolbar Reference >>
    Menu Reference >>
    Advanced Information >>
        SSH2 Functionality
            Host Keys
            Security Properties
        Public-Key Infrastructure (PKI) >>
        Using Certificate Authentication>>
    Troubleshooting >>
    Appendices >>

SSH2 Functionality

The SSH Secure Shell for Workstations Windows client connects and logs into the specified remote host computer. Upon login, the user must prove his identity to the remote host computer by using some authentication method.

Public-key authentication is based on the use of digital signatures. Each user creates a public / private key pair for authentication purposes. The server knows the user's public key, but only the user has her private key.

When the user tries to authenticate herself, the server sends a challenge to the user. User is authenticated by signing the challenge using the private key.

Private / public key pairs can be created with a built-in key generation wizard. (See section Key Generation Wizard.)

Other authentication methods can be used as well. If other methods fail, the SSH Secure Shell for Workstations Windows client prompts for a password. Since all communications is encrypted, the password will not be available for eavesdroppers.

When the user's identity has been accepted by the server, the server either executes the given command, or logs into the remote host computer and gives the user a normal shell on the remote computer. All communication with the remote command or shell will be automatically encrypted. The session can be transparent and can be used to reliably transfer binary data.

The session terminates when the command or shell on the remote machine exits and all X11 and TCP/IP connections have been closed. The exit status of the remote program is returned as the exit status of ssh2.

If the user is using X11, the connection to the X11 display is automatically forwarded to the remote side in such a way that any X11 programs started from the shell (or command) will go through the encrypted channel, and the connection to the real X server will be made from the local machine.

SSH2 will also automatically set up Xauthority data on the server machine. For this purpose, it will generate a random authorization cookie, store it in Xauthority on the server, and verify that any forwarded connections carry this cookie and replace it by the real cookie when the connection is opened. The real authentication cookie is never sent to the server machine (and no cookies are sent in the plain).

If the user is using an authentication agent, the connection to the agent is automatically forwarded to the remote side unless disabled.

Forwarding of arbitrary TCP/IP connections over the secure channel can be specified. TCP/IP forwarding can be used for secure connections to electronic wallets or going through firewalls.

SSH2 automatically maintains and checks a database containing public keys of hosts. When logging on to a host for the first time, the host's public key is stored to a file in the user's personal directory. If a host's identification changes, SSH2 issues a warning and disables password authentication to prevent for example a malicious Trojan horse program from getting the user's password. Another purpose of this mechanism is to prevent man-in-the-middle attacks that could otherwise be used to circumvent the encryption.

SSH2 also has built-in support for SOCKS version 4 for traversing firewalls.

Host Keys

Security Properties

Previous Next Up [Contents] [Index]


[ Contact Information | Support | Feedback | SSH Home Page | SSH Products ]

Copyright © 2001 SSH Communications Security Corp
All rights reserved.
Copyright Notice