Why Aren't We Using SSH For Everything? 203
An anonymous reader writes: A post at Medium asks why, in this age of surveillance and privacy-related bogeymen, we aren't making greater use of SSH for our secure computing needs?
"SSH is one of the most accessible secure protocols ever, second only to HTTPS of course. Let's see what we have so far: Binary protocol, mandatory encryption, key pinning, multiplexing, compression (yes, it does that too). Aren't these the key features for why we invented HTTP/2?
Admittedly, SSH is missing some pieces. It's lacking a notion of virtual hosts, or being able to serve different endpoints on different hostnames from a single IP address. On the other hand, SSH does have several cool features over HTTP/2 though, like built-in client authentication which removes the need for registration and remembering extra passwords."
"SSH is one of the most accessible secure protocols ever, second only to HTTPS of course. Let's see what we have so far: Binary protocol, mandatory encryption, key pinning, multiplexing, compression (yes, it does that too). Aren't these the key features for why we invented HTTP/2?
Admittedly, SSH is missing some pieces. It's lacking a notion of virtual hosts, or being able to serve different endpoints on different hostnames from a single IP address. On the other hand, SSH does have several cool features over HTTP/2 though, like built-in client authentication which removes the need for registration and remembering extra passwords."
Because no. (Score:5, Informative)
>Admittedly, SSH is missing some pieces
Should read, "Admittedly, SSH is missing some crucial features, that make its use in this context impossible."
Re:Because no. (Score:5, Insightful)
The lack of features may be a feature.
The more features something has, the more likely an oversight in the design or implementation will prove to be a liability.
Re: (Score:2)
The more features something has, the more likely an oversight in the design or implementation will prove to be a liability.
The more features something lacks, the more likely a work-around hack will prove to be a liability.
Re: (Score:2)
The more features something has, the more likely an oversight in the design or implementation will prove to be a liability.
The more features something lacks, the more likely a work-around hack will prove to be a liability.
Just use the right tool for the job and you don't have that problem (in this case).
Re: (Score:2)
Re:BINGO (Score:5, Insightful)
I think you just answered the poster's question, by the way. SSH is quite good for what it does, but what it does doesn't cover every conceivable need.
A better question might be,"Why aren't we using SSH *in more situations where it might be useful*?"
BINGO (Score:2, Informative)
Or we could just finally implement DNSSEC, and put the keys (Or, rather, the fingerprint) in the DNS.
Someone is about to point out that DNS can be subverted and hijacked, even with DNSSEC.
Well, considering that SSL keys are commonly *emailed* to people, if anyone has subverted your DNS, or anyone's DNS, you're screwed anyway. At least with DNSSEC, it requires hacking into the actual registrar account and changing records there, instead of just tricking the least-secure SSL-issuer's DNS. (And registrars alre
Medium.com (Score:2, Flamebait)
Re: (Score:3)
What's wrong with Medium? It's essentially just a blogging platform, right?
Oh, wait, my bad! (Score:3)
Re: (Score:3)
Sounds like a perfect description of medium.com to me...
Re: (Score:2, Interesting)
But alas, it is unfortunately the 99% that give the other 1% a bad name.
I kee
Re: (Score:2)
Medium doesn't have ads, so I'm not sure where you're going with that ...
If you havent been to Medium, you would not know that.
I believe he was contrasting this story against stories with poor summaries with a link to some random url you havent been to before.
Perhaps read slower ?
Re:Medium.com (Score:5, Funny)
What's wrong with Medium? It's essentially just a blogging platform, right?
So is Slashdot, if you're Bennett Haselton.
Re:Actually... (Score:5, Funny)
Why aren't we using SSH to monitor the computer's microphone?
We ARE using SSH to monitor your microphone.
Sincerely,
The [3 characters redacted]
Re: (Score:2)
Given that they easily cracked SSH why use it for much of anything. Properly we'd want/need something stronger. And you can't really exchange keys over the internet in a really safe way. Though, I'm hugely in favor of replacing general public key encryption schemes for those password schemes to access websites. Just encrypt my account with the key on file, if I can read what my email is, I must be me.
I do (Score:5, Funny)
I use SSH for everything. I use it between my cell phone and the wall charger. I use it between my thermostat and my furnace. Probably most importantly, I use it between my my remote control and TV. Never can be too careful these days.
Re:I do (Score:5, Funny)
Re: (Score:2, Funny)
That's nothing - I use SSH 2.0!
2.0? you lamer...
Us superleet types are on our own supersekret version...6.9apl3...totally rewritten in APL..It does indeed do everything (we took our inspiration from systemd), it achieved a degree of semi-sentience sometime last Tuesday, hell it now even feeds the cat..
Re: (Score:2)
Re:I do (Score:5, Funny)
Re: (Score:3)
I use it between my my remote control and TV. Never can be too careful these days.
By echoing commands over ssh, I have my Raspberry Pi control my TV (HDMI CEC), you insensitive clod!
Re: (Score:2)
Don't forget to airgap your TV and only use remote controls that you built yourself from open-source blueprints. Everybody knows the remote manufacturers secretly capture your button presses.
Re: (Score:2)
I'm glad I'm not the only one doing this. I also do those things you mention but now I've upgraded to my new digital flush SSH enabled toilet and toilet paper dispenser. No longer do I worry about my shit being seen unencrypted.
Re: (Score:2)
I use SSH for everything. I use it between my cell phone and the wall charger. I use it between my thermostat and my furnace. Probably most importantly, I use it between my my remote control and TV. Never can be too careful these days.
Don't look now, but the Internet of Things is right behind you
Then you'll be +5 insightful instead of +5 funny.
Because it's not safe either (Score:5, Interesting)
Recent Snowden documents shed doubt on whether the NSA isn't actually able to crack ssh, too. http://www.spiegel.de/international/germany/a-1010361.html
Re:Because it's not safe either (Score:5, Interesting)
More likely the NSA can use some misconfigurations and crack some (really old) defective clients or servers that are still on protocol v1 or the like. OpenSSH should be pretty secure, but some commercial implementations really suck, and not only with regards to security.
Re: (Score:3)
OpenSSH should be pretty secure
And that's the part that worries me.
Re: (Score:2)
From the documents I saw, they're cracking passwords and pre-shared keys in SSH and IPSec not keyed connections.
Re:Because it's not safe either (Score:5, Interesting)
So they are brute forcing weak SSH passwords. Not impressive, anybody can do that and there is even a bot-net that does it, look up "low-intensity zombies". As to pre-shared keys, there is a known vulnerability of embedded devices that can make their keys vulnerable if they are generated in a low-entropy situation. That has been fixed AFAIK and does not affect proper computers.
As to IPsec: First it is known that the IPsec standard was sabotaged by the NSA by making it overly complicated and complex, doubtless in order to make implementation and configuration mistakes more likely. Second, I have no idea what "non keyed" means for IPsec. Maybe you mean PSK? That can again be attacked if keys are badly chosen. No surprise.
Really, the NSA will of course to what ordinary hackers can also do, but use sound practices and they will need to to an expensive and high-risk targeted attack and even that may fail. The goal here is not to make it impossible for them to get in, the goal is to make it far to expensive in most cases, to they cannot do dragnet-surveillance. One of the hugely dangerous things they are doing is that they collect data on everybody. If somebody becomes, say, a president in some place and they do not like that person, they can go through their archives and sabotage democracy with what they find. It may even be enough that people think they can do this. That makes them a clear and present danger to democracy, freedom, the rule of law, etc. Or in short: Terrorism is peanuts in comparison with the huge threat these people represent.
Re: (Score:2)
Why did you even reply to my post?
I'm not sure who you think you're explaining all that to but it wasn't me.
Re: (Score:2)
Don't flatter yourself.
Re:Because it's not safe either (Score:5, Informative)
Despite the similarity of the names, OpenSSH and OpenSSL are maintained by entirely different teams. Of note is that the organization which maintains OpenSSH recently forked OpenSSL into LibreSSL [slashdot.org] which, once it stabilizes, is expected to behave more safely.
Re: (Score:3)
In addition, the OpenSSH guys are really, REALLY paranoid. They come from the OpenBSD team.
Re: (Score:3)
The track-record for OpenSSH shows it. This is one excellent piece of security software. Must remember to donate this year to them again. I don't use OpenBSD, but OpenSSH alone makes it worth giving them something, for the countless hours of work and worry they have saved me.
Re: (Score:2)
Your expertise extends to all of comparing names syntactically? That is impressive! And not in a good way.
Re: (Score:2)
Considering OpenSSH was vulnerable to heartbleed because it uses OpenSSL, the name is not the only thing they have in common.
Re: (Score:2)
You claim OpenSSH was vulnerable to heartbleed? How would that work?
OpenSSH uses OpenSSL crypto, but _not_ OpenSSL SSL/TLS. Why would it? The SSH protocol is entirely different from SSL/TLS. Hence OpenSSH was never even close to be vulnerable to heartbleed. But I guess you made your claim without knowing the first thing about OpenSSL or OpenSSH.
Really, some actual clue is required to participate in this discussion, pattern matching with names does not cut it at all! Otherwise complete nonsensical claims li
Re:Because it's not safe either (Score:4, Interesting)
The article suggests heavily that a properly configured SSH client and server with secured cert chain is likely safe from prying. The problem with SSH, as with all things, is the use of older distros that may not be updated and not building a proper CA to sign certificates.
Re: (Score:2)
This is the first I've heard of using a Certificate Authority in an SSH context. So I had to look this up. Appears that recent versions of OpenSSH (5.4) have added support for signing ssh keys. Interesting. I doubt many enterprises have deployed OpenSSH new enough to support this sort of thing. RHEL 6 certainly doesn't. RHEL7 should. Seems like a nice security addition. Instead of checking fingerprints (which no one ever does), we can check the signing of the cert to make sure we recognize that. I c
Re:Because it's not safe either (Score:5, Interesting)
If anyone else hadn't heard about using a CA with ssh, as I hadn't, they might find this short tutorial interesting:
https://www.digitalocean.com/c... [digitalocean.com]
Wish this was available back in my uni days when I managed many dozens of Linux workstations. Managing keys was always a pain.
Re: (Score:2)
And you have some evidence of this, right?
Re:Because it's not safe either (Score:5, Insightful)
SSH actually does handle some of those limitations (Score:2, Informative)
SSH can be used for virtual hosting environments just fine with things like force-command chrooting automatically when a user logs in based on username or pubkey. The protocol is not hostname aware, so it cannot handle "different hostnames from a single IP", you have to have a different user account name in order to do similar tricks. I do not think that is a limitation though, since you are talking to the underlying system, not to a content serving system like a web server.
SSL, SSH, S/MIME (Score:1)
I use ssh a lot. and ssl. and s/mime.
Windows (Score:5, Informative)
If anything is missing, it's probably only missing on Windows.
Support on Linux and Mac is jut fine, I think.
Windows:
- client support is kind of OK
- virtual filesytem support is kind of OK
The biggest missing solution:
- Windows server support. There are some expensive solutions, not sure how well they work.
Cygwin works fine. (Score:5, Informative)
I know back in 1995 when Cygwin came out it got a reputation of being pretty flakey.
But it's come a long way in the last 2 decades.
These days, pretty much any time you think you have a "hmm, Linux can do this but I don't know how to do it on Windows", Cygwin is probably a very good possibility.
Re: (Score:2)
These days I would rather run linux in a VM if I need it for something instead of messing about with cygwin.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
The biggest missing solution: - Windows server support. There are some expensive solutions, not sure how well they work.
I've been using the Bitvise [bitvise.com] sshd server on Windows for about 10 years with no problems. It's free for noncommercial personal use and $100 (plus $20 per year for upgrades) per host for a full license if you're using it for business or commercial purposes. This doesn't seem "expensive" to me, but YMMV of course.
Re: (Score:3)
Re: (Score:2)
If anything is missing, it's probably only missing on Windows.
Support on Linux and Mac is jut fine, I think.
Exactly. I have used ssh for "everything" for a decade and half already. Moving files, remote word processing across town, accessing email. Anything goes when you can forward X. Might be tricker with windows - but I don't do windows and haven't used it since version 3.1.
How do you get around the lag issue? Even on a good connection down the street from my office, the lag is unbearable for me. One thing I thought might help (if anyone knows how) is to turn down the eye candy when forwarding X. If anyone has any insight on the issue, please share!
Re: (Score:3)
Depends sometimes I just use it as a proxy using proxychains and, or i will mount the filesystem and use local copies of programs to work on the remote files in both cases I don't have to use the remote app the forwarding X is not a issue. If I do use app remotely its on my server where I just use a no frills low eye-candy desktop environment and enable compression on my ssh session besides nano, elinks and emacs don require X.
compression, cipher, application (Score:3)
Turn on compression with -C and select a fast cipher with -c
ssh -C -c blowfish-cbc,arcfour -X
Also, some applications (Firefox) seem to do all their own per-pixel rendering rather than using appropriate X primitives. For those applications, VNC with a a minimum color palette may work much better, or choose a different application that does the same job.
Speaking of choosing different applications, consider CLI options. A CLI interface is quite usable at about 64 kbps. I use the GUI only for a browser and e
Re: (Score:2)
Layered with, not instead of, HTTP/2 (Score:5, Interesting)
One of the coolest client-side features of most SSH clients (at least OpenSSH and PuTTY support it) is the ability to turn any SSH connection into a SOCKS5 proxy, provided the server will let you. If your Internet connection has a restrictive stateful firewall on it that blocks your access to many useful legitimate sites, you can just stunnel out over TLS and then have the ability to go outbound on any port (including SSH's default port of 22) using your SOCKS5 proxy. I've used RDP over SSH over TLS before to get around restrictive filters.
Re:Layered with, not instead of, HTTP/2 (Score:5, Informative)
And if SOCKS isn't enough, you can also do ssh -w 42:42 to link a pair of tun interfaces between the two sides. (Slightly less cool because you have to manually configure networking on both ends for it.)
And then the summary decides to hold compression up as the super amazing feature that nobody has ever heard of...
Re: (Score:2)
Re: (Score:2)
One of the coolest client-side features of most SSH clients (at least OpenSSH and PuTTY support it) is the ability to turn any SSH connection into a SOCKS5 proxy, provided the server will let you.
Yep. I was using that nine or ten years ago, with Cygwin, to tunnel my http traffic from work through my home computer. Worked like a charm.
Because it's slow and featureless (Score:5, Insightful)
SSH connections take For. Eh. Ver. relatively speaking:
Subsequent requests using the same connection are quick enough:
% time ssh localserver exit ssh localserver exit 0.00s user 0.00s system 20% cpu 0.039 total
But compare to an HTTPS connection to a remote host:
A brand new request to a remote server takes just 263ms, and a second request only 81ms. Considering that the server is 25ms away, that makes it a bit faster than a cached SSH connection to a local machine.
But even more than that, SSH in this context is a transport, not a protocol. It allows you to build and manage secure connections, but you still have to write a protocol on top of it ("I'll send this command, and you reply with..."). Even if you "cheat" and use SFTP, you're still missing out on fixes to the thousands of little issues people have worked out with HTTP over the years. What's the SFTP equivalent of If-Modified-Since? How will redirects to remote servers work? What's your cross-domain scripting policy? How are you going to handle anonymous connections?
Use SSH for SSH. Use HTTP for HTTP. They're separate things for good reasons.
Re:Because it's slow and featureless (Score:5, Interesting)
Yes.
There have been discussions where I work about setting up encrypted connections for some of the data that we're passing over the Internet. At first it was taken for granted that we'd use SSL or some form of encrypted link to do so.
Then someone very smart mentioned that the data is already sent in a manner in which it is difficult, albeit not impossible, to reconstruct usefully. It might be possible for someone like a state actor or organized crime to spend the time and resources on reconstructing the data, but without any personal information or financial transaction information in the stream, it ended up not even mattering at all anyway.
The flip side is that we really, really want the data to be processed quickly. That means not spending the time and effort on decryption processing overhead where our options are either accepting lower quality of service or alternately spending more on processing power.
Point is that we know that the NSA or FSB or North Korea or the Mafia could intercept and and reconstruct our data, but ultimately we don't care if they can, we don't know why they'd bother, and we don't promise our customers that we'll prevent that. What we do have are QoS guarantees, not to mention a general need for QoS so we don't seem shitty.
Make no mistake, for sensitive information, you should have encryption, despite the overhead. We do use it for anything that would be sensitive, such as authorizations, personal information, and transactions. Even then, we don't kid ourselves about SSL preventing some sort of determined attack by someone with sufficient resources. At that point, there is only so much you can do.
Security risk assessment is not an exercise about what is possible, it about what is *probable* and then assigning your limited security resources to defend against the most likely, but not always most glamorous threats.
For instance, the Sony hack was likely a common combination of social engineering, malware, and shitty risk management with the internal networks. Encrypting the connections would have probably done fuckall for them, because the hackers weren't intercepting traffic, they were actually breaking in with passwords or remote exploits. Having admins who knew how to compartmentalize their shit (and not click on malware) and maybe keep their passwords in an encrypted keychain with some multifactor authentication thrown in would have been priceless.
Internal networks are a cesspool of open shares, with proprietary or sensitive information liberally slathered around, waiting to be found. Everyone assumes the "firewall" or the "encrypted network" will protect them. What actually happens is that too many people are storing too much information on systems that are too numerous and heterogeneous for anything but the most dedicated internal IS department to keep track of. That is, unless there are some intelligent risk assessment and useful programs (like actual training and well enforced security procedures).
Re: (Score:3)
SSH connections take For. Eh. Ver. relatively speaking:
gethotbyaddr + getpeername + gethostbyname
Try configuring your DNS correctly; the reason it's fast with Google as a remote host is that their DNS is correctly configured.
Re: (Score:3)
SSH connections take For. Eh. Ver. relatively speaking:
gethotbyaddr + getpeername + gethostbyname
Try configuring your DNS correctly; the reason it's fast with Google as a remote host is that their DNS is correctly configured.
No, the reason HTTPS is fast (with respect to a comparison to SSH + gethostbyaddr/etc) is because the webserver isn't doing ANY** reverse DNS. The config change needed would be putting "UseDNS no" in sshd_config.
There are other slow downs as well. For example, HTTPS normally has nothing to do with authentication, but SSH almost always makes a bunch of attempts for various auth types (GSSAPI, host based, public key (DSA, RSA, ECDSA), keyboard interactive, password). There's a fair bit more back-end-forth for
Re: (Score:2)
Parent is one side of the "why not". The other is, "why *would* we use ssh for everything?".
The summary (I'm not going to bother reading the article) makes it sound like they want to use ssh in place of HTTPS. That's stupid. We have secure protocols for many things that each fit correctly (ipsec, https, sftp, ssh, various-vpns (ssl/tls/etc), s/mime, pgp/gpg, etc).
The summary says, "SSH does have several cool features over HTTP/2 though, like built-in client authentication which removes the need for registra
Re: (Score:2)
* compression. You mean like this, "SSLCompression On".
Which isn't a good idea anyway [wikipedia.org].
Re: (Score:2)
But even more than that, SSH in this context is a transport, not a protocol. It allows you to build and manage secure connections, but you still have to write a protocol on top of it ("I'll send this command, and you reply with...").
Or you could just layer HTTP as is on top of SSH. Which would also give answers to all the other questions that you have posed.
The point about speed is a good one, though.
Integration into OS (Score:2)
I've been wondering for some time now why TLS (SSH) is not integrated into the OS, to extend the TCP/IP stack on a low level.
Re: (Score:2)
I've been wondering for some time now why TLS (SSH) is not integrated into the OS, to extend the TCP/IP stack on a low level.
Hint: you don't need it when all mass-market modern operating systems I've used have IPSEC built in.
Of course IPSEC is an abomination that's a billion times easier to misconfigure than to configure correctly, and still suffers from the same authentication issues as HTTPS. If they hadn't thrown the kitchen sink in the spec, we'd probably all be using encrypted communications by now. Hey, did anyone see the NSA skulking around the IPSEC committee?
Re: (Score:2)
Because TLS is not SSH?
TLS 1.x is derived from SSL, not SSH.
We ARE using ssh and https for everything (Score:5, Interesting)
telnet and ftp practically died a while back, http is on the way out. In most corporate environments, other protocols such as X are local only and remote use is over ssh tunnels. IMAP/SMTP takes place over TLS when using decent providers. I guess there is a question of whether SSH and HTTPs should be merged. But a lot of work has been put in both and would be difficult to replicate and make as secure from the start. No hurry.
The only exceptions are organizations with lax security (like Sony apparently) and cases where security or integrity is completely not an issue. I guess if you broadcast a video as unencrypted UDP over a local network, that's fine.
Re: (Score:2)
http is on the way out
LOLWAT? Given the ubiquity of JSON-over-REST as a common API for just about everything, HTTP is the exact opposite of on the way out. If anything, it's absorbing and replacing many other protocols (even when it shouldn't).
Re: (Score:2)
Ignore. HTTP vs HTTPS, yes. I'm still waiting for my coffee to kick in.
Re: (Score:3)
Unfortunately ftp has far from died. There are so many other organizations I deal with that haven't been hit with the ssh/sftp clue stick and can't do anything other than ftp. Or worse still, ftps which is a firewall administrator's nightmare.
We even deal with one company who not only refuses to use sftp, but they refuse ftp in passive mode and want us to connect to an ftp server of theirs that only supports active mode. Their admin reckons ftp in passive mode is insecure and won't deal with sftp. Sigh. The
Public Key, not SSH. (Score:3, Interesting)
SSH as a protocol was designed for interactive login, and it has some issues when used for other applications. But there is one key aspect of it that needs to break out of SSH, the public key cryptography part.
When creating an account on a web site, rather than entering a User ID and password the browser should generate a public-private pair, and send the public part to the other side. Logins can then be done just like SSH does, with a cryptographic exchange.
The "lost password database" goes away completely. If you got the database on the far end it would only contain public keys, which would not allow logins. The whole "everyone must change their password" nonsense goes away.
So don't force SSH on us, but let's all work to get more public key based logins.
Re:Public Key, not SSH. (Score:4, Insightful)
The "my hard drive crashed and now all my private keys are gone so I've irreversibly lost access to all my accounts" problem comes up though.
You also need a secure method of either transferring keys between devices or linking new keys to existing accounts.
Re: (Score:2)
This problem is exactly the same for passwords, at least if you follow decent security practices and never reuse passwords.
It is actually worse for passwords, since you can use the same private key securely with all sites. It is simple to backup a single private key, not so simple to backup your entire ever-changing database of passwords.
Re: (Score:2)
No it's not.
The "lost password database" goes away completely
That's the bit that creates the problem of losing access.
Re: (Score:2)
I don't get what you are saying. I did not say the things you quoted.
I have my SSH private key saved securely. That is easy, it does not take up any room at all. My password database on the other hand is not backed up; I am not willing to make the compromises necessary to do so. I will just have to recreate passwords everywhere in case my drive crashes.
Life would be a lot easier if sites would accept my SSH key or my PGP key as ID.
Re: (Score:2)
the public key cryptography part.
The thing is, that is already available in any protocol employing TLS. Client side certificates are the same as ssh keypairs. There's some capability in x509 certificates not in ssh keypairs, but all that can be ignored.
But if you dig into the current in-vogue two-factor stardard (U2F), they actually are implementing what you describe. "During registration with an online service, the user's client device creates a new key pair. It retains the private key and registers the public key with the online servi
Re: (Score:2)
This, like all password/key managers, completely breaks if you do lose the database or don't have it available.
Trust (Score:4, Insightful)
I think, because only a fraction of 'net users are security conscious.
The rest just use the 'defaults' of their apps and search result links for things like email , online shopping, and online banking, and trust(?) that the people providing the access to their email, online banking, and online shopping, kept them safe.
Answering the question (Score:2)
Why aren't we? Because using ssh doesn't prevent people from posting their private keys to github and being shocked, outraged even, that their entire infrastructure is now compromised?
because setting up a SSH cert is still a PitA (Score:2)
seriously, have you ever tried to get a cert installed properly in J2EE? Node? PHP/Apache? Ever tried to get PGP working right on t-bird?
There is nothing about the process that is straightforward in any way (including the cert signing stuff). Thus, most websites will simply find it easier to not bother. Let those who can pay for experts pay for it, but until expertise becomes "push this button" easy, and still almost free, it isn't worth it for typical web traffic.
Re: (Score:2)
This is exactly why it would be nice to use SSH instead. SSH key handling is easy.
The slowness and excessive round trips that SSH connections require makes it entirely impractical to replace HTTPS, of course, but I would LOVE if the key handling parts were copied.
Another idea... (Score:5, Funny)
Condoms are pretty good for safe sex. I think we should be using condoms to protect our bank accounts, for giving everyone safe drinking water, for screening passengers at airports and for securing your valuables in hotel rooms.
Re: (Score:2)
Condoms are pretty good for safe sex. I think we should be using condoms to protect our bank accounts, for giving everyone safe drinking water, for screening passengers at airports and for securing your valuables in hotel rooms.
I can assure you: leave a used condom on top of your valuables and no one who enters that hotel room will touch them.
Just Call Me Mr. Ssh (Score:2)
why (Score:2)
Why Aren't We Using SSH For Everything?
Because only morons use the same tool for everything. Experts use the best tool for the job at hand.
And besides, most of us use SSH for a lot of things. For remote management, copying files, for accessing our git repositories and probably 20 other things.
Well, I already am but confusion.... (Score:2)
If you are using a SSH tunnel or similarly with a VPN, you are already doing 'everything' over SSH, that is to say the whole network connection. Even my X11 server is using it right now.
However HTTP/S, SMTP and the like are protocols, not transport mechanisms.
Re:PITA (Score:5, Informative)
Hummm... configuring openssh is really not difficult on most modern Linux distributions.
Install the openssh packages, execute ssh-keygen once per user and you are basically done.
The only tricky part for some novice users is to copy the public key to the server (in .ssh/authorized_keys) but recent versions of openssh provide the ssh-copy-id tool that can do that for you.
Re: (Score:2)
Remote root access is allowed by default on at least some distros.
So take that up with the maintainers of the (braindead) distros you didn't mention and get something done about it. Your complaint has nothing whatsoever to do with the OpenSSH software itself.
Re: (Score:2)
Which don't?
I always check it, and every distro I've tried has root login set to yes. I don't try as many distros as I used to though.
Re: (Score:2)
Someone was aiming at "cool story, bro".
Re: (Score:3)
Re: (Score:2)
Instead of being first hand journalism, sites like Slashdot and Reddit aggregate news and lets people discuss it.
At least old timey newspapers would hire journalists. Here we just regurgitate stuff we find. I don't really get the whole Reddit/Slashdot was first kind of competitiveness in the light that neither site creates much original.
Re: (Score:2)
Oh I thought it was a Ycombinator Hacker News post first. Besides each site has different communities with different values and cultures it is intresting to see the different conclusions they will come to.
Re: (Score:2)
I wish Microsoft would bite the bullet and just drop telnet and fork Openssh for use on windows, at this point there is no good reason for them not to.
Re: (Score:2)
TCP also lacks the notion of virtual hosts, but it doesn't preclude it from being used as a base. There's no reason why you can't use SSH as the underlying "security layer" protocol, and then stick HTTP on top of that pretty much as is - complete with hostname in the request (and hence, virtual hosts).
Re: (Score:2)
Nope - an annoyance that is minor because the problem is so temporary. Soon enough we'll use IPv6, and every virtual host will have its own address
I really wish that was true, but seeing as BT had to install a parallel leased line to provide IPv6 - luckily we didn't have to pay for it - I can't see consumer providers bothering their arses to upgrade anytime soon.