SSH is a great tool many people are familiar with, but many more people aren't. Even if you use ssh daily, Why aren’t we using SSH for everything? is a great introduction to many things ssh does now, and what it could be used for in the future. One humble example is an ssh-chat server. The icing on the cake? The source for ssh-chat is open.
Related Stories
SSH key forwarding is to be avoided when possible. When it is not possibile to avoid, it is a good idea to limit what gets forwarded. Software developer Vincent Bernat describes one way by putting a simple shell script wrapper around the SSH client to provide a session with a unique, ephemeral key agent.
ssh-agent is a program to hold in memory the private keys used by SSH for public-key authentication. When the agent is running, ssh forwards to it the signature requests from the server. The agent performs the private key operations and returns the results to ssh. It is useful if you keep your private keys encrypted on disk and you don't want to type the password at each connection. Keeping the agent secure is critical: someone able to communicate with the agent can authenticate on your behalf on remote servers.
ssh also provides the ability to forward the agent to a remote server. From this remote server, you can authenticate to another server using your local agent, without copying your private key on the intermediate server. As stated in the manual page, this is dangerous!
Perhaps another approach would be to embed the wrapper in the ProxyCommand configuration directive, thus obviating the need for either a shell alias or shell function.
How and why have soylentils had to deal with SSH agent forwarding?
Previously:
(2019) How SSH Key Shielding Works
(2019) SSH Gets Protection Against Side Channel Attacks
(2018) Default OpenSSH-Portable RSA Private Key Encryption is Poor
(2017) SSH vs OpenVPN for Tunneling
(2016) Upgrade Your SSH Keys
(2015) Why Aren't We Using SSH for Everything?
(Score: 2) by d on Saturday January 03 2015, @11:18AM
It's said that NSA has broken it in some cases: http://www.spiegel.de/international/world/nsa-documents-attacks-on-vpn-ssl-tls-ssh-tor-a-1010525.html [spiegel.de] (also, see talk: http://media.ccc.de/browse/congress/2014/31c3_-_6258_-_en_-_saal_1_-_201412282030_-_reconstructing_narratives_-_jacob_-_laura_poitras.html [media.ccc.de] )
(Score: 3, Informative) by canopic jug on Saturday January 03 2015, @02:14PM
As far as OpenSSH goes, the weak ciphers have been removed [openssh.com] from the default as of version 6.7. So that should make it more robust except for the old systems out there. Even for the old systems, it is possible to specify in the server's configuration that it not accept the weak ciphers.
About the client, and related utilities, showing MD5 hex checksums for keys, those will be replaced with SHA256 base64-encoded [marc.info] fingerprints in a future version.
Money is not free speech. Elections should not be auctions.
(Score: 3, Informative) by frojack on Saturday January 03 2015, @07:28PM
Just as likely to be old short keypairs (1024 or less), which are said to be childs play to crack with modern processors.
Many experts recommend 4096 bit key lengthts, although there are some systems that can't handle keys longer 2048.
There is a slight log-in time penalty for longer keys, but once established the session key is used and it is much faster.
No, you are mistaken. I've always had this sig.
(Score: 2) by pkrasimirov on Saturday January 03 2015, @11:45AM
> Why Aren’t We Using SSH for Everything?
Because it is not for everything.
Why aren’t we using root for everything?
(Score: 1, Insightful) by Anonymous Coward on Saturday January 03 2015, @11:57AM
i stopped using root because it was no longer the default user in ubuntu, you insensitive clod!
(Score: 0) by Anonymous Coward on Saturday January 03 2015, @12:03PM
Because using SSH for everything makes everything more secure. Using root for everything makes everything less secure.
(Score: 0) by Anonymous Coward on Saturday January 03 2015, @12:05PM
because root doesn't taste like bacon
(Score: 2) by gallondr00nk on Saturday January 03 2015, @01:12PM
Because Windows XP went EOL in April last year :)
(Score: 2) by frojack on Saturday January 03 2015, @07:39PM
> Why Aren’t We Using SSH for Everything?
Because it is not for everything.
Exactly.
Just because some kid wrote a chat server less than a month ago doesn't make this a good idea.
And once you are on the server, your chat session is not necessarily encrypted.
There are things ssh is great for, chat isn't one of them.
(If you want secure chat use regular old XMPP (jabber) on just about any server yes, even Google's, and turn on the OTR feature.
that provides end to end encryption that even the XMPP server can't decode).
No, you are mistaken. I've always had this sig.
(Score: 3, Informative) by bzipitidoo on Saturday January 03 2015, @12:17PM
We are. We have almost entirely replaced telnet with ssh. Telnet still has a few niche uses, like to connect to a port to test whether a server is up. But its many deficiencies, like sending passwords in the clear, were recognized decades ago. Ssh has been around long enough that it even has one of the well known ports reserved for its use.
scp and sftp have not replaced ftp because most ftp transfers don't need encryption. Most of my ftp use is anonymous ftp, of publicly available files, like Linux distros, so there's no logging in and exposing of a password. Going to md5sum those anyway if I want to check that the transfer wasn't corrupted. As for protecting the privacy of whatever I downloaded, I don't care, not for those files. Transfers on LANs often do not need any protection either. If I do want encryption, there are VPNs.
Or did the article author mean the whole SSL suite of tools, with the OpenSSL library? Well, there was that heartbleed problem, but apart from that, why not SSL? And by the way, why isn't that sshchat application called sslchat or just schat?
(Score: 2) by tynin on Saturday January 03 2015, @03:02PM
FYI u can port test with ssh.
ssh -vp port IP
E.g. ssh -vp 80 10.0.0.1
V stands for verbose so you'll see it say connection established. And p is for the port.
Sent from a phone... Sorry for the bad formatting.
(Score: 1) by RedGreen on Saturday January 03 2015, @04:16PM
" Going to md5sum those anyway if I want to check that the transfer wasn't corrupted."
rsync --checksum for the win.
"I modded down, down, down, and the flames went higher." -- Sven Olsen
(Score: 2) by sjames on Saturday January 03 2015, @07:55PM
SSL introduces un-needed complications. For example, a secure chat server can be built just by making the totally unsecured client pointed at a totally unsecured chat server on localhost be the shell for the pty. The actual client doesn't even need a chat program to make that work. No kooky APIs where you're just supposed to know you have to hop on one foot while patting your head and rubbing your belly (counterclockwise) while reciting Jabberwocky backwards when you frobnicate the wadget or it will send the whole datastream directly to the NSA in the clear.
(Score: 4, Insightful) by Justin Case on Saturday January 03 2015, @12:18PM
OK the article has some interesting examples. Yes I read it. Yeah, I know.
SSH is great. HTTPS is pretty good too, although with any crypto you still have the problem of initial key generation, safe storage, exchange. Who are you going to trust while you are still bootstrapping trust? Your browser might have built-in trust for a Three Letter Agency's root certificate. It may or may not reveal this to you when you ask. Your hardware may have already been toasted before you bought it.
Nevertheless, crypto is never going to be easier to crack than no-crypto. It is time to start encrypting everything everywhere. (Yes I'm looking at you SN. Protip: If you manually change the SN URL to https it will work. The web server is ready to go. We just need all the links to switch from http to https.)
But, you say, my web site is just static text! No sensitive data. No login. I have no secrets. Everyone can read everything. Why should I bother with crypto?
Because even our ISPs are inserting malicious scripts in pages as they get downloaded. How do I know they are malicious? Because the author didn't put them there, that's why. That's reason enough. Even if it is just an ad, it is being represented as coming from the site you think you're visiting. If you really wanted the ISP's ads you'd go to the ISP's "give me lots of ads" page wouldn't you?
(Score: 1) by dmbasso on Saturday January 03 2015, @12:30PM
Why should I bother with crypto?
Because even our ISPs are inserting malicious scripts in pages as they get downloaded. How do I know they are malicious? Because the author didn't put them there, that's why.
I couldn't agree more! Additionally, I might have no secrets, but the one viewing my kitten photos might be infringing his country's kitten-hating laws. If I can help my poor oppressed fellow, I think I should.
`echo $[0x853204FA81]|tr 0-9 ionbsdeaml`@gmail.com
(Score: 2) by c0lo on Saturday January 03 2015, @03:11PM
But when you come to have some, why should others know you conspicuously switched to encryption: isn't it better to use https as a rule?
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 2) by frojack on Saturday January 03 2015, @07:46PM
Exactly...
And not using crypto casts aspersions on those that do.
FTR I always connect to SN with ssl, even though everything on the site is freely available information.
No, you are mistaken. I've always had this sig.
(Score: 2) by darkfeline on Saturday January 03 2015, @11:55PM
>But, you say, my web site is just static text! No sensitive data. No login. I have no secrets. Everyone can read everything. Why should I bother with crypto?
>Because even our ISPs are inserting malicious scripts in pages as they get downloaded. How do I know they are malicious? Because the author didn't put them there, that's why. That's reason enough. Even if it is just an ad, it is being represented as coming from the site you think you're visiting. If you really wanted the ISP's ads you'd go to the ISP's "give me lots of ads" page wouldn't you?
You don't need crypto as in encryption for that, just signing. HTML5 should have added a method to PGP-sign HTML source...
Join the SDF Public Access UNIX System today!
(Score: 1) by CaptainK on Saturday January 03 2015, @12:32PM
Didn't we already agree that open source != secure?
http://archive.oreilly.com/pub/post/is_open_source_secure.html [oreilly.com]
http://www.zdnet.com/article/six-open-source-security-myths-debunked-and-eight-real-challenges-to-consider/ [zdnet.com]
Although, searching for reasons not to use ssh only shows articles on password key management, using certificates instead, debates on what port to run on etc.
Here are some considerations http://www.commandprompt.com/blogs/ildefonso_camargo/2013/11/security_considerations_while_using_ssh-agent/ [commandprompt.com]
Laslty, http://greplinux.com/blog/2014/01/29/the-at-n-hack-why-absolute-security-is-a-myth/ [greplinux.com]
In conclusion, looks like ssh is the least of the evils for now.
Your imagination is your only limitation to creation.
(Score: 0) by Anonymous Coward on Saturday January 03 2015, @05:56PM
Didn't we already agree that open source != secure?
*Nothing* is perfectly secure, though you'll find no one saying that open source gives you 100% security anyway. What they say is that it's easier to spot backdoors and fork projects if necessary, making you more (but not perfectly) secure.
(Score: 2) by frojack on Saturday January 03 2015, @08:08PM
Just about NONE of your posted links make the point you THINK they make, and the couple that are close to the mark, also debunk the claims to some extent.
Besides, this thread is not about some random opensource project (other than TFA's ssh-chat program) but rather it is about core ssh capabilities. The point about not using ssh-agent is valid, which is why most people never use the agent unless both ends are on trusted servers. (Just because you use an agent doesn't mean you have to load ALL your keys into it).
No, you are mistaken. I've always had this sig.
(Score: 2) by Aiwendil on Saturday January 03 2015, @01:04PM
Let's see here..
MUD over ssh - already being done, also do not forget that today ssl is supported for most telnet MUD and telnet BBS:es, also nothing really to prevent you from having a bbs running instead of the shell for your users and taking the login-info from the enviornment (this has been done for quite some time)
chat over SSH - irc over ssl, or in case you want to be "one on one" on a machine where you both have an ssh-account then just set up talk/talkd.
Basically it all just seems to have the "advantage" (depending on your point of view) of enforced identification (but nothing really prevents you from hacking this into nameserv on irc).
However I must admit that one thing that would be nice would be if ircclients would remember and compare the ssl-certs in use for the different servers it connects to.
Or am I missing something basic here?
(Score: 2) by kaszz on Saturday January 03 2015, @02:03PM
SSH is good as a Telnet replacement and piping. For other application one can enable SSL libraries or simple do away with it completely by using IPv6 IPsec.. unless NSA had messed up the standard.
SSH is mainly a replacement for telnet and the software is highly integrated. Created in a time where encryption was quite strange, but serious administrators saw the need to protect root passwords.. For the general case there's better solutions, really.
Pro tip: Clean up IPsec and deploy it.
(Score: 2) by frojack on Saturday January 03 2015, @08:44PM
Telnet? Really?
SSH is good for a lot of things, which it seems you lump into "piping" and promptly forget about.
- Forwarded X sessions
- sftp / ftps - usually wired directly into your file managers like Dolphin, Thunar, PCman, MC, etc for
accessing remote file systems as if they were local
- Forwarded ports for mail, web, monitoring
- Remote control of virtually any machine
The thing is, piping is a LOT of what we do on the net. You can't just dismiss it as irrelevant.
Then you recommend SSL (already severely compromised [spiegel.de].
The NSA and its allies routinely intercept such connections -- by the millions. According to an NSA document, the agency intended to crack 10 million intercepted https connections a day by late 2012.
In short, you seemingly dismiss ssh as old-hat, from a bygone era, while lauding ssl and ipsec. But the NSA is after those "piping" systems too. See VULCANDEATHGRIP [arstechnica.com].
No, you are mistaken. I've always had this sig.
(Score: 2) by kaszz on Saturday January 03 2015, @10:00PM
I just think of SSH as a telnet replacement. To make use of permanent secure piping you would need to keep SSH running which may be more tricky than using a SSL library. Which SSH really is.. a "telnet" implemented using a SSL library calls.
I think of SSL as a concept. That some people suck at implementation doesn't make it wrong.
SSH is certainly not old hat. It's a really good tool (minus not found security bugs). SSL and IPsec is the right approach to secure and reliable streams as a system. If you need to handle a massive amount of connections SSH will likely show some deficiencies. Why would HTTPS be around otherwise?
Btw, The certificate authority system used with HTTPS sucks big time security wise as any CA can authorize for any website and no fingerprinting is implemented by default in web browsers. It's also hard for websites to change their own keys because it's tied with a specific CA.
(Score: 2) by frojack on Sunday January 04 2015, @04:05AM
To make use of permanent secure piping you would need to keep SSH running which may be more tricky than using a SSL library.
Not really, I have had ssh connections open between offices in Washington state and Australia for WEEKS at a time.
There is currently a problem with ssl and "resumed" connections. Most of the NSA ssl compromises are from dormant and then resumed ssl connections. (This sounds like a fixable problem now that we know that's how it is being done.
Some things clearly work better with ssl, web browser stuff, where you really can't expect people to have a key pre-established on every web server.
But these always take some control out the the user's hands (substituting some unknown session key for your own public/private key pair.
As for the current story, SSH-CHAT, it looks like a case of a guy with a hammer looking at every problem as if it were a nail.
No, you are mistaken. I've always had this sig.
(Score: 0) by Anonymous Coward on Saturday January 03 2015, @02:29PM
disable root login over ssh? ok .. maybe.
else it's just a looooong keyboard and monitor cable lying infront of your house on the public road with some "safe" lockpad.
srsly ... version 6+ and it's still a computer with flaws.
also one more port open.
(Score: 0) by Anonymous Coward on Saturday January 03 2015, @02:51PM
When using an IRC client or a web browser is there a trivial way to accidentally allow your client or browser to extend the ability to authenticate as you to other servers? Because with an SSH client there is a trivial misconfiguration that would do exactly that: hand authority for authentication to be performed using your local keys via ssh agent forwarding.
Is this inherently the fault of SSH? No, this is inherently a form of user error if it happens. Is it reasonable to think that using an IRC client one needs to be paranoid about also leaking the ability to log in as your user on other computers? No it is not, why would something that offers this capability be used as a transport layer for something else? Most of the features explained as benefits of using SSH, such as multiplexing, are implemented better in SCTP which is a proper transport layer.
Your question should be: why isn't SCTP ubiquitous on the Internet?
SSH isn't used for stuff like this because SSH isn't the right tool for the job.
(Score: 0) by Anonymous Coward on Saturday January 03 2015, @02:55PM
Long term the solution is a layer 4 proto that does some fancy block chaining type stuff. It is surprisingly easy to queer bulk snooping if you communications are just point to point, since bulk snooping is dependent on the uniformity of the transient data.
Simply reverse the layer 4 frame bitwise at both ends, and anything in between analyzing above layer 3 will fail. How to do this sort of thing in a way that can't be easily undone is more a question of cost than of security. For example, you could encrypt 4 frames, and include a key in the open in frame 4. The receiving host buffers and decrypts frames 1 2 and 3, after receiving frame 4. (But so can the snooping switch right?) It doesn't matter, the point is you've quadrupled the RAM and CPU required on the snooping equipment. End devices will ALWAYS outperform switching equipment in the aggregate. So broad support of such a system would make non-snooping networks cheaper than snooping ones, and good ISP's more competitive than bad ones.
All that is really required to deslime the Internet, is to make being a corporate slime, more expensive.
(Score: 2) by kaszz on Saturday January 03 2015, @03:25PM
Neat idea with messing up RAM requirements :P
(Score: 1) by pTamok on Saturday January 03 2015, @08:08PM
You are assuming the snoops wish to decrypt on the fly.
They don't.
Currently, according to the reports I have read, they record the session, and decrypt the recorded session as necessary - which need not be in real time.
Again, according to the reports I have read, the NSA simply record ALL encrypted sessions that flow over the communications circuits they have tapped, and store them for later analysis, if later analysis is necessary.
Anyone wishing to make life difficult for the snoops needs to radically increase the volume of encrypted data. Even then, some judicious filtering out, by the snoops, of data that is not originated or received by a person of interest will reduce the needed storage requirement.
As far as I can tell, the best thing to do is use perfect forward security; use encryption algorithms that are regarded as 'difficult to break' by the academic community; use keys/passphrases that are long and strong; and use good random number generators.
Be aware that if you are a person of interest to national security organisations, they have capabilities to do all sorts of nefarious things, like plant hardware keyloggers in unattended laptops; and activate special firmware you may not be aware of. If you play with the big boys, then pencil and (rice) paper methods and one-time-pads are pretty much all you can reliably use. Pretty much all COTS hardware has been suborned in one way or another.
(Score: 0) by Anonymous Coward on Saturday January 03 2015, @10:21PM
Post processing happens AFTER interception. So increasing interception costs as a technique for preserving privacy still applies. Second, in post processing systems, big data compilation is cost prohibitive at the commercial and local law enforcement level. (The local PD doesn't have a petabyte data farm at its disposal) So for most cases, inflating interception costs is still a step in the right direction. And while it doesn't solve every problem, there are a lot of problems out there that will take a running start to scale. So one step is better than no steps.
Note that I'm not advocating any one technique. I'm saying: Generally, capacity differences between end node, and transitory node represent a fulcrum that privacy technology can bend against. It is a big lever, and it is essentially free.
(Score: 1) by pTamok on Sunday January 04 2015, @09:43PM
But the technique described above does not increase interception logging costs, only subsequent decryption costs. The snoops log EVERYTHING that is not transmitted in the clear, and therefore susceptible to instant analysis. Doing fancy stuff at layer 4 is completely irrelevant if you capture everything at layer-3, which you can then replay and decrypt at leisure.
This also means that even if you do do fancy stuff at layer-4, you don't need to add resources at the point of interception for decryption: you can 'simply' tee the layer-3 stream off to a decryption centre which does have the resourcs to decrypt your fancy stuff at layer-4: you do not need the layer-4 decryption capability at the point of interception - you simply copy the traffic to where you do have resources.
One way in which life could be made less easy for snooping is if every PC, laptop, server, and smartphone were simultaneously something like TOR transit node (middle relay or bridge) and TOR exit node, using the full capacity of the network links available to it. Instead of being idle, the links are filled with random data between the transit nodes all the time. This would mean that any properly encrypted data you send or receive (which is indistinguishable from random data) is blended in or hidden by the random chaff. The only way a snoop can get usable information then is to hack into your machine and intercept the connection between the TOR-like transit node and TOR-like exit node that is in your machine. While not impossible, it is difficult. Note that I'm not aware of any network with this architecture currently. There has been academic work on networks with this architecture, but I don't have the references to hand - read this paper (especially looking at how chaff works): http://people.csail.mit.edu/vshyeung/docs/6857project.pdf [mit.edu] and follow up from there, paying attention to the keywords that often crop up, such as "Chaum-Mixes" [ https://en.wikipedia.org/wiki/Mix_network [wikipedia.org] ], and "anonymous routing". There are obvious problems with real-world implementations - not least, generating significant volumes of random chaff is not easy, and ensuring your encryption is indistinguishable from the random chaff, even when challenged by sophisticated signal analysis, is also tough.
(Score: 0) by Anonymous Coward on Monday January 05 2015, @04:01PM
"does not increase interception logging costs"
Have you ever tried to capture a single stream passing through a fully loaded switch or router? I I haven't done this sort of thing in years, but... the most limiting factors are in the network equipment. You can only switch at line rate if the switching algorithms are small and fast. The more complex the algorithm the more clock cycles per transmission and the more switches you need. Even if you capture the whole frame, you still have to unwrap it at some point to get to the data. So you are still burning more clock cycles even in post processing.
Extremely large capture rates are the domain of governments. At that point there are easier methods of harming you than cracking crypto. But even so, post processing is done using statistical techniques. (which by definition, only work if your data clusters) So if data clusters less at layer 4, then you've queered both post processing, AND real time inspection. Or at the very least, compelled a long and irritating development cycle in Dr. Evils lab. :-)
If all I want out of an ISP is layer 3 service, and he is giving me layer 4+ service (against my will), then simply making the algorithms at layer 4 more complex will increase infrastructure costs at layer 4+. The costs to the user are disproportional. His costs are a multiple of his subscriber base. Mine are not. IOW, network neutrality is solvable by engineering complexity into layer 4. The nature of the complexity is less important than the fact that complexity exists. The entropy, IS the leverage. You don't need much. Just enough to sour milk.
(Score: 1) by anti-NAT on Saturday January 03 2015, @02:57PM
How do we know he doesn't? How do we know he isn't recording all the chat dialogs?
He might claim not to be, and probably isn't, but what *proof* is there that he isn't?
This chat-server or more generally client/server model requires that the server be a completely trusted and trustworthy intermediary, because it sees everything. Using some random chat server on the Internet means it should not and cannot be trusted, despite the claims of it's operator (who you also don't know).