Telnet Mapscii.me | Hacker News Reader

Telnet Mapscii.me

mapscii.me

103 pointsdTal25 comments

Open articleView on HN

And shame on HN for claiming that telnet://mapscii.me is not a valid URL!

The URL "telnet://mapscii.me" is definitely a valid URL and it should be corrected please.

Ironically, the string "mapscii.me", which it accepted, is not a valid URL, as it lacks a protocol.

I do something very similar in ROSshow for NavSatFix (GPS) messages: https://github.com/dheera/rosshow

https://github.com/dheera/rosshow/raw/master/screenshot3.png...

It also has a pure ASCII mode:

https://github.com/dheera/rosshow/raw/master/screenshot3-asc...

Unfortunately this utility isn't really usable outside of the context of robotics and ROS but one could extract the map rendering functionality and create a separate utility out if it if they wished.

The main difference in approach between this and Mapscii is that I actually just convert raster map tiles from OSM instead of using the vector data.

I used to work on some telnet based "campus wide information services" in the previous century. I know we had a special hardened shell someone at academic computing wrote for our BSDi boxes.

nowadays, with the "https everywhere" movement -- would it make more sense to do anonymous user terminal access over ssh somehow?

SSHing into an untrusted box is - sadly - a security minefield. Some trip hazards include:

-Unless specifically instructed not to, ssh will send all key fingerprints to the server

-ssh sends a string describing the exact version of SSH and operating system you’re running, and this behavior can't be changed

-If the client has taken the unwise but plausibly lazy step of wildcard-enabling ssh agent forwarding, the server can masquerade as the client and log into any servers they have keys for

-If the client has X11 forwarding set up by default, the server can sniff the client's keystrokes (among a great many other things)

Haven't heard of the first one before - when you say "all key fingerprints to the server" do you mean the public client key or the public key of the host it's expecting or something else completely?

2 is true is https and most other protocols without concern. The problem usually comes to running an old version not telling the other side you're running an old version.

3/4 seem to only be true if you go and misconfigure settings from defaults, which is true for nearly everything.

I'd be curious what the risk of 1 really comes down to because other than that I'm not seeing anything to be worried about if you know you're connecting to an untrustworthy box.

1 is necessary for ssh keys to work: unless configured otherwise, the client has to send the public key for every private key to the server so the server can determine whether any of the keys is trusted. (a) this isn’t a security issue, but it might be a privacy issue. (b) you can configure ssh to use a specific private key if this really is unacceptable.

I don't think ssh provides the same level of confidence as https, unfortunately. There are no root CAs that are agreed upon, so the users are too used to blindly accepting whatever server keys they are given. This makes MITM attacks too easy.

SSH supports certificates (and they aren't X.509 certificates; they're simple and purpose-built for SSH) which resolves the MITM problem in both directions. It's what organizations who manage large numbers of servers use already (in particular, certificates make it easy to tie logins to SSO systems, and to keep people from holding on to long-lived SSH keys). They're great, and you should check them out.

The very last thing in the world you should do is adopt something like SSHFP, a clangorous hack that ties your SSH service to a root of trust operated by a state actor.

certificate pinning gives me more trust than letsencrypt as a root ca for most of my use cases . except for the agent forwarding protocol and that you cannot secure opensshs socks proxy i am actually quite happy with SSH given its applications . i do not like the plutocratic aspect behind the current www consensus on protocols. Having said that: thanks for using telnet. This is great fun.

DNSSEC + SSHFP is a simple, scalable, accessible solution.

Root CAs are just a bit of a bummer; I hope to be a part of the transition away from them.

I didn't know about SSHFP, thanks for informing me. DNSSEC has always felt cumbersome to set up, so I've stayed away from it. Might give it another try.

I'm disturbed this runs on Javascript, and impressed it runs so smoothly in my terminal.

Props on the Github project page for breaking down all the libraries that helped achieve this.

And props to OpenStreetMap for making this data available.

Ditto. Cool project, but when I saw it was written in JS, a wave of disgust washed over me.

If you think that's neat, go watch Telnet Star Wars :)

Previous discussion: https://news.ycombinator.com/item?id=27042629

MapSCII is really a cool project.

I like how the demo points to the c-base.

I visited a couple of years ago and that "library" really needs an updating. :P

I'm not just ribbing, I would be happy to make donations.

Source: https://github.com/rastapasta/mapscii

That's where the link redirects.

I would be willing to bet that, 3 years from now, only the GitHub link will be valid.

Very, very few things really impress me.

This really, really impresses me.

This could really use an instruction page on 'h' and/or '?'. Without going to the website I couldn't figure out how to zoom.

I'm amazed at that sending mouse movement and buttons over telnet works. I guess there's some xterm extensions that allow that now?

this is genius

Reply on news.ycombinator.com