Hacker News Reader

Comment by camgunz | Hacker News Reader

I love Charm; doing `ssh git.charm.sh` is a lot of fun and really sparks the imagination about SSH apps. They also have usable solutions for auth and storage, which like, if you're thinking of writing something like this are the first things you'd start reaching for. They also work hard to enable you to run all your own services, so you don't rely on the Charm cloud for everything. Definitely a good model for future punk projects IMO.

View on HN

The dynamic intuitive interface provided by `ssh git.charm.sh` is a wonderful example of how text-based user interfaces do not need to be limited to REPL. I wonder if there is space for a new text-based web browser that adopts some of the design features showcased by Charm.

It surely is impressively well made. I am wondering though whether Charm actually qualifies as a text-based interface. Isn't it more like a replication of a graphical user interface, with windows and tabs etc.? If one's issues with working on the command line has always been that there are no "drawn" windows GUI elements, then this of course is a revelation, but we already have high-res versions of Charm, i.e. modern windows-based OSs.

There is no doubt, is a text based interface. The common term is text user interface (TUI vs GUI), and every app rendered as characters in a shell have been always considered TUI, whether they had windows, tabs, dropdowns and whatnot

OK. Then I probably should have asked whether there is anything gained by "drawing" a GUI with characters. Don't get me wrong, I spend most of my day on the command line. But I never thought "this would be so much better if it was more like windows / mac os".

I do think so. Terminal applications tend to be really accessible.

You said accessible, so would you expect terminal applications to work with screen readers for example? What about localisation?

I did not mean that kind of accessible. I mean easy to get, easy to install, easy to manage, easy to distribute.

apologies then! i dont understand how a tui app is necessarily get-able or installable or distributable. system package managers are more than capable of managing GUI apps, and a GUI can be distributed by uploading a zip to gh releases, just as a TUI app can be.

> would you expect terminal applications to work with screen readers for example

Can you explain to me any way in which they might not, bearing in mind they're basically text.

It's not automatic, any sufficiently complex interface will need to offer some kind of support. E.g. if your widget library offer dialogs, using e.g. ncurses, then TAB shouldn't allow you to flow out of such dialog. If you render graphic elements with special characters (dots, dashes or unusual glyphs), you would need to offer some hints to the screen reader to skip or identify differently that stuff. Just "read them out loud because is text" wouldn't work. It's been a long time since my last complex TUI so I don't know what's there today for accessibility

I did a quick Google for examples, and found this comment [0] on HN which gives some examples.

It being "basically text" doesn't matter; a pdf can be mostly just text but that doesn't mean in any shape or form that it's searchable.

[0] https://news.ycombinator.com/item?id=17683719

> I wonder if there is space for a new text-based web browser that adopts some of the design features showcased by Charm

Not sure if you're aware, but older protocols are still around to be used for this use case, and Gopher has even had a bit of a resurgence as of late

A Gemini client might benefit:

https://gemini.circumlunar.space/

Not using Charm, but I've designed a TUI Gemini client in Go! It's pretty popular, for terminal clients at least.

https://github.com/makeworld-the-better-one/amfora

I miss a search function, but thanks for your client. I may write one a la av98, but with jimtcl instead of Python3. It makes really easy to write networked stuff, either with TLS or not. I wrote a finger client in minutes.

Aren't Gemini pages static-by-design? It would be hard to do something really interactive / state-preserving with them if I'm not mistaken.

Looks cool! Are there any security risks posed by ssh'ing into an unknown server?

By default, you are probably uniquely identifiable: the SSH client sends your public keys, and sites like GitHub and GitLab publish the public keys for each account too. Someone made a demonstration SSH server a few years back that would greet you by GitHub username based on this, but I can’t immediately find it.

If you don’t specify a username, your local account name will be used and thereby disclosed.

Much more seriously, if you have the ForwardAgent option enabled, the remote server can impersonate you, using your SSH agent to log into any remote server. Don’t enable ForwardAgent globally, despite its convenience, unless you have an agent that requires manual action for every action; and be exceedingly leery of using it even on trusted servers, lest the compromise of one machine allow the compromise of everything. Consider ProxyJump instead.

I think this is sufficient regardless of configuration (but don’t trust me to be correct, I haven’t verified the actual traffic or anything):

  ssh -a -o PubkeyAuthentication=no nobody@git.charm.sh

It’ll prompt you for a password, just press Enter, it’ll accept it.

Now of course using this will make you comparatively fingerprintable (though not identifiable) unless enough other people do it too. But then, they have your IP address, so—

If you want to skip the host key stuff, you can add `-o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no`, though it’ll emit a warning about adding the host key to the known hosts file every time.

    ssh whoami.filippo.io

Ah, good, thanks. Unfortunately, whoami.filippo.io is not resolving.

https://words.filippo.io/ssh-whoami-filippo-io/ and https://github.com/FiloSottile/whoami.filippo.io are useful. It suggests also adding the option IdentitiesOnly yes.

Or just add a VM or user which specifically is used for such, and then destroyed. (By default, they still have your username and IP address, unless you take additional steps to obfuscate such)

You potentially send all your key IDs (ie public keys) your agent has. there are command line options to force your ssh not to use your agent in which case, barred any bugs in the ssh client, it’s like browsing to a domain in your browser.

This is the first time I’ve heard someone say sharing public keys is a security risk. Can you explain the threat model here?

I think it’s more of a privacy leak. E.g., the service could potentially figure out who you are if your public keys are tied to some other service, like GitHub.

If you ever manage to leak a private key it’s easier to track it back to you. There was a recent paper showing the ability to tie rather a lot of keys to the associated developers.

Would be easy to contact other web services and determine the identity marching a public key.

Regarding the concept in general, since it's just a screen with i/o you can't inspect its client-side code (the UI) nor what it does with your user input - but that can be more of a benefit for infosec reasons if you were to deploy this as an alternative to something like browser isolation[0] where you simply see what a remote browser sees without being able to inspect the contents of the page nor inject code.

0: https://www.cloudflare.com/teams/browser-isolation/

You are probably using terminal software that has memory corruption bugs trivially exploitable by the remote end.

Also these https://marc.info/?l=bugtraq&m=104612710031920&w=2

It really does. I wonder if these SSH applications can be linked and used like web applications where it's delivered to the end-user over the network with terminal + SSH being used as a browser. The only problem for these applications (and Charmbracelet) would be that there isn't much audience that could use these.

Good point on the small target audience.. It really is a shame because this is a great looking project.

I think I should write a web app that handles the SHH connection on the backend and renders the SHH app into HTML so that they can be enjoyed by the masses.

If you do this, please mention that using a proper terminal + ssh will work better(This is based on my understanding of technologies used, but I could be wrong), and you may be responsible for a lot of people taking their first steps into knowing computers a lot better!

ttyd is a nice little web terminal: https://github.com/tsl0922/ttyd Just a small, fast, low fuss C-based executable.

wetty is another good option if you want to run a nodejs server: https://github.com/butlerx/wetty

Both use xterm.js for the client terminal, which is these days the only game in town for a web terminal (it's what VS code and many other electron apps use too). It's quite good.

Do be aware though that running a web-accessible terminal is a huge security headache. You're opening up a websocket to effectively allow commands and code to run on your server. Pay attention to security and authentication options any web terminal gives you, and use them. Most are not very secure out of the box or just following their readme examples.

And watch out as many rootkits use web terminals as payloads so smart organizations and security policies will be looking for them or their traffic and you might get a very concerned IT person asking you questions if you use these on a network or machine you don't control.

Reply on news.ycombinator.com