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

Excuse me?

[Anonymous Coward]

You're blaming the failure of the BSD's on the license? Are you on crack? Do you really think the GPLame is what made Linux what it is today? And how can the BSD license possibly scare EVERYONE away? Next time you decide to flame someone, make more intelligent comments.

OpenSSH is slower than (closed) ssh

[embobo]

For interactive sessions OpenSSH may be fine but it has about 1/3 the performance of ClosedSSH for bulk transfers, e.g., (r|s)cp, network backups.

Re:OpenSSH

[Jeff Mahoney]

I wouldn't say that hardly anyone uses it because of licensing issues - I'd say hardly anyone uses it because not many SSH v2 servers have been deployed. In my experience, I haven't deployed any SSH v2 servers because of the lack of clients (which doesn't seem to be as true anymore). It's a catch-22 that comes with any new, fairly incompatible release.

Sorry to pick on just this post, but this is something that has been bothering me about slashdot comments for some time... NOT EVERYONE CARES WHETHER IT IS A ``FREE'' LICENSE OR NOT!

I certainly don't give a rat's ass about the GPL. The GPL is a damn virus. I like Linux, and associated products - but I wish it was all under the truly free BSD license.

-Jeff

Encryption doesn't use more bandwidth

[rips]

You seem to suggest that encrypting the data uses more bandwidth. This isn't the case. Encrypting the data DOES originally require public key authentication of both parties but after that a symetric encryption protocol is used that uses a byte-for-byte mapping (correct me if I'm wrong). It makes sense really. Using block ciphers for a text stream isn't practical as you want text to be sent as soon as you type it. Compression is an added bonus, not a compensation measure.

duh.

[Zurk]

ssh 1.2.27 (patched) or 1.2.28...no other alternative has been that badly *thrashed* by everyone in sight over so many *years*. of course openssh is equally secure but there arent that many people hammering it yet.

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 :)

Re:OpenSSH (SSH 2.x lisencing issues)

[versus]

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

From OpenSSH History and Credits:
Rapidly after the 1.2.12 release, newer versions bore successively more restrictive licenses. Earlier restrictive licenses forbade people from making a Windows or DOS version. Later licenses (read - v2.x) restricted the use of ssh in a commercial environment, instead requiring companies to buy an expensive version from Datafellows.

Re:OpenSSH

[Spud]

> The GPL is a damn virus.

You are a wise man.

Re:OpenSSH

[Patola]

You are the only one which doesn't care.

The GPL is not a damn virus, it is the reason for the success of Linux and the failure of the free BSD's, as was featured on an article on slashdot. It disallows people to go away from the freedom policy.

Patola

Re:SSH

[dexev]

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.

I think this statement needs to be qualified a bit. When I switched from telnet to ssh, I didn't notice a *bandwidth* hit, but the *latency* of the connection went up. This makes sense, really, when you think about all the processing involved.

In any case, the difference was hardly noticeable over a 33.6K modem. So, yeah, you should go with SSH. OpenSSH is based on the original SSH1 source code, with lots o' bug fixes. SSH2 fixes some problems with the SSH1 protocol, but is non-free for commercial use (AFAIR).

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."