Hey everyone, thanks for dropping by the main ssh-chat server (chat.shazow.net). That one is running a fairly old version of the software (/uptime -> 13579h33m20.784837542s).
I just deployed the latest Github release on an east-coast server here, please come help test it:
^C doesn't work because the SSH client is passing it through to the remote server (which is normally what you want), not because the client itself is stuck.
ssh has a little-known "escape character" feature for situations like this. You can type <ENTER> ~. to tell the client itself to exit, or <ENTER> ~? for a list of other escape commands.
It doesn't hurt to mash <ENTER> a few times, either, just to tell ssh that you're serious. I used to have it not work occasionally until I started mashing -- probably because it passed the newline through and I didn't make it to ~ fast enough, so whap-whap-whap ~. is my muscle memory for killing ssh now.
This is extremely useful information if you do a lot of work on remote servers, particularly when you restart networking and lock yourself out. You can get your shell back without having to kill the terminal or open another to kill ssh, which I see a lot of people do. It's too bad it's little-known.
~C is useful too so you can alter your forwarding setup (including cancelling open forwards) without dropping the connection.
Do you happen to be an older North Carolinian? I don't think I've heard anyone use "mash" in this sense since being a bewildered Northerner in an NC elementary school in the 70's when a teacher asked me to "mash the lights". Apparently some light switches once used buttons, and "mash" was (and possibly still is) a regionalism for "press".
Is it used elsewhere too? Personally I'd use "mash" to describe preparing potatoes, and would need it for brewing beer, but I wouldn't have considered that it might be applicable to escaping from ssh. Although searching now, I see that it also seems to be a term-of-the art for rapid button pressing in video games. And I see that suggestions that it's also used in the West Indies.
Would you say "mash <up-arrow> several times until" or "mash <up-arrow> until"? That is, in gaming terminology, would you ever use "mash" to describe pressing a key only a single time? Or does "mash" always describe repeatedly and rapidly pressing a key?
Mash, as it did in the above context, only describes pushing a button rapidly and repeatedly. It can be used interchangably with spam, but usually implys a shorter time frame, and when using spam, you usually name the action, not the button.
To demonstrate the difference:
"After you get knocked out in punch out, mash A to get back up"
"In Quake 2, spamming rockets to protect entryways is the only use for the stupid things."
That's not ssh's fault; you can pipe /dev/random into just about anything and get the same result. Rate-limiting isn't the job of the protocol, in this case - it's the job of the chat server application.
As tempting as it is to use SSH everywhere (for exactly the reasons outlined here), other protocols exist because they usually have some form of marginal gains over the alternatives, and marginal gains matter at scale.
Encrpytion isn't always something that's needed (arguably; though I'm all for enabling it everywhere it can be enabled), and in places where it's not critical, it adds performance overhead both client- and server-side.
SSH also has to be shoehorned into distributed chat applications, for example, else the interface deters inexperienced users and, again, almost inevitably, overhead is incurred. Using PGP for authentication and encryption in this case is a saner choice because it supports decryption by groups of recipients, and implementing a protocol over UDP (or even TCP) is plenty.
EDIT: Just to be clear, though, there are some pretty cool nonstandard uses of SSH out there. Medium OP's chat server is a great example.
> As tempting as it is to use SSH everywhere (for exactly the reasons outlined here), other protocols exist because they usually have some form of marginal gains over the alternatives, and marginal gains matter at scale.
I heard people "at scale" also use micro services over HTTP. Or even Rest for mobile apps, where latency is a real issue.
So I am not buying that part. I think HTTP (over TCP) has won because the web has won. As always technical people are overestimating the importance of technical aspects of a product and thereby their own importance, when really it is all about usability and network effects.
>I think HTTP (over TCP) has won because the web has won.
For sure. If I were building a mobile app that had to talk to a server, a RESTful API would be the first thing that comes to mind.
It's not the most lightweight protocol, but it's the protocol with a structure and interface that's designed for this -- making it a natural choice.
You could to a certain extent implement a REST-like API over SSH, or UDP for that matter, but that takes extra effort, and the fact of the matter is that many developers are just working on a higher level of abstraction, and lack the expertise to build new protocol. (My reasoning is that the lower barrier of entry into software development has created many developers with skillsets specialized in use of more "modern" technologies).
TL;DR -- IMO, using verbs to act on resources is easier to grok than working in terms of packets for most developers, and is sufficient in most situations. I still believe there are better alternatives for high-performance networking.
It is very easy to write a virus that is not detected by any anti-virus. I don't see how dropping an SSH key on some machine is worse than dropping a remote shell on it.
It's not like SSH keys are stealthy or something - any sysadmin worth his salt will occasionally look at his authorized_keys list.
It's simple to setup. You first create a CA, and then you sign the servers public key and the client's public key, and you take the resulting certs (alongside the CA's pubkey) and move them over to the machines. And I think it's important to note that you can do this process on any machine-- perhaps an air-gapped $30 Raspberry Pi, or if you're less paranoid you can do it on your laptop, but the point is that you can generate keys in bulk, offline, and move them over to dozens of machines in one fell swoop.
You still need to maintain an authorized_keys file in your homedir with your client public key, which means if someone was able to get the CA key they still wouldn't be able to get into the server without first getting the key that corresponds to the entry in your authorized_keys file. And likewise, if someone was able to get access to your user key, they would be able to login with it but wouldn't be able to add a backdoor key to the authorized_keys file unless they also had the CA key to sign it with, because both the client and server check the other's certificate against the CA pubkey.
Of course, if you see ssh keys as a panacea and subsequently use passwordless sudo or a weak enough password, they have root and can just edit your sshd_config and this was all for naught. But it does solve the problem of an unchecked authorized_keys file.
I wish everyone checked their authorized_keys file like you do. Sadly, this is rarely the case across the board, based on my experience. People are lazy. There are good aspects of being lazy, but this is one of the sub-optimal cases.
In summary, this methodology would not likely be detected even in places where folks and admins are quite vigilant. The behavior and usage is expected. If I were unethical, I could gain access to thousands of companies by simply emailing a link to github and saying, "This script is giving me errors, what am I doing wrong?" Using the default settings in ssh an sudo, I can access all of their systems with no syslog entries and gain root to anything they have sudo on.
I saw it on Lobste.rs and did a quick search for the url but it returned nothing. Medium articles suck with that hash they put on. Thought it was worthy of submitting here.
This is actually one area where I like our IBM i system, the 5250 console may be extremely lacking in many features compared to say a VT100, but the block-based console eliminates the remote server from needing to handle redrawing or dealing with input until the user explicitly requests an action. It's pretty amazing to see a thousand users connected to the box and none of them have any latency with inputting data (getting a new screen back from the server make take a couple milliseconds) because it's all done locally until they press a function key or some other action button that pushes the data off to the server.
This technique assumes the operator is OK with taking a few weeks for all users to register the new host key. In the event of a leak, revocation of the leaked key must be immediate. That's why we have CRLs (and OneCRL) and OCSP.
No. I said that changing the key, which must happen, will trigger a warning that will scare users away. Which is (partly) why no one uses SSH with non technical populations.
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
IT IS POSSIBLE THAT SOMONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now!
Then, yes, users will be prompted in the scariest possible language.
Compare this with HTTPS/browsers, which care not a lick if a certificate/fingerprint is different, provided that the certificate is valid and the chain is trusted.
> When you join ssh-chat, not only do I know who you claim to be, but I can also permanently and securely attach an identity to your connection without any user intervention on your part.
A great part of IRC is that there's no registration. There's no identity.
There doesn't have to be registration or a consistent identity with ssh, when it's used as described in TFA. Just pass a different identity file with "-i".
Of course, most uses of ssh would use a preestablished account on a host and that wouldn't vary, but there's nothing in the protocol requiring that.
That's... not true at all? Nickserv and Chanserv are essential parts of modern IRC and in practice people need a consistent identity to interact with most channels.
Most? Essential? Not really. I can hop into most of the channels with a different nick every time. Nobody cares. I can even use the same one without registering it as long as nobody else does that. I can open a chan without being registered and enforce rules in there.
The only time I need to register something is when I want to keep the channel alive and still be OP when I come back, when I want to keep my nick or when the chan owner requires me to register.
SSH lacks a key distribution/certification model for server authentication.
The article describes server authentication (in the section with misleading title "SSH connections are encrypted") but does not mention the fact that fingerprint should be sent over another secure channel and manually verified.
In addition to the fact that openssh has supported certificate authentication of both servers and users for years -- the easiest way to bootstrap "traditional" ssh keys is probably just to list the public ssh host keys on a web page secured by https/tls.
It'll be just as insecure as the rest of the x509 CA-based cluster-fuck -- but at least it's easier to automate and less error prone than manually checking fingerprints.
So, not saying you're wrong, but that while advice regarding "fingerprints" is technically correct, just adding "the correct" keys to known hosts is probably the more practical -- and in practice more secure -- solution.
That is of course assuming that like the rest of the world setting up an actually secure solution using ssh-keygen seems like too much work (I'm myself guilty of this, for my personal servers it's easier to just stick with manual keys - it's also hopelessly insecure and inconvenient in the case of a breach or other reason to rotate keys).
"It doesn't work because you generated your key with RSA instead of moduli-2048" is not a conversation I want to have with my mother. Until the tools to deal with SSH keys are a lot more user friendly, it won't be used much by the wider public.
performance. sshfs is dog slow compared to NFS on a local network.
Also, coherence: sshfs manages to hide a lot of the ugly details, but you'll meet coherence problems on sshfs much more often than on nfs. They both do aggressive caching, but nfs gets help from the server side and is thus usually better.
Both good reasons. My personal use case happens to make these issues unimportant: mounting remote file stores that are only accessed by me. But I guess for mulitply-accessed files on the local network, nfs headaches may be worth the trouble.
I'd started using ssfs for something and found this slowness issue. I asked my mentor about what could be done to improve it, and he said "If you're using sshfs, you've already lost".
'scp' is very slow as well. Anything bigger than a small text file gets rsync'd. Small text files get scp'd, because remembering rsync flags is a minor annoyance :)
If anyone is interested seeing another interesting service, our organization is currently developing user onboarding over SSH (WIP). All sources are public [1] and easy to follow/read. It's written in nodejs and has nice blessed/blessed-contrib based UI.
The hashbang people are doing a LOT of interesting things. What's nice is that they aren't waiting to get the whole internet onboard with their ideas, they are building the services now.
The best part is that (theoretically), you could install their software on a machine of your own and it would then be capable of providing services to their users.
If you look around there are cases of using ssh for various things, but at the end of the day HTTP is the protocol of the masses, you aren't going to beat it's adoption.
I added SSH authentication to the roadmap for the API in one of my projects. I love the UX of the first connection from a new users acting as registration.
When I looked for information on how git SSH servers are implemented I did not find enough information to get started.
Can anyone recommended reading for someone getting started with an API over SSH?
I looked at it a while ago using OpenSSH's AuthorizedKeysCommand feature and found Phabricator's implementation for vcs over SSH to be the most understandable thing I could find.
Why aren't we using ipv6 with ipsec for everything? Then we could just stick with rsh, telnet and http...
I honestly think that the time has come to turn back the clock, and move forward with that approach. We've time and time again proved that "mostly encrypted" is almost impossible to get right, and almost never what we really want. We've also shown that we really do care about authenticating the servers we communicate with.
With the recent advances in cpu power, ram (and custom hardware) -- there's not much reason not just encrypt and authenticate all the things any more.
In the 90s, doing full ipsec and ipv6 everywhere was expensive: new switches and network hardware was needed, and the overhead of encryption was way too high.
But now the time should be right. Still not all that hopeful that we'll actually get there, though.
I ask because I hacked up something a couple years back to let me manage files in ~/.ssh/config.d, plus a Makefile that produced ~/.ssh/config from them and a set of shims for OpenSSH commands which would run make before running ssh, scp, etc., to make sure the live config stayed up to date with changes in .d files. But I haven't used that pile of shell scripts or looked at it in a while, so it's probably started to smell a bit, and it would therefore be nice if this were a thing OpenSSH itself can now do.
Sadly, we don't even invent new protocols any more, at least not open ones. What we do is invent new, closed platforms like Slack (and HipChat and Campfire before it).
Besides the obvious hype and hipster “this time its different” appeal, is there any technical reason one would would prefer Slack over, say, XMPP? I looked into it only until I realized one has to pay to access chat history.
Slack gives you a unified chat stream and a simple, buttery-smooth onboarding process for the tech-naifs. Jabber does neither of these. I'm not fond of Slack in particular, as it's ridiculously expensive and the main chat window is too widely spaced, even with mods.
I use jabber with a friend, and frequently messages go to his other laptop, which he doesn't see until he logs onto it. Same in reverse. Similarly, history isn't unified. You can get around these problems by having your own centralised jabber chat client (like bitlbee), but that's a technician's answer, not an answer for the general public.
And >90% of the cases detailed here are covered by an IRC server with TLS and certificate authentication, and you can even use it on a mobile device with the kind of humane, task-focused UI that a general-purpose SSH client can't provide.
It's great if you can leverage the SSH keying system, but using SSH "raw" for anything high-bandwidth is a disaster (try using sshfs on a high latency network, you will get two digit kilobytes when you know the network connection can sustain a megabyte)
SSH chat does not ensure that "I know who you claim to be". Only that "I know you're someone who has access to the same SSH key as that someone with whom I was talking yesterday".
In terms of authentication, that is about on par with an IRC "nickbot".
There's nothing preventing you from transporting an SSH public key over some other secured channel. Then it's "I know that you are someone that has access to the SSH key transported over that secure channel".
round trip times. it makes somethings impossible with that much interchange required to send anything - and it will never go away because the speed of light is a hard limit.
We're not using it because... well... it's weird (for lack of a better word)? Sure, it's a multiplexing protocol that can support a few neat use cases like port forwarding and X11 tunneling, but that's really not what we want in most cases. It carries a lot of baggage in its clients and implementations that in principle shouldn't cause problems but in practice makes it suboptimal.
One of the most important aspects of why we don't use it: it's scary to work with. SSH's implementation of its protocol is much closer to the actual client implementation than the divide traditionally maintained between SSL and its clients. People are rightly afraid to get close to cryptographic code without sufficient training, and so there is the equivalent of a "If You Are Responsible: Keep Away" sign for most developers who might be inclined to improve the situation.
Still, the community found the impetus to augment the protocol and UI to help deal with latency issues that plague SSH via Mosh. It helps escape the legacy idea that RTTs will be consistent and therefore are ignorable in a shell implementation.
Ultimately, SSL is a better understood tunneling protocol and full of a lot less... maybe it's just the perspective we have in a world where SSL is ubiquitous but SSH is weird. Its rules are weird, its certificates are weird, its tooling is weird.
This is a common contention in Hacker News I'm often on the minority size of, but I submit that while syntactic interfaces (shell, programming) has clearly demonstrated its value and deserves to be better developed, the same can not be said for serial text entry interfaces. Something based around a streaming query protocol like SSL+HTTP/2 that makes some fundamentally different decisions than the legacy UNIX shell and supporting tooling would be substantially better, and be able to use existing web browser techniques and software.
Which is all abstract, but imagine for a moment something we've seen before: an Electron Shell based terminal. But what we haven't seen is someone really dive in and attempt to redefine the world around shells. So bear with me for a second...
Imagine an Electron Shell based terminal experience that works locally and remotely. A line buffer separate from the display accumulates and maintains the current prompt (because instead of PS1 being pseudo-executable in our shell it actually can attach scripting functions and web-browser style timers).
Executables logically return open dictionary objects (which can contain streams) instead of the current fixed set of indexed streams. We can use 0, 1 and 2 as legacy keys into these objects to maintain compatibility. But you could imagine a "rich-1" key that actually outputs rich markup, "error-1" that outputs rich markup for error, etc. And of course, media itself could either be file system references. These rich objects are just textual objects with references to valid HTTP/2 requests do what they do.
This actually resembles SSH's protocol on the outside, but using tools that are reusable elsewhere and a cryptographic stack and transit protocol that has more funding and attention and traction.
Yes. I would suggest anybody who poses the question "why not" to try to actually implement SSH from the scratch! I've looked at some "smaller" implementations than OpenSSH and they are still, like you say, "weird."
SSH appeared to me to be an implementation of the console application that got crypto and network code bolted on, everything kept together almost with the Sellotape. And it doesn't change when somebody has to re-implement it as most of the "features" have to exist for a thing to work.
However, there are also some advantages in using SSH for some purposes: for somebody who knows what he does, just the key management is actually less weird than the whole SSL thing. The tunneling is also very convenient and I like it.
No. Disregarding technicalities of which there are many, the most important difference is that with ssh you either get the host key through a different secure channel or "trust on first use" (TOFU). With HTTPS you trust certificate authorities (CA).
I was referring to the browser side certificate that can be generated using the <keygen> tag, and then used for the subsequent HTTPS sessions. Would this be equivalent to ssh-keygen for SSH?
That's deprecated though and afaik, that's only the client-side authentication, not the server-side. That still relies on CAs, with all the disadvantages.
I just deployed the latest Github release on an east-coast server here, please come help test it:
Binary releases are available here if you're interested in running your own: https://github.com/shazow/ssh-chat/releases/