SBN

Network Traffic Analysis for IR: SSH Protocol with Wireshark

Introduction to the SSH protocol

The Secure Shell (SSH) is designed to allow confidential and authenticated remote access to a computer. Like the Telnet protocol, it enables a user to remotely access a command shell on a machine, run commands and access the results. However, unlike Telnet, SSH traffic is fully encrypted, making it the correct choice for remotely interacting with a machine.

SSH is assigned port 22 in both TCP and UDP. However, the protocol primarily runs over TCP due to its need for reliable communications, proper packet ordering and so on. A number of different SSH implementations exist, but the primary ones are OpenSSH (on *nix systems) and PuTTY and WinSCP on Windows Systems.

The SSH protocol in Wireshark

The main difference between SSH and Telnet is that SSH provides a fully encrypted and authenticated session. The way that SSH accomplishes this is very similar to SSL/TLS, which is used for encryption of web traffic (HTTPS) and other protocols without built-in encryption.

The screenshot above shows a sample SSH session in Wireshark. As shown, packets associated with the session are filtered using the built-in ssh filter.

To accomplish its goals, SSH uses two different types of cryptography. Symmetric cryptography, like the Advanced Encryption Standard (AES), is faster and more efficient for bulk encryption, but it requires a shared secret key. Asymmetric encryption, on the other hand, doesn’t require a shared secret key but is less efficient.

SSH uses asymmetric cryptography to establish a shared secret key and then symmetric cryptography for bulk encryption with that key. The use of asymmetric cryptography is shown in the screenshot above as Diffie-Hellman is a protocol for secure key generation.

Diving into packet 21, as shown above, we see the use of symmetric cryptography as well. This SSH session will be using (Read more...)

*** This is a Security Bloggers Network syndicated blog from Infosec Resources authored by Howard Poston. Read the original post at: http://feedproxy.google.com/~r/infosecResources/~3/3t8H7FzE-pE/