Client/server telnet text editor?

'Password less ssh' ... could mean using keys, where you generate a public and private ssh key and share (upload) the public one with the server you want to access, so you're subsequently pre-validated and don't have to enter a password; Or if you want to provide a server ssh service that anyone can access then what I've done is set up a password less userid inside a container (restricted environment) and turn off both password and key authentication for ssh. So anyone just ssh'ing to that is automatically logged in. I've set that users shell to be a self written limited-shell, that basically loops around prompting for a command, and then a case statement that runs any commands that are valid (included). Provided you avoid any commands/programs that can invoke a shell then that's acceptable.

The ssh redditbox.us link I previously posted is such a example of a password less setup. For keys based password less ssh there's a ton of info out there of how to set that up.

If you happen to be online when I'm also online (desktop active), try for instance

Code: 
ssh ssh@ssh.dnsfree.com 'mp3test' >my.mp3
or
Code: 
ssh ssh@ssh.dnsfree.com 'mp3test' | mpv -
or
just access it
Code: 
ssh ssh@ssh.dnsfree.com
and run 'menu' and then something like gauge ... to see a example gauge dialog
 
Last edited:
http protocol adoption/expansion has predominately been funded by advertisers. Largely "free" for users in the sense payment is personal profile data. https secures the end to end traffic once the http initial connection completes. But your ISP can see all of those initial open http connections, one for every site you visit using http(s), so they know exactly where you've been. Given a encrypted text (https traffic) and knowing where that came from and visit that web site and you'll likely get a indication if not exact replica of the unencrypted content that was conveyed (many front end/initial web pages are largely static in nature). In cryptology given the encrypted and unencrypted messages, figuring out the key can be trivial.

IMO ssh is better at providing a degree of privacy from your ISP (who likely will be under (single) state directorate/control). You can ssh into one box/server, and then ssh out of that to another ssh server ... et cetera. Your ISP only gets to see the first connection establishment, can't see where you may have ssh'd to from there. And those ssh 'hops' can be within different state jurisdictions.

Whilst you can do gui (X) through ssh, mostly its textual, more in keeping with the original Unix philosophy. Which is easier for hard of hearing/sight, less exposed to advertisers, and generally a better choice for privacy. Some even use dial up to gain access to the broader net and from most places you can pretty much dial up anywhere globally.

telnet and ftp have been superseded by ssh and sftp (scp), mostly for the end to end encryption benefits.

In the event of a swell of people using alternatives to advert ridden http(s) (some might say google owned), such as ssh, then the likes of gopher for searching could also revive. But in the event of such a swell likely google would jump in looking to command gopher as well.
 
I believe your statement about HTTP->HTTPS and "figuring out the key can be trivial" is bit paranoid. Even though most sites might be static, you can't know for sure and even if you know for sure, it sure is not trivial to figure out the private key based on this kind of traffic.
 
Indeed for https, its key/methodology does make it very difficult. Having visibility of the public key, unencrypted and encrypted ... and it still takes massive process time to potentially deduce private key possibilities. That's why its been widely adopted. But does reduce down the process times when you have all three. Whether man-in-middle or other attack vectors could further scale down times ??? Commonality is a weakness (such as a single ISP seeing all). Diversification such as your ISP seeing just a single connection (ssh from your PC to a server and then onwards to other servers from that server with the data/content flowing though that single encrypted channel) reduces one concentration risk (ISP/single state), but in turn does introduce other risks (trust in other ssh servers).

Still, would be nice to have a alternative ssh based (rather than https based) browser (and more widespread adoption) IMO. Sites that accept open ssh connections and feed back content (videos, sounds, images, text ...etc.) via the ssh protocol. Perhaps with hard of sight/hearing more in mind and less accepting to advertising. But as I suggested earlier, if that were to take off then I suspect it also would fall foul of commercialism.
 
If you enter "https://" in front of the URL, nothing is ever in plain HTTP. To me your last two posts sound a bit overly paranoia.
 
https requires handshaking to be performed before encryption can be used. That handshaking has to occur for each unique site visited, of which a single page can link to many others. That handshaking process occurs in open (non encrypted) format.
 
rufwoof said:
https requires handshaking to be performed before encryption can be used. That handshaking has to occur for each unique site visited, of which a single page can link to many others. That handshaking process occurs in open (non encrypted) format.
Click to expand...

Please read here about the initial key negotiation used in HTTPS and other encryption protocols:

https://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange

It's not a bulletproof way of negotiating the initial encryption key but assuming the method is used properly (large enough primes, 2048 bits recommended) it's resistant to most attacks, even to goverment agency level players.
 
kpedersen said:
I see you point but still don't entirely agree. Just because I am a "techie" and they are a "casual user", doesn't mean that they should be allowed to use the incorrect tool for the job or a shortcut.
Click to expand...

It is not your problem or business. They are adult and free to choose.
 
Spartrekus said:
It is not your problem or business. They are adult and free to choose.
Click to expand...
It isn't my problem *until* I have to babysit them. People like this is the reason why I still have to keep around a "legal" copy of Windows XP and Office 2007 on an old broken laptop ;)

Plus if they were free to choose, we would still be using Adobe Flash for business critical applications XD
 
kpedersen said:
It isn't my problem *until* I have to babysit them. People like this is the reason why I still have to keep around a "legal" copy of Windows XP and Office 2007 on an old broken laptop ;)

Plus if they were free to choose, we would still be using Adobe Flash for business critical applications XD
Click to expand...

It is their problem. They made their own mature decisions to use whatever operating systems, according to their personal needs and experiences. Even if it is XP,... or (M$) Microsoft Windows 10, with all default enabled spying tools, designed by M$.
 
tommiie said:
If you enter "https://" in front of the URL, nothing is ever in plain HTTP. To me your last two posts sound a bit overly paranoia.
Click to expand...
https://news.netcraft.com/archives/...rvers-vulnerable-to-trivial-mitm-attacks.html 95% of https servers vulnerable to trivial MITM attacks

Other methods such as traffic analysis can be revealing. Even if the content is encrypted there's the google search a user might have made, the dns lookups that subsequently occurred, and the amount of data flowing in from one point, and out at the users location. Where in many cases the content might be deduced as many web pages are largely static.
 
You must log in or register to reply here.
Back
Top