The Secure Shell protocol version 2, or SSH2, specifies how a client can connect securely to an SSH server, and then use the resulting secure link to access the server’s resources. Among other things, the client can run programs; transfer files; and forward other TCP/IP connections over the secure link. The SSH2 protocol is a descendant of the SSH v1.x series of protocols. SSH version 2 is standardized at IETF, and the vast majority SSH implementations now support SSH version 2. SSH version 1 is less secure, and is almost no longer being used.
SSH and TLS/SSL are different protocols used for similar purposes. Both protocols are used to authenticate communicating parties and secure data during transport. SSL/TLS tend to use X.509 certificates, is based on ASN.1 encodings, and is most commonly used to as a security layer for HTTP, SMTP, and FTP traffic. The SSH protocol tends to use public keys without a certificate infrastructure, is based on a simpler binary encoding, and tends to be used as a security layer for SFTP and SCP file transfers, terminal shell access, and forwarding of connections for other applications. SSH can be perceived as a less clunky version of TLS. Due to its deliberate independence from X.509 certificates, SSH lends itself well to connections between entities with an existing trust relationship, where TLS does poorly. TLS lends itself better to connections between strangers.
How Secure Is SSH?
The SSH v2 protocol provides the services of server authentication; encryption; data integrity verification; and client authentication. Server authentication is performed using DSA, RSA or ECDSA public key algorithm. For encryption and data integrity verification, a number of algorithms are provided which every SSH product can implement in a modular fashion. Client authentication can be performed using a password, a public key, single sign-on Kerberos, and other methods. The SSH2 protocol specification is publicly available and has been reviewed by several independent implementors. When properly implemented and used, the protocol is believed to be secure against all known cryptographic attacks, passive as well as active.
SSH is a highly flexible protocol, and many different types of services can use it. The protocol’s open architecture allows these services to run at the same time without impeding one another. An SSH client and server can transfer files using the protocols SCP and SFTP, which run on top of an established SSH session. While SCP is the old Unix rcp utility transplanted onto a different transport, SFTP is a flexible remote file access protocol that can be used in advanced ways. SFTP is better standardized and widely supported, so often software that provides an SCP-like interface really uses SFTP instead. Note that SFTP is unrelated to FTP, or to FTP over TLS/SSL. The protocols are independent and very different. A frequently used service is the remote console. This involves allocating a channel within the SSH session, which is then used as transport for a terminal protocol such as vt100 or xterm. The client displays to the user a console window within which the user can execute command line programs on the server. SSH also provides exec requests. An exec request executes a program on the server like a remote console, but without expectation of interactive input. Exec requests are useful for automated remote administration. Another popular SSH function is port forwarding, or TCP/IP connection tunneling. With SSH port forwarding, it is possible to secure a TCP/IP connection established by an independent application that would otherwise be vulnerable to network attacks.
This article summarized from this site: https://www.bitvise.com/ssh2
