# Client/server telnet text editor?



## Spartrekus (Mar 27, 2019)

Hello,

Would you have ever heard of a client/server telnet text editor ? 

Since terminal and telnet has been used, this software for the console/terminal might be surely existing.   

With best regards,
Sp.


----------



## SirDice (Mar 27, 2019)

Spartrekus said:


> Would you have ever heard of a client/server telnet text editor ?


Simple question, why? What's the point? 



Spartrekus said:


> Since terminal and telnet has been used, this software for the console/terminal might be surely existing.


What issue/problem would this solve? Almost all applications are born out of some sort of necessity. What's the need that would warrant the existence of such an application that can't be solved with existing tools?


----------



## D-FENS (Mar 27, 2019)

What do you mean with "telnet text editor"? There is a console text editor and telnet provides you with a console. So you can run any console text editor in telnet - vi, nano, ee, emacs or whatever you prefer.
I have not heard recently anyone using telnet for anything else than testing TCP connections. It's completely unencrypted and it should be used at most on the localhost interface.


----------



## Spartrekus (Mar 27, 2019)

1) Run a server to edit a text file.

2) clients use the old good telnet to connect and work on same doc.

In 1969 was dev of telnet. It might be quite a good number of years, so it must exist.


----------



## SirDice (Mar 27, 2019)

1) Sorry? Why would I need to run a server to edit a text file?
2) Telnet has been deprecated a long time ago due to its inherent insecurity. Barely anybody uses it nowadays. 



Spartrekus said:


> In 1969 was dev of telnet. It might be quite a good number of years, so it must exist.


So, after 50 years it still doesn't exist. Don't you think that's a clue your "solution" might be wrong? Do you really think you can do better than 50 years worth of the world's brightest and most innovative people coming up with ideas?


----------



## Spartrekus (Mar 27, 2019)

SirDice said:


> 1) Sorry? Why would I need to run a server to edit a text file?
> 2) Telnet has been deprecated a long time ago due to its inherent insecurity. Barely anybody uses it nowadays.
> 
> 
> So, after 50 years it still doesn't exist. Don't you think that's a clue your "solution" might be wrong? Do you really think you can do better than 50 years worth of the world's brightest and most innovative people coming up with ideas?



who care about security?

There are computer scientists, not only web developers.


----------



## SirDice (Mar 27, 2019)

Spartrekus said:


> who care about security?


The whole world, except you apparently.


----------



## D-FENS (Mar 27, 2019)

Spartrekus said:


> 1) Run a server to edit a text file.
> 
> 2) clients use the old good telnet to connect and work on same doc.
> 
> In 1969 was dev of telnet. It might be quite a good number of years, so it must exist.


There are far superior tools for working on a common text file than telnetting and editing a file on the server. Just use git, subversion or any other version control system. It will help you merge and resolve conflicts instead of overwriting each other's work without history log.


----------



## D-FENS (Mar 27, 2019)

SirDice said:


> 2) Telnet has been deprecated a long time ago due to its inherent insecurity. Barely anybody uses it nowadays.


As remote shell - no. But it's great for testing out server sockets and protocols. I use it mostly to validate that a specific server is accessible and the firewall does not block it.


----------



## shkhln (Mar 27, 2019)

roccobaroccoSC said:


> Just use git



Spartrekus actually refuses to use git.


----------



## Spartrekus (Mar 27, 2019)

shkhln said:


> Spartrekus actually refuses to use git.


I install only what is not needing too much dependencies or that is not touching user data privacy and spying tool/machines, such as Cloud Microsoft, Apple, Facebook, Google... Subversion for instance is better.
Support *Free* Opensource, just use free opensource.




roccobaroccoSC said:


> There are far superior tools for working on a common text file than telnetting and editing a file on the server. Just use git, subversion or any other version control system. It will help you merge and resolve conflicts instead of overwriting each other's work without history log.


Who care about GIT? This is for developers.


----------



## Spartrekus (Mar 27, 2019)

SirDice said:


> The whole world, except you apparently.


You are wrong. Telnet still exists, like Unix does.

There are many people still using telnet for large non-public research and computer sciences, behind highly secured network infrastructure(s). Those are usually very specific use, which can not be generalized to larger usage/public/audience.


----------



## rufwoof (Mar 27, 2019)

tmux is good for cli based collaboration. Multiple participants ssh into the same box and userid and one starts tmux, the others attach to that session. Open vi or whatever text editor you like and you can all type into the same document(s). Obviously some control is needed to avoid 'fighting' for control at the same time. You can detach and leave the session running, and later reattach again from the same or another location/device.

Public telnet is predominately just for old bbs's nowadays. Or for other 'fun' asci art type things such as telnet towel.blinkenlights.nl (Star Wars)


----------



## Spartrekus (Mar 27, 2019)

rufwoof said:


> tmux is good for cli based collaboration. Multiple participants ssh into the same box and userid and one starts tmux, the others attach to that session. Open vi or whatever text editor you like and you can all type into the same document(s). Obviously some control is needed to avoid 'fighting' for control at the same time. You can detach and leave the session running, and later reattach again from the same or another location/device.
> 
> Public telnet is predominately just for old bbs's nowadays. Or for other 'fun' asci art type things such as telnet towel.blinkenlights.nl (Star Wars)


vi cannot allow two clients simult. on a single buffer.


----------



## rufwoof (Mar 27, 2019)

Spartrekus said:


> vi cannot allow two clients simult. on a single buffer.


Log into a box and run tmux. You, or another, log into that same box and userid and run tmux attach

You both share the same tmux terminal session and either of you can open vi, type text in ... and the other can take over typing at any time.

Just tried it myself to confirm that's the case with vi.


----------



## Spartrekus (Mar 27, 2019)

rufwoof said:


> Log into a box and run tmux. You, or another, log into that same box and userid and run tmux attach
> 
> You both share the same tmux terminal session and either of you can open vi, type text in ... and the other can take over typing at any time.
> 
> Just tried it myself to confirm that's the case with vi.


Strange method, while network exists today. 
Try to type on line 1: and line 5000: at same time on same latex doc...


----------



## kpedersen (Mar 27, 2019)

Spartrekus said:


> vi cannot allow two clients simult. on a single buffer.


To be fair, I am more than fine with that. This kind of multi-user collaboration is a "cloud" gimmick and not actually that practical for real work.

For real work we have many VCS systems (i.e svn, git, cvs) available to merge text.


----------



## Spartrekus (Mar 27, 2019)

kpedersen said:


> To be fair, I am more than fine with that. This kind of multi-user collaboration is a "cloud" gimmick and not actually that practical for real work.
> 
> For real work we have many VCS systems (i.e svn, git, cvs) available to merge text.


In your world, but you may eventually see that people can have various jobs and computer usages for other areas.
Your world is your unique own world, your work, experiences and patterns.


----------



## rufwoof (Mar 27, 2019)

Spartrekus said:


> Strange method, while network exists today.
> Try to type on line 1: and line 5000: at same time on same latex doc...


Doesn't work that way, unless two of you were battling to enter text at the same time. In effect you're both using the exact same vi session so either keyboard can enter commands/text. If one is jumping to line 5000 whilst the other is entering text then you'd end up with a random outcome.


----------



## Spartrekus (Mar 28, 2019)

rufwoof said:


> Doesn't work that way, unless two of you were battling to enter text at the same time. In effect you're both using the exact same vi session so either keyboard can enter commands/text. If one is jumping to line 5000 whilst the other is entering text then you'd end up with a random outcome.


The program can calc where the cursor shall be, depending to type at same place.


----------



## tommiie (Mar 28, 2019)

shkhln said:


> Spartrekus actually refuses to use git.


Yet he does use git and github. He even has 600+ repositories so I would say, quite an avid user even.


----------



## kpedersen (Mar 28, 2019)

Spartrekus said:


> In your world, but you may eventually see that people can have various jobs and computer usages for other areas.
> Your world is your unique own world, your work, experiences and patterns.



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. This kind of thinking is why Windows went from being pretty decent (around Windows NT 4.0) to a weird on-line only consumption tablet OS (Windows 10.1809).

I.e I notice we have two kinds of academic writers at a Uni, the Microsoft Office guys and the LaTeX guys. Neither group would say they are computer techies... but the Microsoft Office guys are definitely the least productive. The LaTeX guys can merge correctly (i.e with the TortioiseSVN GUI) whereas the Office guys have to just flap around copying around work and manually merging it.


----------



## shkhln (Mar 28, 2019)

tommiie said:


> Yet he does use git and github. He even has 600+ repositories so I would say, quite an avid user even.



You didn't see all those "Add files via upload" commits, did you? Although, now that I think of it, they should also have verification label…


----------



## tommiie (Mar 28, 2019)

shkhln said:


> You didn't see all those "Add files via upload" commits, did you? Although, now that I think of it, they should also have verification label…


Indeed, I did not notice those commit messages.


----------



## SirDice (Mar 28, 2019)

roccobaroccoSC said:


> But it's great for testing out server sockets and protocols. I use it mostly to validate that a specific server is accessible and the firewall does not block it.


Use netcat(1)


----------



## rufwoof (Mar 29, 2019)

'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


```
ssh ssh@ssh.dnsfree.com 'mp3test' >my.mp3
```
or

```
ssh ssh@ssh.dnsfree.com 'mp3test' | mpv -
```
or
just access it

```
ssh ssh@ssh.dnsfree.com
```
and run 'menu' and then something like gauge ... to see a example gauge dialog


----------



## rufwoof (Mar 29, 2019)

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.


----------



## tommiie (Mar 29, 2019)

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.


----------



## rufwoof (Mar 29, 2019)

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.


----------



## tommiie (Mar 29, 2019)

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.


----------



## rufwoof (Mar 29, 2019)

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.


----------



## kpa (Mar 29, 2019)

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.



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.


----------



## Spartrekus (Mar 30, 2019)

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.



It is not your problem or business. They are adult and free to choose.


----------



## kpedersen (Mar 30, 2019)

Spartrekus said:


> It is not your problem or business. They are adult and free to choose.


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


----------



## Spartrekus (Mar 30, 2019)

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



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


----------



## rufwoof (Apr 4, 2019)

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.


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.


----------

