Vulnerabilities of Secure Shells

Question

I ssh into my school's engineering computer to submit large programmin projects on a regular basis. Are there any vulnerabilities or worries about using this channel so frequently? What makes a secure shell so secure? What does the computer I am connecting to have access to on my computer?

Answer 1

The remote server has no access to your machine; the SSH session is essentially a tunnel into a shell account on the remote machine.

The reason SSH is secure is that it uses similar mechanisms to TLS, which enforce confidentiality and authenticity. Essentially the SSH server has a public key, which is transmitted to you and stored on your machine. You then trust that key for all future communications. As long as the original transmission of the SSH public key was not tampered with, you can maintain security for communications in the future.

When you connect, your client uses the server's public key to encrypt a randomly generated session key, and sends that encrypted key to the server, which uses the private key (which is secret, and only known by the server) to decrypt the message. At that point, only you and the server know the session key, and can use it to encrypt messages using a symmetric cipher. The session key is also used to enforce authenticity and integrity of the messages, via a message authentication code, which allows both sides of the conversation to ensure that no part of the transmission was altered by a 3rd party.

A simplified version of the handshake is as follows:

1. The server generates a key pair for an asymmetric cipher, e.g. RSA. The private key is kept secret. This key pair is used as the server's identity, and is usually only generated once, then updated infrequently.
2. The server sends the client its public key. This only has to happen once, for the first time the client communicates with the server, or if the server changes its public key. After that, the client keeps a local copy of the public key.
3. The client and server agree on a cipher suite to use, e.g. AES-128 and SHA256. This process is rather complex and somewhat out of the scope of this answer.
4. The client generates a random session key for the chosen symmetric cipher (e.g. a 128-bit key for AES-128) and encrypts it with the server's public key.
5. The client sends the message to the server.
6. The server decrypts the message using the private key, and uses the decrypted session key as the key for the chosen symmetric cipher.
7. Each message is encrypted using the symmetric cipher, and authenticated via a HMAC based on the hash algorithm chosen in the cipher suite agreement. Both sides can now exchange messages safely.

Obviously this glosses over some details, but it's a reasonable representation of what happens.

Answer 2

Polynomial's answer covers the hard part of your question. For the rest:

"What makes a secure shell so secure?"

"Secure Shell" was the alternative to what existed before it. Telnet, FTP, rcp and rsh.

Those protocols all operated in the clear and could be trivially intercepted by anyone who could sniff the traffic. They were also subject to impersonation attacks and man in the middle attacks, where the impersonator or MITM could collect your credentials or watch your session.

"Are there any vulnerabilities or worries about using this channel so frequently?"

There's nothing specifically wrong with using SSH frequently. It's common practice in techncial circles to use SSH for everything. Security risks for SSH are usually tied to users using weak passwords on Internet-facing servers, or admins who fail to keep ssh up to date, don't lockout accounts after too many failed attempts or use rate-limiting to mitigate brute-forcing.

It's best to disable password-based authentication and rely exclusively on public-private key pairs. Key pairs can't realistically be brute-forced.

The use of keypairs and non-centralized trusts makes implementations of SSH more trustworthy than SSL. But it requires a more technical user to understand how to use SSH properly.