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