Introduction to OPENSSH

           Introduction to  openSSH & SSH (Secure Shell)                                                       

opensSSH?

OpenSSH is a free implementation of the SSH 1 and SSH 2 protocols. It was originally developed as part of the OpenBSD (Berkeley Software Distribution) operating system and is now released as a generic solution for UNIX or Linux® and similar operating systems.

What Does openSSH Package Provides?                                    

Basically openSSH provides three kind of services

Ø  logging to the server(SSH)

Ø   secure file transfer(SFTP)

Ø  Secure Copy (SCP)

Why SSH?

   SSH was designed as a replacement for Telnet and for unsecured remote shell 

           protocols such as the Berkeley rlogin, rsh, and rexec protocols.

             Those protocols send information, notablypasswords, in plaintext, rendering

           them  susceptible to interception and disclosure using packet analysis.

Note:  The encryption used by SSH is intended to provide confidentiality and integrity of data over an unsecured network, such as the Internet.

In UNIX the configuration files for ssh is sshd_config and for older version it's ssh_config. it is basically located under /etc/ssh directory.

What is SSH ?

The Secure Shell (SSH) protocol was developed to get around these limitations.

 The standard TCP port 22  has been assigned for contacting SSH servers:

1. SSH provides for encryption of the entire communication channel, including the login and password credential exchange

2.It can be used with public and private keys to provide automatic authentication for logins.

3.   You can also use SSH as an underlying transport protocol for other services 

How SSH Protocol works?

SSH architecture

IETF RFCs 4251 through 4256 define SSH as the "Secure Shell Protocol for remote login and other secure network services over an insecure network." The shell consists of three main elements.

·         Transport Layer Protocol: This protocol accommodates server authentication, privacy, and integrity with perfect forward privacy. This layer can provide optional compression and is run over a TCP/IP connection but can also be used on top of any other dependable data stream.

It sets up encryption, integrity verification, and (optionally) compression and exposes to the upper layer an API for sending and receiving plain text packets.

·         User Authentication Protocol: This protocol authenticates the client to the server and runs over the transport layer. Common authentication methods include password, public key, keyboard-interactive, GSSAPI, SecureID, and PAM.

·         Connection Protocol: This protocol multiplexes the encrypted tunnel to numerous logical channels, running  over the User Authentication Protocol. A single SSH connection can host multiple channels concurrently, each transferring data in both directions

What are the different SSH Protocol Versions?

When  first time SSH Protocol Version 1  was introduced , Many vulnerabilities were reported and for fixing the  vulnerabilities in between many versions were introduced like 1.3,1.5 etc 

Currently  we are having two major  SSH Protocol Versions.

1.       SSH Protocol Version 1

2.       SSH Protocol Version 2

What is SSH Protocol Version 1 ?

SSH version 1 makes use of several patented encryption algorithms (however, some of these patents have expired) and is vulnerable to a well known security exploit that allows an attacker to insert data into the communication stream.

What is SSH Protocol Version 2 ?

SSH protocol version 2 is the default protocol used these days.

 This is due to some major advancements in version 2 compared to version 1.

 The workflow of the ssh login is almost same as that of version 1, however there are some major changes done in the protocol level.

Some of these changes include improved encryption standards, Public key certification, much better message authentication codes, reassignment of session key etc.

Various types of encryption are available, ranging from 512-bit encryption to as high as 32768 bits, inclusive of ciphers, like Blowfish, Triple DES, CAST-128, Advanced Encryption Scheme (AES), and ARCFOUR.

Why is SSH Protocol Version 1 not encouraged?

                                                                After using the SSH Version 1 ,it was noticed that , hackers are able to do  unauthorized insertion of content into an encrypted SSH stream due to insufficient data integrity protection from CRC-32 used in this version of the protocol . Later the developers of SSH released fixes but the vulnerability detection continued  due to the flaw in the design flaw of this protocol .

Differences between SSH1 and SSH2 protocols

SSH protocol, version 2	SSH protocol, version 1
Separate transport, authentication, and connection protocols	One monolithic protocol
Strong cryptographic integrity check	Weak CRC-32 integrity check; admits an insertion attack in conjunction with some bulk ciphers.
Supports password changing	N/A
Any number of session channels per connection (including none)	Exactly one session channel per connection (requires issuing a remote command even when you don't want one)
Full negotiation of modular cryptographic and compression algorithms, including bulk encryption, MAC, and public-key	Negotiates only the bulk cipher; all others are fixed
Encryption, MAC, and compression are negotiated separately for each direction, with independent keys	The same algorithms and keys are used in both directions (although RC4 uses separate keys, since the algorithm's design demands that keys not be reused)
Extensible algorithm/protocol naming scheme allows local extensions while preserving interoperability	Fixed encoding precludes interoperable additions
User authentication methods: publickey (DSA, RSA*, OpenPGP) hostbased password (Rhosts dropped due to insecurity)	Supports a wider variety: public-key (RSA only) RhostsRSA password Rhosts (rsh-style) TIS Kerberos
Use of Diffie-Hellman key agreement removes the need for a server key	Server key used for forward secrecy on the session key
Supports public-key certificates	N/A
User authentication exchange is more flexible, and allows requiring multiple forms of authentication for access.	Allows for exactly one form of authentication per session.
hostbased authentication is in principle independent of client network address, and so can work with proxying, mobile clients, etc. (though this is not currently implemented).	RhostsRSA authentication is effectively tied to the client host address, limiting its usefulness.
periodic replacement of session keys	N/A

How to know which  SSH protocol version is used for connection ?

[root@saks20161 ~]# telnet 192.168.0.115 22 Trying 192.168.0.115... Connected to 192.168.0.105 (192.168.0.115). Escape character is '^]'. SSH-2.0-OpenSSH_4.3 >>>>>>>  this will show the protocol used

 SSH security and configuration best practices

SSH Security hardening is also required to minimize the security attacks . openSSH provides lot of flexibility where we can enable/disable the various features  using the ssh configuration file.

Below are the  list of processes and configurations that you can use to tighten and enhance SSH security with regard to remote host access:

      Restrict the root account to console access only:

# vi /etc/ssh/sshd_config

PermitRootLogin no

Create private-public key pairs using a strong passphrase and password protection for the private key 

a:) never generate a password-less key pair or a password-less passphrase key-less login

b:) Use a higher bit rate for the encryption for more security

ssh-keygen -t rsa -b 4096

Restrict SSH access by controlling user access

We can restrict the user access  through ssh as per our need in ssh configuration files . Below mentioned 4 funtions  can be used for doing this.

·         AllowUsers

·         AllowGroups

·         DenyUsers

·         DenyGroups

·         # vi /etc/ssh/sshd_config

·         AllowUsers fsmythe bnice swilson

Only use SSH Protocol 2

·         # vi /etc/ssh/sshd_config

            Protocol 2

Don't allow Idle sessions, and configure the Idle Log Out Timeout interval:

·         # vi /etc/ssh/sshd_config

·         ClientAliveInterval 600                           # (Set to 600 seconds = 10 minutes)

Disable host-based authentication:

·         # vi /etc/ssh/sshd_config

           HostbasedAuthentication no

Disable users' .rhosts files

·         # vi /etc/ssh/sshd_config

            IgnoreRhosts yes

Confine SFTP users to their own home directories by using Chroot SSHD

·         # vi /etc/ssh/sshd_config

·         ChrootDirectory /data01/home/%u

Disable empty passwords:

·         # vi /etc/ssh/sshd_config

           PermitEmptyPasswords no

Configure an increase in SSH logging verbosity:

·         # vi /etc/ssh/sshd_config

            LogLevel DEBUG

IMP: after doing any of the above changes in the ssh configuration files ,you need to stop and start the ssh services.  This changes will impact only the new connections . The existing SSH Connections will be using the earlier configuration .

******************************************************************************