SSH vs SSL/Telnet

tyr asks: "I am setting up a masquerade server for our church to access the Internet. I want to be able to remotely administer the server, but other people have concerns about security. I have decided to implement some type of encrypted login. I have heard rumors that SSH compresses the stream to cut down on the bloat caused by encryption. Is this really significant for a text only login? Anyway I just wanted to see discussion on the relative technical merits of each of the options like SSH 1.x, SSH 2.x, OpenSSH, SSL/telnet, and any others you would recommend."

Comments

Re:duh.

[Matthew Weigel]

Yeah, but the ssh 1.5 protocol (the one implemented by all ssh 1.x clients) has, IIRC, some inherent flaws that allow it to be cracked; further, ssh 1.2.28 doesn't demonstrate the same attention to detail that OpenSSH has demonstrated, like (for instance) the recent RSAREF bug that OpenSSH prevented from being tickled.

OpenSSH, while vulnerable when implementing the 1.5 ssh protocol, also supports an incompatible "1.6" ssh protocol that is immune to the known vulnerabilities of the 1.5 protocol; between OpenSSH clients, this protocol can be spoken instead, improving security.

I'm not great at security, but I try to pay attention to those who are :)

SSH

[drix]

You won't notice a difference between SSH and Telnet for text login, even over a modem. This means of course you should go with SSH. It's a lot more featureful than telnet, and has been around so much longer than all the other altnernatives you mentioned that it's bound to be more secure. Also, the distinction between SSH and TelnetSSL must be made - tunneling telnet through SSL encrypts your communications, so your session won't get sniffed, but anyone who has your public key can still access the box just like regular telnet (assuming you're not using a firewall). Obviously, this isn't that much of a leap over plain old telnet - they still get a login: prompt at will, which with enough motivation will can be cracked. OTOH SSH can disable password based logins altogether and use RSA for authentication, where you create a private/public keyblock that you must supply a decryption key to login with. The only way someone will be able to login to your box period is if they get ahold of and crack your private key, which at 1024 bits would take several billion years IIRC, or if they install their own public key on the server, which makes this whole discussion a moot point. So I would use SSH.

--

openssh

[galore]

openssh would seem to be the way to go. the plaintext of most encryption schemes today is compressed, btw. this is not so much to reduce the size of the encrypted traffic (it's usually pretty similar in size), but to help hide patterns in the plaintext. various modes of encryption also help hide these patterns. as other people have said, this compression probably won't increase your throughput that much, though, on a text based ssh session. there is a small delay at the beginning of the session, where the session key is generated and encrypted. if you can live with that second delay, openssh is the way to go.

Re:OpenSSH

[RGRistroph]

You say "Hardly anyone uses ssh 2.x because of it's licencing issues."

What licensing issues ? How does the ssh1.2 license differ from the ssh2 license ?

ssh1 vs. ssh2 vs. openssh vs. telnet over ssl

[dlc]

i'm not a security expert, but i have had ample opportunity to ponder this and related questions. my (admittedly basic) research has led me to these conclusions.

• ssh 1.x - this is the most common ssh implementation, and when people say "ssh" this is most often what they mean. ssh 1.x clients are common, exist for most major platforms, many are very good, and some are even free.
• ssh 2.x - fixes a lot of the bugs in ssh 1.x, adds some nifty new features (like a secure ftp daemon), but i have never seen a functional ssh2 implementation. i beleive it is because of both the more stringent licensing than ssh 1.x and the fact that ssh 1.x is firmly entrenched.
• openssh uses the ssh 1.x protocols, and is completely compatible with ssh 1.x. you should not notice the difference between the two in regular usage.
• telnet over ssl - the actual telnet connection is still sending passwords in plaintext, and the ssl connection has to be made in a separate step.

some random notes:

• ssh (1.x and 2.x) allow for RSA authentication, where a public/provate keypair are used for authentication rather than passwords. clients can be set up to do authentication automatically using this method from specific hosts, based on signatures. this makes ssh a more attractive option for automated, secure transactions such as regular (up|down)ploads and updates. another useful feature of this type of authentication (as opposed to password authentication) is that other users can be given access to the ssh-protected machine, without having to distribute passwords and accounts, from certain controlled environments.
• ssh 1.x and ssh 2.x are incompatible. if you have ssh1 installed when you install ssh2, the ssh2 client will give you the option to fall back to ssh1 if the server you are connecting to is ssh1. without ssh1, however, ssh2 will complain and die. so, it seems that ssh2 only is not the way to go.
• i haven't used openssh, but it seems like a wonderful alternative to ssh. ssh has licensing issues which make it less attractive if you are a commercial entity, but free for non-commercial and educational use (use for a church's web server would probably qualify as non-commercial).

OpenSSH

[The Iconoclast]

one should definately go with OpenSSH, as it is 100% compatible with ssh 1.x. Hardly anyone uses ssh 2.x because of it's licencing issues. There are numerous Free/open clients for the ssh 1.x protocol for many platforms. OpenSSH was based on the last opensource version of ssh 1.x. The OpenBSD team fixed all of its bugs and ran it though a security audit. It is very tight. They are a whole lot quicker about fixing new bugs then the normal ssh guys. The recent buffer overflows and DOS vuenrablities are nonexisitant in OpenSSH.

A wealthy eccentric who marches to the beat of a different drum. But you may call me "Noodle Noggin."