I have a Raspberry Pi running a read-only server where some friends and I have a "poor man's IRC" chat, in that we all log in from Termux and post messages to one another using `wall`. It's absolutely ridiculous and I love it.
Indeed, I wish there was something like it today with a modern design. Like a DHT with your public key fingerprint as a lookup. Anyone who 'follows' your .plan also hosts it as a torrent. You 'approve' followers by signing your .plan file with their pubkey, or for a fully public .plan, just sign with your private. Blah blah blah decentralized cypherpunk social media utopia.
Oh man, I've been working on this stuff for years. End users just don't care. Devs just reinvent the wheel in dumbass languages. The tech for this stuff has existed for 15 years, there's nothing to invent. It's ready now.
Thanks, I'll check these out. I have some hope that something like this could take off because of the popularity of Mastodon. I think the problem is that there has to be a major impetus for lots of people to switch, and it has to be completely brain dead stupid simple to set up, and to have it work fairly transparently so they don't feel like they're doing something completely new and different. Unfortunately decentralized services tend to add overhead, and user's expectations have been primed with centralized tech. We might see people care about stuff like this if we get more online censorship with government taking a closer look at tech lately.
An old, old Internet protocol that was used to get information on a user, and could be used by users to post updates from their .plan files. Essentially plaintext social media for people with Internet connections in the 80s and (early-ish) 90s.
Reimplementing it (well, the CLI program, `finger`) also happens to be the final exercise of Haskell Programming from First Principles, after 1200 pages of glorious buildup from the lambda calculus forward, in case that sells anyone on trying it ;)
I had that "oh crap, I'm old" moment when my initial reaction was "what? You've never heard of finger?!" and then I remembered I last used it in the late 90s.
I'm glad your reaction was to assist the young folks. :)
Or you can just run IRC client on start. Just trap SIGINT and SIGTSTP, run simple or modified client that cannot do exec or escape to shell and you are done :)
Or in the authorized_keys file, prepend the public key with a specified command. This is then the only command that the user can execute when logging in with that particular key. To wit:
Pretty neat! We implemented something similar with an IRC chat app (senpai) in our SSH app (pico.sh). After the user creates an account, it lets users connect to our public IRC bouncer with a single command (`ssh pico.sh -t chat`).
ssh-chat sort of inspired devzat. here's the story: I used to live in dubai at the time and for some odd dns reasons I could never actually join ssh-chat, but it acted as proof that ssh chats are possible, and so I decided to make my own version of it. then I moved to the us and was actually able to use both ssh-chat and devzat.
I'd be curious whether there's any security concerns on this one. Could an attacker craft a message that gets access to execute commands into a client terminal?
This is not sshd, this is a golang binary that uses the stdlib ssh lib. You would have to either a) figure out how to escape out of a golang binary, or b) if the go code executes shell commands with some user provided text, trying to shell inject something in there.
yup, not an extensive list, but further demonstrative:
- terminal emulators are not security hardened clients against malicious actors
- ssh lacks PKI and is inconvenient so users never do prekeying in practice, so it's TOFU / zero server assertion in most practical cases (i.e. easy to mitm)
- ssh channel features are a constant concern, for server resources and for client features like agents, agents are easy to disable
- most ssh implementations don't scale that well, it wasn't ever really a goal to do so
- there are few tools for auditing and monitoring, unlike the common protocols/services/clients
fun for toys, but i wouldn't put credit card details in there, unlike some streamers started doing lately.
ssh definitely supports PKI, it's just not the standard workflow for individuals
ssh-keygen (1):
ssh-keygen supports signing of keys to produce certificates that may be used for user or host authentication.
Certificates consist of a public key, some identity information, zero or more principal (user or host) names and
a set of options that are signed by a Certification Authority (CA) key. Clients or servers may then trust only
the CA key and verify its signature on a certificate rather than trusting many user/host keys. Note that
OpenSSH certificates are a different, and much simpler, format to the X.509 certificates used in ssl(8)
It's also worth knowing about SSH clients that can use X.509 certificate keys as normal pre-shared keys with any SSH server, like PuttyCAC and built-in for macOS High Sierra and later.
While it supports serial numbers, expiration dates and key revocation lists, it does not allow certificate chaining. That means whoever signs keys for end users has implicit access to the master key.
I'm not talking about supporting public key cryptography, I'm talking about having a specific and usable deployment of a PKI. The closest thing SSH has is SSHFP, which depends on DNSSEC, which is according to many opinions, DOA.
Yeah, though SSH is already very mature at processing text, so it's a surprisingly good fit for a chat. I would also remember that any machine you SSH from is going to give the server some metadata like IP address, public keys (which aren't useful as creds but can be for tracking). Really fun little project though
SSH might be, but maybe not your terminal. Which the very least can possibly trick you using escape codes. Also, unless my memory fails me 'cat'ing an untrusted file isn't recommended for security reasons.
I'm also interested. Setting up a passwordless SSH account for some public service sounds like a good way to give your machine away to North Korean hackers, because you forgot to set someting in /etc/sshd to "no".
Is there a usable description somewhere on how to do this safely?
I experimented with writing a shell replacement a while back. Turns out you can just run any old program. Here’s and example “hello world” shell replacement written in Go.
It’s amazing how simple some things are. Similarly, an HTTP server can also run any old binary in response to an incoming request. As long as it produces output that looks like an HTTP response, the client will receive that response.
but nginx or caddy can't run CGIs, they want scalability to the billions.
Disclaimer: I build a personal social web server https://seppo.social like that on top of shared (apache) hosting requiring no root privileges to install and run.
Or with a few lines of sh you can turn many cli tools to web services like https://qr.mro.name/
Or the person never expected more than a couple of hundred concurrent users and dimensioned the container or whatever after that.
I once wrote a similar chat, but much much worse in many ways, that could easily handle thousands of concurrent users, but hosted it on a 1mbit residential line. When Slashdot hit it I stood no chance.
I love stuff like this. I made a widget for MacOS where you can see incoming |hi messages sent to your Urbit, as a kind of poor man's p2p chat. But I didn't add a feature to send hi messages, so you still need a CLI for that.
Related: Does anyone by chance know how to configure an "anonymous" ssh account that always runs the same program? This would be great for making text mode games available to everyone without needing to support different platforms, now that windows actually ships with ssh.
THats the theory. However, AIUI, you need a machine that only does this single application. Because if you have a user without password, that can be an issue for many other services. SMTP for instance.
If you want to use my server, it might be a little more powerful than the current one. I would self host but to be honest I'd prefer helping out with the main instance. In case, I am here
what sort of server resource usage is this like right now as you are getting a ton of traffic?
also noticed that people were able to run commands but permission denied. that kinda freaked me out. eventually somebody is going to figure out how to escape the go binary
There was also `write` [0]. It would literally parse /etc/utmp [1] to find out which terminal the recepient user was logged on, then it would open that terminal and write(2) the message to it. Ah, wonderful user isolation.
I still use posix write [1] if there is an incident and i want to talk to the other admins that all try to fix sth. Quite fünf AS the younger ones are always Quote puzzled and feel caught...
