G++

[Sidoh]

It could be telnet .  Makes me sentimental for a time that has long passed.

Haha.  I don't think the Unix machines here have telnet running, but SSH is open to the outside world on all of the lab machines.  They all have unique ip's.

[AntiVirus]

I mean telnet.

[iago]

Haha, all our University servers ran SSH and Telnet, but you wouldn't catch me dead with Telnet.  It's just a dumb thing to use, you're asking to get your account stolen. 

[Sidoh]

I mean telnet.

[deadly7]

The many faces of sidoh.
Sad, confused, and teary-eyed.
In other words: emo and stupid.
Hehe.

[AntiVirus]

Yeah, I am aware that Telnetting isn't safe, but it's what the school (as in our class) is making me do.  I suppose if anythign happens, it's their fault.  I'm not too worried if someone gets my password for my account.  I only use that password for my school E-mail account, so no harm if they do.

[iago]

They get your password -> they log onto your account -> they hack/spam/etc -> you get in shit, expelled, etc. 

And sniffing telnet passwords is something that's reasonably common, I've heard stories about it more than once. 

Telnet should be banned, and everybody who uses it should be shot.  And, while we're at it, FTP.

[Sidoh]

Haha, FTP is terrible too.  It's too damn widespread to kill, though.  I really need to start using SFTP...

[Joe]

Plus I remember iago saying something about SFTP being faster than FTP because it's encryption algorithm comes out smaller than it's input? I don't see how that's possible but eh.

[Sidoh]

Plus I remember iago saying something about SFTP being faster than FTP because it's encryption algorithm comes out smaller than it's input? I don't see how that's possible but eh.

Maybe during login, but it wouldn't be faster for the rest of the datastream to require less bandwidth.

[iago]

SFTP supports in-line compression:

     -C      Compression enable.  Passes the -C flag to ssh(1) to enable com­
             pression.

So it can be faster, depending on the data. 

[Sidoh]

Faster transmision, slower parsing and storing.  Seems like a moot tradeoff to me, though I can see where it would be advantageous.

[nslay]

Well, ssh is only safer once you have established the authenticity of the RSA/DSA keys of the host.
On your first connect, a man-in-middle attack can still occurr.  Scary huh?
That's why certificate authorities exist, to prevent any possible situation where man-in-middle attacks can happen.

Here's how SSH works, or something along these lines:
Client connects to Server
1) Server sends DSA or RSA public key
2) Client generates a private DSA or RSA key by using some of the parameters from the server's public key
3) Client dups a DH key from the newly generated private key and computes a secret key K with the DH key and server's pub_key
4) Client takes a cryptographic hash of the secret key K and signs with the private DSA or RSA key
5) Client sends the signature and public DSA or RSA key
6) Server, like 3, computes a secret key K
7) Server verifies the signature against client's DSA or RSA public key
Server, like 4, signs K and sends signature
9) Client, like 6, verifies the signature

On a first connect, man-in-middle can happen because you don't have the server's public DSA or RSA key to begin with.  Therefore, the man in the middle can forge new keys and send his public key in place of the server's and basically conduct all 8 steps thereafter.

[iago]

Faster transmision, slower parsing and storing.  Seems like a moot tradeoff to me, though I can see where it would be advantageous.

True, but when transferring a file over the Internet, the connection speed is almost always the bottleneck, unless you're going over a LAN.  Even then, I suspect that network speed is probably the bottleneck. 

Do you just like arguing with everything you read lately?  You seem more argumentative than usual

Well, ssh is only safer once you have established the authenticity of the RSA/DSA keys of the host.
On your first connect, a man-in-middle attack can still occurr.  Scary huh?

Not really. 

With something like a school server, you're probably connecting to it every day.  Statistically, the odds of somebody doing a MitM the very first time you connect is actually pretty low, the same way the odds of somebody sniffing your telnet/FTP/pop3 password is pretty low.  However, when you do it every day, or several times a day, the odds of being attacked steadily increase.  It's the same way as on Battle.net -- the weakest point in the War3 authentication is creating your account, since you have to send some sensitive data over the wire, but that's so rare compared to logins that the risk is fairly low. 

Yes, having a trusted CA would mitigate the risk, but CAs charge money for their services.  I don't think every University server, every home Linux user, everybody who wants to use SSH for remote access wants to pay for a CA to store their key. 

We have to remember that there is no perfect solution to security.  Security is about weighing the risks against the difficulties, and implementing controls that mitigate the risks to the point where the risks are low, but the usability is high.  If you add too much security, your network becomes unusable and users will circumvent your controls, and if you add too little security you're at risk.  A good example of that is enforcing stupid password policies, so people write them down and stick them to the monitor. 

SSH is sort of the same way.  If you start making life difficult without signing up for a CA (the same way that SSL does), then you're going to end up finding more people using telnet because of the headache caused by SSH.

[Sidoh]

Well, ssh is only safer once you have established the authenticity of the RSA/DSA keys of the host.
On your first connect, a man-in-middle attack can still occurr.  Scary huh?
That's why certificate authorities exist, to prevent any possible situation where man-in-middle attacks can happen.

I know.  It is still invariably more secure than a plaintext protocol.

On a first connect, man-in-middle can happen because you don't have the server's public DSA or RSA key to begin with.  Therefore, the man in the middle can forge new keys and send his public key in place of the server's and basically conduct all 8 steps thereafter.

I know.

True, but when transferring a file over the Internet, the connection speed is almost always the bottleneck, unless you're going over a LAN.  Even then, I suspect that network speed is probably the bottleneck. 

Do you just like arguing with everything you read lately?  You seem more argumentative than usual

Haha, yeah.  I know that.  That's why I said "though I can see where it would be advantageous."  I didn't bother typing out the explanation.

However, if you have a server managing a few hundred clients and you have, say, 50 of them connected constantly sending data, it's going to be a very busy CPU.  How many cycles are spent decrypting packet data?  I know it depends on the algorithm used, but how about the default one used for SFTP?  It utilizes SSL, right?  So RSA, I think.

SSH is sort of the same way.  If you start making life difficult without signing up for a CA (the same way that SSL does), then you're going to end up finding more people using telnet because of the headache caused by SSH.

Haha, that's an excellent point.  I'm not much of a paranoid person, but I don't think I could live with using telnet every day in the place of ssh.  I recognize the potential risks involved with using SSH, but like iago said, the odds of that are way lower than using telnet every day.