What is the Full Form of SSH

SSH: Secure Shell

SSH stands for Secure Shell. It is also known as Secure Socket Shell. A cryptographic network protocol called Secure Shell (SSH) is used to safely operate network services across insecure networks. Client server architecture is the foundation of SSH applications, which link an SSH client instance with an SSH server.

As a successor for Telnet and unsafe remote Unix shell protocols like the Berkeley Remote Shell (rsh) and its associated rlogin and rexec protocols, SSH was created for Unix-like operating systems that employ unsecure, plaintext authentication token communication.

Definition

We may apply SSH in several different ways. The simplest implementation encrypts data using automatically generated public-private key pairs at both ends of a communication channel and a network connection. After that, it authenticates the user using a password. When a user manually generates a public-private key pair, authentication is virtually completed when the key pair is established, allowing a session to be launched instantly without a password prompt.

In this case, the owner keeps the corresponding private key secret, and the public key is installed on all machines that must grant access to the owner. Although the private key serves as the foundation for authentication, the key is never sent over the network when performing authentication. SSH confirms that the public key's provider also holds the corresponding private key.

Connecting the unknown public key with a known private key in all versions of SSH is crucial before accepting them as legitimate public keys with IDs. Accepting a public key from an attacker without validating it will accept an untrusted attacker as a legitimate user.

Creation

Tatu Ylönen, a computer scientist from Finland, created SSH for the first time in 1995. The protocol suite's further development took place in many developer groups, leading to various implementation iterations. There are implementations available for all popular operating systems, including embedded systems. OpenSSH, which the creators of OpenBSD made available as open-source software in 1999, is the most frequently used software stack.

Management of OpenSSH Keys for Authentication

The approved public key list is commonly kept on Unix-like systems in the file ~/.ssh/authorized keys in the user's home directory, which has remote login privileges. SSH only respects this file if it cannot be modified by anybody other than the owner and root. The password is no longer necessary when both the remote end's public key and the local end's matching private key are present. But we may use a passphrase to lock the private key for much more protection. We may also search the secret code in common locations, and we can use a command line option to provide its complete path (option -i for ssh).

SSH further provides automated key generation-encrypted password-based authentication. The attacker in this scenario may impersonate the trustworthy server side, request the password, and gain it (man-in-the-middle attack). On the server side, we can turn off password authentication.

Use

SSH uses the client-server paradigm. Typically, SSH is used for logging. It can also tunnel TCP ports, forward X11 connections, and execute commands on a remote system. Typically, connections to an SSH daemon allowing remote connections are made using an SSH client application. Both are often found on most contemporary operating systems, such as macOS, Linux distributions, OpenBSD, FreeBSD, NetBSD, Solaris, and OpenVMS. Some versions are proprietary, freeware, and open source with varying degrees of complexity and comprehensiveness (such as PuTTY and the version of OpenSSH included with Cygwin and OpenSSH). Notably, SSH is not included by default in Windows versions until Windows 10 version 1709.

Similar file management (synchronization, copy, and remote deletion) functionality is offered by the free and open-source windows application WinSCP, which uses PuTTY as a back-end. Without needing to be installed on the client computer, WinSCP and PuTTY are available packed to operate directly off a USB drive. Enabling a feature in the settings app is often required to set up an SSH server in Windows.

To handle connection concerns and prevent the security risks of directly exposing a cloud-based virtual machine to the Internet, SSH is crucial in cloud computing. A secure connection over the Internet can be made possible through an SSH tunnel virtual computer via a firewall. For this protocol, the IANA has designated TCP port 22, UDP port 22, and SCTP port 22.

As early as 2001, IANA classified the default TCP port 22 for SSH servers as one of the well-known ports. The connection-oriented transport layer protocol SCTP may be used to run SSH instead of TCP.

Historical Progression

Iteration 1

A password-sniffing assault on the network of his institution inspired Tatu Ylönen, a researcher at the Helsinki University of Technology in Finland created the initial iteration of the protocol (today known as SSH-1) in 1995.

SSH was designed to take the role of prior protocols, including rlogin, TELNET, FTP, and rsh, which lacked robust authentication and secrecy guarantees. Ylönen made his application available as freeware. In July 1995, the device rapidly became well-liked. By the end of 1995, there were 20,000 SSH users spread over 50 different nations.

To promote and advance SSH, Ylönen established SSH Communications Security in December 1995. Various free software components, including GNU libgmp, were utilized in the SSH program's first release, but later iterations provided by SSH Communications Security grew into increasingly proprietary software. According to estimates, there were 2 million users by the year 2000.

Iteration 2

The Internet Engineering Task Force (IETF) designated the working group in charge of creating SSH protocol version 2 as "Secsh" in its official documentation.

SSH-2, an improved protocol iteration, became a standard in 2006. SSH-1 is not compatible with this version. SSH-2 offers functionality and security upgrades over SSH-1. For instance, Diffie-Hellman key exchange and robust integrity verification via message authentication codes provide higher security. The ability to operate an unlimited number of shell sessions over a single SSH connection is one of SSH-2's new capabilities. Because SSH-2 is more advanced and widely used than SSH-1, certain implementations, such as libssh (v0.8.0+), Lsh, and Dropbear, only support SSH-2.

Iteration 1.99

RFC 4253 required that an SSH server supporting 2.0, as well as earlier versions, should indicate its protocol version as 1.99 in January 2006, well after version 2.1 was developed. This version number is used to indicate backward compatibility rather than to represent a previous software revision.

OSSH and OpenSSH

Since the last version of the original SSH program, version 1.2.12, was distributed under an open-source license in 1999, developers have been working on a free software version. This was used as the foundation for Björn Grönvall's OSSH program. Soon after, the OpenBSD team cloned Grönvall's work to produce OpenSSH, which was included in OpenBSD Release 2.6. They created a "portability" branch from this version to transfer OpenSSH to different operating systems.

The most widely used SSH implementation as of 2005 was OpenSSH, the default version in many operating system distributions. After removing SSH-1 support from the codebase in the OpenSSH 7.6 release, OpenSSH is still being updated and supports the SSH-2 protocol. Meanwhile, OSSH is no longer relevant.

Uses

The user "josh" "SSHed" from the local computer "foo fighter" to the distant machine "tengwar" to run xeyes as an example of tunneling an X11 program through SSH. People utilize Windows SSH client PuTTY to access OpenWrt.

SSH is a protocol that works with many systems, including Microsoft Windows and most Unix variations (Linux, BSDs, including Apple's macOS, and Solaris). The following apps can need capabilities that are exclusive to or compatible with particular SSH clients or servers. For instance, it is currently only feasible to use the OpenSSH server and client implementation of the SSH protocol to construct a VPN.

• To access a shell on a distant host (replacing Telnet and rlogin)
• For carrying out a solitary command on a distant host (replacing rsh)
• For configuring a distant server's automated (password-less) login (for example, using OpenSSH)
• As a fully functional encrypted VPN, keep in mind that only the OpenSSH client and server support this capability.
• For transmitting X from a distant host (possible through multiple intermediate hosts)
• For using SSH clients that support the SOCKS protocol to browse the Internet over an encrypted proxy connection.
• For safely mounting a remote server's directory as a filesystem on a local machine employing SSHFS.
• Through one or more of the technologies mentioned above for automatic remote server monitoring and administration.
• For SSH-compatible mobile or embedded device development.
• To protect file-transfer mechanisms.

Transfer Methods for Files

Several file transfer systems employ Secure Shell protocols such as

• Over SSH, Secure Copy (SCP) is developed from the RCP protocol.
• rsync which is supposed to be more effective than SCP is often operated through an SSH connection.
• An alternative to FTP that is safe is SSH File Transfer Protocol (SFTP) (not to be confused with FTP over SSH or FTPS)
• FISH, or files transferred over shell protocol, was introduced in 1998 and developed from SSH over Unix shell instructions.
• Aspera, also known as Fast and Secure Protocol (FASP), employs SSH for command and for data transport, UDP ports.

Architecture

Three distinct components make up the layered architecture of the SSH protocol:

• The Transmission Control Protocol (TCP) of TCP/IP is commonly used by the transport layer (RFC 4253), with port number 22 set aside as a server listening port. This layer implements encryption, compression, integrity checking, initial key exchange, and server authentication. Although each implementation may allow for more, it exposes to the higher layer an interface for transmitting and receiving plaintext packets of up to 32,768 bytes each. Usually, after 1 GB of data has been transported or after an hour has passed, whichever comes first, the transport layer arranges for key re-exchange.
  
• Client authentication is handled via the user authentication layer (RFC 4252), which also offers several authentication techniques. Client-driven authentication means that the SSH client, not the server, may ask the user for a password. Only the client's requests for authentication receive a response from the server. The following user-authentication techniques are often used:
  1. Password, a simple password authentication technique that includes the ability to modify the password. Not all software uses this technique.
  2. Usually supporting at least DSA, ECDSA, or RSA keypairs, the public key is a technique for public-key-based authentication. Other implementations additionally accept X.509 certificates.
  3. Keyboard-interactive (RFC 4256) is a flexible technique in which the server provides one or more prompts for information entry, the client displays them, and then sends back answers that the client has typed in. Used by some OpenSSH settings to effectively offer password authentication when PAM is the underlying host-authentication provider, which might occasionally prevent logging in with a client that only supports the simple password authentication technique.
  4. Single sign-on functionality for SSH sessions is provided via GSSAPI authentication techniques, which offer an extendable system to handle SSH authentication using external mechanisms like Kerberos 5 or NTLM. Although OpenSSH has a functional GSSAPI implementation, commercial SSH implementations often integrate these techniques for use in companies.
  5. The idea of channels that define the SSH services offered is defined by the connection layer (RFC 4254). We can multiplex multiple SSH connections from a single one. Both transmit data in both directions. Channel requests transmit out-of-band data particular to a given channel, such as a server-side process's exit code or a terminal window's size change. Additionally, using the receive window size, each channel controls its flow. The SSH client makes a global request to forward a server-side port. Channel types that are common include:
     • Shell for SFTP, exec, and terminal shells (including SCP transfers)
     • Direct-TCPIP for forwarded connections from the client to the server.
     • Server-to-client forwarded connections using forwarded-tcpip
     • To confirm the host's legitimacy, the SSHFP DNS record (RFC 4255) offers the public host key fingerprints.

Due to its open design, we may use SSH for a wide range of tasks in addition to securing shells, giving it great versatility.

Vulnerabilities

SSH-1

Due to inadequate data integrity protection provided by CRC-32 in this protocol version, a vulnerability in SSH 1.5 was identified in 1998 that permitted the unauthorized insertion of material into an encrypted SSH stream. In most implementations, they added a patch known as SSH Compensation Attack Detector. Several of these revised implementations included a new integer overflow flaw, enabling attackers to run arbitrary code with root or the SSH daemon's capabilities.

A flaw that enables attackers to change the last block of an IDEA-encrypted session was found in January 2001. Another flaw that enabled a rogue server to pass a client login to another server was found in the same month.

Due to its inherent vulnerabilities, SSH-1 is generally regarded as being out-of-date and should be avoided by explicitly removing SSH-1 fallback. Most current servers and clients support SSH-2.

Plaintext Recovery for CBC

A theoretical vulnerability that allowed the retrieval of up to 32 bits of plaintext from a block of ciphertext encrypted using the time's standard encryption method, CBC, was discovered in all versions of SSH in November 2008. The simplest fix is to switch to CTR, counter mode, instead of CBC mode, which makes SSH immune to the attack.

NSA Suspected of Decryption

Edward Snowden's release of sensitive documents to Der Spiegel on December 28, 2014, implies the National Security Agency will be able to potentially decode certain SSH communications.