（评论）

（评论）
(comments)

原始链接: https://news.ycombinator.com/item?id=40998158

作者描述了他们使用 Raspberry Pi 和 Termux 创建的自定义聊天系统。他们将其比作简化的互联网中继聊天 (IRC)，用户通过“wall”命令进行通信。该聊天系统的理想改进版本将采用去中心化哈希表（DHT）技术，从而允许参与者之间实现无缝的点对点连接。为了确保安全，每个参与者的公钥指纹作为网络中的唯一标识符。其他用户的批准是通过数字签名授予的，用户可以自由选择完全公开或选择性批准的连接。此外，作者还提到了这一概念与流行的去中心化平台 Mastodon 之间的联系，表明由于在线审查制度的加强而存在潜在的增长。然而，挑战在于鼓励大规模采用，要求设置简单且透明，以避免习惯于集中式技术的用户不知所措。进一步的讨论涉及去中心化服务面临的挑战，包括增加的复杂性和用户期望调整。安全问题主要围绕潜在的攻击媒介，例如尝试在客户端内执行恶意命令，特别是在使用 Golang 二进制文件的情况下。最后，作者分享了设置无密码 SSH 帐户的相关经验，强调了正确配置以防止不必要的入侵的重要性。此外，他们还讨论了使用 SSH 进行聊天，并提到了 IP 地址和公钥等元数据的潜在暴露。

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.

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.

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:

  command="/usr/bin/foo" ssh-ed25519 AAAA....

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`).

ref: https://pico.sh/irc

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)

PKI, with I in bold quotation marks.

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.

You may not want the chat server owner to know which public ssh key you are using for privacy reasons.

Workaround: Specify another ssh keypair

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?

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-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.

> Turns out you can just run any old program.

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.

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.

The readability might be nice, but the way files are structured makes no sense to me.

In PHP/Typescript there’s always a direct correspondence between imports and file locations, but Go baffles me.

As a gentle reminder, if you are forwarding your ssh-agent by default, you should connect with:

    ssh -o 'ForwardAgent no' $host

So your secure identities are not exposed to a random ssh server ...

Is this working for anybody else?

I created a throwaway ed25519 key, reconfigured ssh config, and tried to connect with ‘ssh chat’

Nothing loads. ‘ssh -v chat’ isn’t helpful either. ping and nc (on both 22 and 443) show the server (or load balancer) is accessible for me.

Maybe a “hnfp DoS” (hacker news front page DoS)?

Looks like ascii colors aren't being filtered correctly.. which is a pretty big issue. White on white isn't very readable... :-)

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

ssh: connect to host devzat.hackclub.com port 22: Connection refused

PORT STATE SERVICE

22/tcp closed ssh

Nmap done: 1 IP address (1 host up) scanned in 1.18 seconds

----

overloaded?

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.

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

Normal talk in unices system can do that.

Irc have exange data between server and minimalize data trafic.

still irc is better, but meybe in future

（评论） (comments)

（评论）
(comments)