• Main Menu
  • SSH (Secure Shell)


    SSH (Secure Shell) is one of the most widely-used network protocols supporting secure data communication in academia and industry today. The protocol supports remote command execution, command-line login, and other secure network services between two networked computer hosts. The computers make use of a secure channel that is setup over an insecure network and both a client and server computer that run the applicable SSH server and client applications. The two major versions of SSH in use today are SSH-1 and SSH-2. The encryption built-in to SSH communications helps provide both data integrity and confidentiality when communicating over a network or the Internet as compared to the legacy protocol, Telnet.

    How Does SSH (Secure Shell) Work?

    Secure Shell (SSH) leverages public key cryptography in order to authenticate both the remote computer and user (if required). There are a number of ways that SSH is employed throughout industry. One of the methods is to have the system automatically create public and private key pairs to encrypt the network connection. When using this method, password authentication is required in order to allow the end-user to log on to the system.

    An alternative method for the use of SSH is to setup the system to use manually created public and private key pairs to conduct network authentication. This method allows other programs or users to log-in without having to use password authentication. In this application, any end-user is able to generate a matching pair of keys. Once created, the public key is then sent to all computers that are required to allow access to the respective owner of the matching private key (the private key has to be kept secret). Although the authentication is based on the private key in this case, the key is not transferred over the network during the authentication phase of communications. Instead, Secure Shell will verify that the computer which is offering the public key also has ownership of the private key.

    In every version of SSH, it is a critical requirement to validate all unknown public keys to associate computer hosts with identities. This step is required before accepting a connection as a valid attempt. If a rogue actor or hacker’s public key is accepted without validation, then unauthorized access to system resources could be granted.

    How are SSH Keys Managed?

    On UNIX and Unix-like operating systems, the authorized public keys are stored in the home directory of the user account that is permitted to login remotely. The file path and name are: ~/ssh/authorized_keys. If the file is writable by anyone besides the owner and root it will not be recognized by SSH. Once the public key is present on the remote-end of the connection and associated private key on the local computer, the password is not required on some configurations of SSH. Some network setups will lock the private key with a passphrase in order to maintain a greater degree of security. The private key location’s path can be specified on a command line option using the –I setting and the ssh-keygen utility program will also produce the public and private keys in pairs.

    Secure Shell (SSH) provides support for password-based authentication which is encrypted through the automatic generation of key pairs. If a rogue actor is able to imitate the legitimate side of an SSH connection using the password authentication option, it is possible for he or she to execute the “man-in-the-middle” attack if the two computers have never authenticated with each other before. If they have, then the attack will be unsuccessful since SSH will remember the key previously used by the remote computer.

    SSH (Secure Shell) History

    SSH Version 1.X

    The first version of SSH, now labeled SSH-1, was designed by Tatu Ylönen in 1995. His work was motivated by a password-sniffing attack that occurred at Helsinki University of Technology (his place of work). The primary goal of SSH was to provide a replacement technology for the Telnet, rsh, and rlogin protocols that did not guarantee confidentiality or provide a means for strong authentication. Ylönen released his implementation of SSH as freeware in the summer of 1995. By the end of the year, there were more than 20,000 users of the software located in more than 50 countries.

    By the end of 1995, Tatu Ylönen would go on to found the SSH Communications Security company in order to help him further develop and market SSH. The first version of SSH software used a number of free software libraries such as libgmp (GNU). Later releases of SSH would increasingly leverage proprietary software. In just four years of use, there were an estimated two million users of SSH by 2000.

    SSH-1 Vulnerabilities

    In 1998, there was a vulnerability discovered in SSH 1.5 that allowed rogue actors to insert content into encrypted SSH streams. This vulnerability was due to the data integrity protection from CRC-32 being insufficient. In order to fix the problem, the SSH Compensation Attack Detector was included in the subsequent builds of the SSH project. Unfortunately, this fix included a new integer overflow vulnerability. This vulnerability could actually be worse than the integrity issue it was intended to fix. An attacker could take advantage of the overflow vulnerability and execute code in the root of the computer with the same privileges as the SSH daemon.

    In early 2001, a new vulnerability with SSH was found which allowed attackers to modify the last block of IDEA-encrypted sessions. In a similar timeframe, another vulnerability in SSH was found which would allow malicious servers to forward client authentication on to other servers. Due to the number of design flaws inherent in SSH-1, the version of the protocol is now considered to be obsolete. The majority of modern computer client and servers now support the SSH-2 protocol.

    SSH Version 2.X

    In 2006, the IETF working group, Secsh, released a revised version of the SSH protocol named SSH-2. The new released was subsequently adopted as an international standard and is not compatible with SSH-1. SSH-2 features improved security and features that were not included in the original SSH protocol. Improved security in SSH-2 is achieved through the use of a Diffie-Hellman key exchange and a stronger integrity check that uses message authentication codes. The improved protocol also includes the ability to run more than one shell session over a single connection which is not possible under the original protocol.

    SSH-2 Vulnerabilities

    In the fall of 2008 (November), there was a theoretical vulnerability found for all versions of SSH. This vulnerability would allow up to 32 bits of plaintext to be recovered from a single block of ciphertext which was encrypted in the default SSH encryption mode (CBC). As a result, if users were concerned about the vulnerability, they could simply shift to using CTR mode to make the SSH build resistant to the attack.

    SSH-1 Version 1.99

    After SSH 2.1 was released, RFC 4253 was released that specified all SSH servers which supported both SSH-2 and legacy builds of SSH should be labeled as SSH 1.99. Although this is not a true version of the software build, the label is used to identify servers which help support backward compatibility with the server versions.

    SSH-2 Architecture Improvements

    The SSH-2 protocol internal architecture is defined in RFC 4251. There are well-defined layers within the protocol to include: the transport layer, user authentication layer, and connection layer.

    SSH-2 Transport Layer

    The SSH-2 transport layer is defined by RFC 4253 and is responsible for handling both server authentication and the initial key exchange. It also conducts integrity verification, compression, and sets up session encryption. The transport layer is exposed to the upper layer of the protocol through an interface for sending and receiving plaintext data packets with allowable sizes of up to 32,768 bytes. This size can be changed through the implementation of the protocol. The transport layer is also responsible for arranging the re-exchange of keys after one hour or 1GB of information has been transferred between two computers (whichever metric is reached first).

    SSH-2 User Authentication Layer

    The SSH-2 user authentication layer is defined by RFC 4252 and is responsible for providing a number of authentication methods as well as handling client computer authentication. In SSH-2, all authentication is client-driven. For example, when a password prompt is delivered, it is the SSH client that conducts the prompting, not the SSH server. The SSH server will simply respond to all SSH client authentication requests.

    Some of the most used SSH user authentication methods include:

    Publickey: An SSH method for public key authentication. This normally supports a minimum of RSA or DSA keypairs. There are SSH implementations which also support X.509 certificates.

    Keyboard Interactive: Keyboard interactive is a method where the SSH server will send one or many prompts to the client to input information. The client computer will display the prompts and return any user input to the server. This option is defined in RFC 4256 and is commonly used to help provide one-time password authentication to SecurID or S/Key.

    Password: This is the method used for traditional password authentication. It also includes a means for the end-user to change their password, but is not implemented by all SSH capable applications.

    GSSAPI Authentication Methods: These methods are used to help provide an extensible scheme for SSH authentication using external mechanisms. Some of the external authentication mechanisms include NTLM or Kerberos 5 which give the end-user the capability for a single sign on feature. GSSAPI is normally found in commercial SSH builds, but OpenSSH has started supporting a working implementation of the feature at the time of this writing.

    SSH-2 Connection Layer

    The SSH-2 connection layer is defined by RFC 4254 and is responsible for defining channels as well has handling global and channel requests. In SSH-2, a single connection is able to host a number of channels at the same time supporting two-way communications. A typical channel will include: a shell for terminal shells as well as SFTP and exec requests, forwarded tcpip for server to client forwarded connections, and direct tcpip for client to server forwarded connections.

    What are the uses for SSH?

    Since it was first released in the mid-1990s, there have been a number of applications for SSH developed across most operating systems (Unix, Linux, Mac OS X, Solaris, and Microsoft Windows). A number of the applications that have been developed require a specific build or version of specific SSH client/server software. Some of the numerous uses of SSH in industry and academia include:

    –          Establishing a VPN (OpenSSH is the only public implementation that supports this feature at the time of writing).

    –          Supporting secure file transfers.

    –          Login to a shell on a remote computer host (effectively replacing the unsecure rlogin and Telnet protocols).

    –          To surf the Internet through an encrypted proxy connection with an SSH client program that supports the SOCKS protocol.

    –          To securely mount a directory on a remote server using SSHFS.

    –          Combined with rsync for back-up of files, helps to copy and mirror files in a secure manner.

    –          To forward X from a remote host through one or many intermediate computer hosts.

    –          To forward or tunnel a port.

    –          To automate remote management and monitoring of computer servers.

    –          To support SCP (secure copy) that has been developed from the RCP protocol.

    –          To support SFTP, SSH Fire Transfer Protocol.

    Development of OpenSSH and OSSH

    By 1999, there was a strong demand signal in the development community for a free version of SSH to be released under an open source license. The legacy build of SSH, version 1.2.12, was subsequently released as open source and Björn Grönvall developed OSSH from this codebase. In the same timeframe, OpenBSD would fork this work and create OpenSSH that was included with the OpenBSD 2.6 release. This branch would subsequently be branched into a portability version to run on alternative operating systems. By 2005, OpenSSH would be the most popular SSH implementation and be included as a default part of a number of operating systems. Since that time, OSSH would become obsolute while OpenSSH continues to be maintained and supports both 1.X and 2.X versions of the SSH protocol.

    How to Install OpenSSH on Windows

    The easiest way to install OpenSSH on a computer running the Windows OS is to start with installing Cygwin/X. Cygwin/x is a UNIX-like environment that is available to download, install, and use for free on Windows computers.
    Step 1 – Login to your computer with an account that has administrator level permissions.
    Step 2 – Download and install Cygwin/x on the target computer. Ensure the following packages are included with the installation: Make, g++ compiler, Zlib, Cygrunsrv, and perl.
    Step 3 – Download the OpenSSH Tarball file from the project’s homepage. Then, unpackage the file to the /Cygwin/usr/local directory.
    Step 4 – Download the OpenSSL Fips tarball from the project’s website. Then, upackage the tarball to the /Cygwin/usr/local directory location on your computer.
    Step 5 – Add the Cygwin/Bin directory to the environmental variables on your computer.
    Step 6 – Depending on the version of Microsoft Windows installed on your computer, restart the machine if required for the environmental variable changes to take effect.
    Step 7 – Open the Cygwin program. Then change the directory to the Open SSL directory by entering the following command followed by pressing the “enter” key:
    cd usr/local/openSSL
    Step 8 – Configure OpenLL by entering the following command:
    ./configure BSD-generic32  fipscanisterbuild
    Step 9 – Make the OpenSSL install by entering the following command in the Cygwin interface:
    make install
    Step 10 – Change directories to the Open SSH directory by using the following commands:
    cd  /usr
    cd /local
    cd  /openSSH
    Step 11– Now, you will want to configure the OpenSSH project by entering the following command:
    ./configure –with-ssl-dir=/usr/local/ssl/fips-1.0
    *Note: The fips entry will vary based on the specific version that you downloaded to your computer.
    Step 12 – Register the SSH service by entering the following command:
    cygrunsrv –install sshd –path ‘/usr/local/sbin/sshd’ –env ‘PATH=/bin;/sbin’ –env ‘CYGWIN=ntsec tty’ -a -D
    Step 13 – Configure user accounts by first creating a user on the Windows computer. Then, enter the following commands via the bash command line IIRC:
    mkpasswd –l  >/etc/passwd
    mkdir /var/empty
    chown SYSTEM /var/empty
    chmod 755 /var/empty
    groupadd sshd
    useradd -g sshd -c ‘sshd privsep’ -d /var/empty -s /bin/false sshd
    Step 14 – You will now want to make the OpenSSH installation:
    make install
    Step 15 – That’s it. OpenSSL will now be setup on a Windows computer. Please note that some of the commands or directory paths may be slightly different depending on your specific version of Windows, permission sets, version of OpenSSH and OpenSSL that are installed on your computer.

    Free SSH Servers

    There are several free SSH implementations available. Some support only SSH, while others also support SCP and SFTP.

    SSH Server Operating Systems Supported
    OpenSSH AIX, HP-UX, Irix, Linux, NeXT, SCO, SNI/Reliant Unix, Solaris, Digital Unix/Tru64/OSF, Mac OS X, and Cygwin
    Dropbear SSH Server Linux, Mac OS X, FreeBSD, NetBSD, OpenBSD, Solaris, Irix, True64, AIX, HP-UX
    FreeSSH NetBSD, FreeBSD, Linux
    lsh GNU/Linux on Sparc, Intel, PPC and Alpha, FreeBSD, Solaris and IRIX
    SSHD-NT Windows
    OpenSSH for Windows Windows

    Free SSH Clients

    SSH Client Operating Systems Supported
    OpenSSH AIX, HP-UX, Irix, Linux, NeXT, SCO, SNI/Reliant Unix, Solaris, Digital Unix/Tru64/OSF, Mac OS X, and Cygwin
    FreSSH NetBSD, FreeBSD, Linux
    lsh GNU/Linux on Sparc, Intel, PPC and Alpha, FreeBSD, Solaris and IRIX
    OpenSSH for Windows Windows
    PuTTY Win32 and Unix
    MSSH Windows
    WinSCP Windows (SCP and SFTP, no SSH)
    Fugu Macintosh
    MacSSH Macintosh
    Cyberduck Macintosh (SFTP only)
    pssh Palm OS
    TuSSH Palm OS

    Note: I have specifically excluded SSH clients and servers which do not support the SSH v2 protocol.

    Got Something To Say:

    Your email address will not be published. Required fields are marked *

    Privacy
    } 212 queries in 0.362 seconds.