Quick Hits: Transport Protocols (SSL vs. SSH)

The following is a quick post about transport protocols. Whether you are a network engineer or a systems analyst, it is important to understand how data is transferred from system to system. I will be covering SSL and SSH in this post.

SSH stands for Secure Shell and is a protocol that allows people to remotely access a computer through the shell. In general, SSH allows you to utilize the command line to control a different computer or software.  At my current occupation, we use SSH protocols to securely transfer health information and identifiers, such as SSN’s, between different health practices. However, in our case, we actually establish SSH for the client hosted FTP server (SFTP). In general, software and credentials are needed to establish an SSH connection. The client will usually give us a method of authenticating (username/password, or certificate based). It is worth noting that the standard SFTP port is port 22


Another protocol that is used is SSL, which stands for Secure Sockets Layer. SSL essentially allows data to be securely sent between a server and a client (browser)  via encryption. It is worth noting that whenever we see “https” in the address bar it means that SSL is at work. As opposed to SSH/SFTP, HTTP uses port 80 by default. However, HTTPS uses port 443 as its default. In terms of the OSI model,  SSL is represented in the Presentation layer. This is because SSL arguably has a direct impact on the presentation of the data. As mentioned above, SSL is able to encrypt data using a public, private key system utilizing both asymmetric and symmetric encryption methods. I work with SSL directly at my job to securely send information (FTPS) via web services.