Remote Support (aka Teamviewer Replacement)
- Vous devez vous identifier ou créer un compte pour écrire des commentaires
Is there such an alternative that is solely free software ? I've made a quick research and couldn't find anything.
VNC can be used to access remote desktops. I use x11vnc and ssh. (I
haven't ever used Teamviewer, so I'm not completely sure if it's what it
does.)
Thanks a lot !
I am a member!
Yes- although the free solutions aren't as easy to setup. VNC and similar applications are very commonly used for remote desktop. You do have to manually setup your router to do port forwarding unfortunately.
This is a search I was on for a little while because someone in the office requested TeamViewer. Luckily I have control over the network infrastructure so I can make VNC be a viable solution within the organisation, but otherwise it isn't quite a drop in replacement. I wonder why no one has made it a priority project to duplicate that functionality.
I am a member!
It would be great if there was a solution to this problem. If there was software written for it there would need to be a server in the middle. That could then be charged for as a service and fund the project. If users don't want to pay they could always install the software themselves on there own server.
I would certainly make a financial contribution to anybody working on solving the problem. If there is a solution to the problem and one needs to setup a server for it to work I'd be interested in that as well. I'd probably setup a server for anyone to use (if its feasible security wise, etc, and if not we could probably do a free instance of Amazons cloud). Just let me know.
It would be easy to implement such a remote support software which would make it impossible for server owner ( you ) to spy on traffic or gain remote control over a client. Simply have both sides generate and exchange public keys and then encrypt packets with them. I could write such a program, if someone didn't already do it.
To clarify, I was thinking of encrypting a password with public key and sending it back. On second thought, SRP is maybe better idea.
> Simply have both sides generate and
> exchange public keys and then encrypt packets with them.
This is where all the difficulty in cryptographic protocols starts: why
wouldn't the server be able to change the key? The way SSH handles this
might be practical for this purpose.
Since reading about
http://en.wikipedia.org/wiki/Interactive_Connectivity_Establishment I
think it's not the only interesting part in this project.
I knew someone would ask. This is how I pictured it at that moment:
Jim tells Bob: "Ok bob I'm gonna give you remote support. Encrypted password is doughnut. Start up the program"
Bob: "Ok Jim, here I go" ***bob starts the program*** ./ReMoteSupport doughnut. Bobs' ReMoteSupport sends public key expecting that response from Jim will be string "doughnut" encrypted with his public key. If its not Bob sues Chris :)
SSH does nearly the same, with keys used once per machine. "Password"
isn't imo a good word for this: they should be random, not
user-generated.
The most obvious way to implement such encrypted passwords allows the
data to be decoded later when the attacker (i.e. server operator) gets
one of the private keys. (There are special key exchange protocols that
solve this problem.)
What I think we should do:
1. use existing protocols for all things involving cryptography or
sending the data; SSH has well-known solutions for authentication
2. maybe use a custom protocol for requesting access and getting VNC
server addresses (SIP solves a similar problem). Or maybe use
existing IM protocols or email for it?
3. make hosting servers for it as easy as possible, maybe just require a
TURN server (that users interested in federated VoIP will already
have) and maybe a simple service for 2. There already are solutions
hosted by others.
4. have less options than VNC has.
Key randomness should not interfere with user-friendliness.
Client:
Send(PublicKey);
SupportGuy:
Receive(PublicKey);
NewKey = GenerateStrongRandomKey();
Send(EncryptWithPubKey("doughnut"), EncryptWithPubKey(NewKey));
Client:
Receive(NewKey);
DecryptAndCheckPassword(NewKey);
From now on they communicate with a strong random key. Server operator has 1 guess per connection. That is not enough: Even if original password is 3 english-alphabet characters long chances are ~0.000057%
Access request (Sending initial password) should be manual part.
I miscalculated probability. My bad :(
It is 1/26 * 1/26 * 1/26 * 100 = 0.0057%
What advantages does this have that SSH doesn't? It has the security
problem that I've described earlier, someone more experienced than me
could find other issues.
Aaah I don't know whats with my brain this morning... Anyway... I failed at the part where New key is sent... Doughnut should be encrypted as a part of new password to prevent operator from extracting it and sending its own key...
Send(EncryptWithPubKey("doughnut" + NewKey)); // + means concat
This way, security problem no longer exists...
Advanges? I don't know how ssh works in detail.
I din't know that this would be an issue. Well-known professional
cryptographers designed protocols that were later broken, it's not easy
to make a secure one.
Most tasks for which security is important use TLS or SSH, many security
people know how SSH works and much research was done for its security.
A custom protocol won't get such support. (I don't know the real deep
details of SSH.)
Well, I am fairly sure that protocol i proposed is secure because it relies on the fact that public key cryptography works. Thing is that after both sides „agree” on new randomly generated key you can tell the operator that the key was doughnut but it won't matter anymore and session will remain secure. And operator is unable to insert his key because initial „easy” key was transmited using third party. One key can be reused (assuming you didnt tell it to operator) and it would still not matter because operator has 1 guess per session.
Its secure :)
Years ago I used UltraVNC in Windows XP to another Windows XP and it was easy. Without port forwarding.
The only thing I needed was the IP.
UltraVNC does require port forwarding.
I am a member!
Again- if anybody wants to start a project!
Please do. Something dead easy to use.
I'll make the first financial contribution to the project. Just propose a number and I'll let you know if its feasible.
I will definitely start a project to do this. However, before announcing anything, Michał Masłowski (mtjm) and myself are exploring alternative approaches as well (Such as peer to peer with libnice/libjingle: Alot of traffic on the server might not scale too well)
I'd have to dig into it again but there were some VNC based solutions where the people involved made the server non-free software but the clients were all free software. I wonder how hard it would be to pick up one of those clients and build a server to work with it. Maybe it wouldn't save any time at all...I don't know.
See this about EchoVNC[0].
Latest version: 2.221 Released on: 25 Sept 2007 EchoVNC is a secure remote-desktop tool based on VNC. With it, a Windows PC or OSX Mac can be remotely accessed regardless of firewall or router configuration. Standard VNC becomes "firewall friendly" -- no more port-forwarding! EchoVNC comes with a VNC Viewer, and is designed to work with any flavor of VNC server that you already have installed. EchoVNC uses OpenSSL components to secure your data connections with 128-bit AES encryption. To establish EchoVNC connections, you can either run your own packet relay server or use our free one at "demo.echovnc.com".
[0] http://en.wikipedia.org/wiki/EchoVNC
[1] http://echovnc.sourceforge.net/fom-serve/cache/1.html
This is the one I was thinking of. It has a non-free server and free client code.
How to Use VNC Through a Firewall: http://servera-inc.com/vnc-firewall/
I am a member!
This works if remote desktop has been configured already with port forwarding although if a user hasn't has this setup it becomes extremely difficult.
It looks like the key here is the server relay software that runs inside the client's network. By doing this it can act as a "VNS/RDP Gateway" for any client machines in the LAN and it always talks to the server hosted out on the internet. I may not be understanding this correctly though so correct me if I'm wrong.
I am a member!
OK
It still would need port forwarding though on the router for at least one system even if it then handled any other clients within the network.
There may be an auto-configuration that could be done on both ends if the routers are setup for it on both ends. Although that assumes a lot I think. I guess you could make the assumption that the person fixing the system at the other end is smart enough to setup forwarding and then have the user connect to them. They then would only need an IP address.
CGN makes this more difficult, I can configure the router of the system
that I'm usually fixing and I have no choice for the ISP available here.
Other users might want to connect to users under a CGN.
We need a server (maybe a TURN server: the same could be used for
federated VoIP; an SSH server that the user can access; or maybe a
custom server for this service) for some (most?) cases, direct
connection if a host is public (which one? and IPv4 or IPv6?), or some
kind of hole punching working with some kinds of NAT. (I think the
assumption that the connection must be over the public Internet and not
e.g. an internal network of an organization/single ISP is reasonable.)
This leads to having many options, making it difficult to configure.
Some of these are specific to both hosts, so they need negotiating for
each connection (in the protocol discussed here over IM, it needs to be
simple).
We could implement a solution using one specific server protocol and
then optimize it for other uses.
TURN seems very troublesome...
We can try to test if this works:
http://www.h-online.com/security/features/How-Skype-Co-get-round-firewalls-747197.html
I did a quick(read: proof of concept only, no server but manual port checking with wireshark) implemenatation and suprisingly it worked on my LAN. It may or may not *really* work but its worth considering. I'll send you the source when we're both online (#trisquel, tomorow; mail for details) if you are willing to help me test it out.
I don't think you would need port forwarding and the reason I say that is because the client internal on the each LAN establishes the connection out to the server that is out on the internet. That server of course has all of the correct network configuration to receive incoming connections. Because the clients are establishing the connection from behind the NAT, the server can then reply back and not get blocked by the router.
I think that you should be able to write a VNC client that is capable of acting as this gateway forwarder that is illustrated in the final example on that web site from a couple posts back. Isn't this basically what TeamViewer is probably doing? Both ends have to contact the server though, and that is the key.
I am a member!
I'm not 100% following what your saying although I think I get the gist of it.
What your saying is that there is a third party server involved although the bulk of the bandwidth / screen data being passed from the one machine to the viewer does not need to pass through a middleman despite both ends being firewalled. The middle man only acts as a temporary go between to establish the connection between the two parties. I could see that working although I would think that for that to work there probably would need to be a bit of IP spoofing going on in order to get the viewed systems firewall to open up.
I am a member!
I'm going to post an idea to the main thread about setting up a company or subsidiary aimed at offering a series of services which are free software friendly, secure, and privacy respecting.
The idea being to replace Google, Microsoft, and other services while at the same time adding numerous tech-savy desirable ones in a convenient hopefully cost effective package.
Services like those that teamviewer provides (which require non-free software) which make remote desktop software easier (but free software friendly with this new company/operation).
Here is where I'm posting the new discussion:
https://trisquel.info/en/forum/there-any-interest-privacy-free-software-friendly-services
What I'm interested in is finding out if there may be enough people to make this worthwhile. These are services that I personally would like or we could use at ThinkPenguin and have found no good options short of spending a lot of time and money to do oneself. Of course that is much more expensive than combining the resources of a community. Unfortunately there are more often than not no good free software / privacy respecting / cost effective / or anonymous solutions out there.
You can try using gosupportnow remote support software. It is not totally free, however, just costs you $19.95 / month, which is next to free.
An extra $20 a month would not be considered "next to free" for a lot of people.
And besides, whether or not software is free (as in freedom) has nothing to do with its price. Gosupportnow is clearly proprietary software, which we do not recommend or support on this forum.
I know this is a somewhat old thread and some of the concepts of the original question have been discussed in other threads but has anyone looked into the idea of using VNC Repeater?
http://www.uvnc.com/products/uvnc-repeater.html
It looks like it's under the BSD license. I suspect if we wanted to make improvements to it we could fork it and GPLv3 the whole thing. I see that someone has built this package for openwrt but it's not readily available in the official Debian or Ubuntu Repos that I know of.
I was just looking around a bit more at VNC Repeater and it looks like that will only work with UltraVNC clients. I did find a project on google code that has forked this to GPLv2 and has the goal of making this work with any VNC client.
Hi Everyone
While researching, I found this page in WIKI. there is a lot of software as equal as team Viewer. Depending on what you need, Lots of software developers are under GPL licensing.
https://en.wikipedia.org/wiki/Comparison_of_remote_desktop_software
I think much of this software is equal in many ways but it is all pretty much lacking the ability to work around NAT. They only way to make this work is to do port forwarding on the router.
This is the big problem really and that's why companies that make software like TeamViewer are able to capitalize in this area of software.
Alucardx
I agree with you 100percent in your comment. Everything was capitalized based on fix IP and not NAT.
- Vous devez vous identifier ou créer un compte pour écrire des commentaires