SSH Version 1 and 2
Network Security continues to dominate the IT industry and is one of the most important factors to consider when designing and deploying network. Using rules in Firewalls/network devices, designing and configuring the network provides a robust security framework. Another key aspect is to only allow essential protocols and services which protect the integrity and confidentiality of the IT ecosystem. One such secured protocol is SSH. In this article we will learn about SSH, its configuration, versions and related items.
Introduction to SSH
Secure Shell (SSH) is a protocol which provides a feature of secured remote access to network devices. Connection between the client and server is encrypted in both SSH version 1 and 2. Secure Shell (SSH) improves network security by providing a means of establishing secure connection to networking devices for management using Digital Certificates in a Public and Private Key Cryptography. Telnet is used to connect device but the main disadvantage of using Telnet is that it does not encrypt its connections. SSH overcomes this shortcoming.
SSH has two versions –
SSH Version 1
SSH v1 (Secure Shell) provides an encrypted channel to users for logging into remote device. It provides strong host-to-host and user authentication. It also provides secure encrypted communications over the Internet.
SSH Version2
On the contrary, SSH2 is a much more secured, an efficient version of SSH that includes SFTP, which is functionally similar to FTP with addition of SSH2 encryption.
Advantages that SSH2 provides over SSH1 are:
1). Eavesdropping: SSH2 encrypts all the data which protects against eavesdropping, making it unreadable to potential eavesdroppers.
2). DNS and IP Spoofing: SSH2 avoids such attacks by cryptographically authenticating the identity of the server. In session establishment, the SSH client validates the server’s host key against a local list of available keys that are associated with server names and addresses. If the keys mismatch, then an immediate warning is issued.
3). Man in the Middle: SSH2 can protect against man-in-the middle attacks by server-host authentication. Because the attacker does not have the server’s private host key, SSH2 provide stronger authentication for the client. Passwords are vulnerable but public keys and certificates are essentially immune to these types of attacks.
Difference between SSH Version 1 and 2
| 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. | Exactly one session channel per connection. |
| 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. |
| Extensible algorithm/protocol naming scheme allows local extensions while preserving interoperability. | Fixed encoding precludes interoperable additions. |
| User authentication methods: * Public key (DSA, RSA, OpenPGP) * Host based * Password * (Rhosts dropped due to insecurity) | Supports a wider variety: * Public key (RSA only) * Rhosts RSA * 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. |
| Host based authentication is in principle independent of client network address, and so can work with proxying, mobile clients, etc. | Rhosts RSA authentication is effectively tied to the client host address, limiting its usefulness. Note- With rhosts RSA authentication, a user logs in based on the keys and it is user-specific authentication. |
| Periodic replacement of session keys | N/A |
Download the difference table here.
Options of SSH in IOS:
Hostname#ssh ?
-c Select encryption algorithm
-l Log with user name
-m Select HMAC algorithm
-o Specify options
-p Connect to this port
-v Specify SSH Protocol Version
-vrf Specify vrf name
WORD IP address or hostname
Steps to configure SSH:
- Configure the router hostname using command “hostname”.
- Configure the domain name using command “ip domain-name”.
- Generate public and private keys using command “crypto key generate rsa”.
- Create a user in the local database using command “username…secret”.
- Allow only SSH access on VTY lines using command “transport input ssh”.
Related – SSH Version 2 Configuration on Cisco Router
Troubleshooting
Below are the key items which need to be validated as part of SSH troubleshooting –
- Domain name and hostname should be provided.
- Crypto keys should be generated.
- Password on the vty line.
Conclusion
- SSH is a secure method for remote access to router/switch.
- SSH requires a RSA public/private key pair.
- SSH version 2 is more secure than version 1.
- Administrators and implementers need to make sure to use IOS image that supports crypto feature or else SSH will not work which can make the network device vulnerable to attack.
ABOUT THE AUTHOR
I am here to share my knowledge and experience in the field of networking with the goal being – “The more you share, the more you learn.”
I am a biotechnologist by qualification and a Network Enthusiast by interest. I developed interest in networking being in the company of a passionate Network Professional, my husband.
I am a strong believer of the fact that “learning is a constant process of discovering yourself.”
– Rashmi Bhardwaj (Author/Editor)
