I have migrated my wife's (then girlfriend) computer to Linux and sometimes I had to configure something on her computer (e.g. a printer). This ended up generating lots of back and forth on the phone with me telling her commands to write in the terminal, and she reading the output out loud. I wanted an easy way to see her terminal. So shellshare was born.
Shellshare allows you to run a single command line and share your terminal online (read-only)
Please don't tell people to do this. This is an idiom called "curl pipe sh"; you're asking people to run whatever code someone on their network decides to send them.
As an absolute minimum, you should change that http to https, so that they're merely running whatever code YOU decide to send them; but even that doesn't quite fit with the "share your terminal (read-only)" philosophy...
I agree with the HTTPS part, but aside from that I can't really see how it's less safe than saying "here, install this .deb (which gets to run scripts as root) and then run the binary inside".
deb packages distributed to the public should be pgp signed and in a proper repository. It doesn't help people who will just force-install it anyway, but if they care it allows verification.
Out of band verification. When you're doing curl pipe sh, you're trusting the host and that's it. With packages, you can verify the trust against external services like keybase, check website archive for changed key ids, check signatures on the public key if the author is into things like web of trust.
It won't protect you against someone being directly malicious, but it will against MitM, website hacks, etc. It also establishes semi-permanent trust on first use.
>Out of band verification. When you're doing curl pipe sh, you're trusting the host and that's it. With packages, you can verify the trust against external services like keybase, check website archive for changed key ids, check signatures on the public key if the author is into things like web of trust.
You could use hashpipe (https://github.com/jbenet/hashpipe), from Juan Benet (the author of IPFS). It simply checks that the input to the command matches a given hash, so you can do `curl <url> | hashpipe <hash> | sh`, and if the output of the curl command is different than expected it won't be passed in to `sh`.
Ironically the prebuilt binaries of hashpipe itself are provided without means of verification :I
So if you are going to use hashpipe, I think you should download it in source form, read it -- it's under 100 SLOC -- and then build it from source yourself. This way, you do that once and then in the future provided that you trust those sending you various scripts and binaries and the channel they used to provide the hash, all is well and no further manual verification is needed on your side of things ever again for any of those.
If an attacker can modify the output of the curl command (on the host or on the wire), cannot they also modify the value of the hash seen and copy-pasted by the end-user? I must be missing something...
As viraptor said, putting code into a public repository (e.g., debian packages); that way there should be a paper trail if the code is modified.
Beyond that, there's a simple matter of advertising: "Share your terminal (read-only)" may mislead some people about what is happening. A more accurate description would be "Give us control of your terminal (we promise we'll only let other people read it, not write anything)".
Imagine if this principle were applied to other software products. "Click here to download the Office installer, which will gain full admin-level access to your machine. We promise to only use that to install Office."
The only thing sent to shellshare's servers is the text in your bash terminal. There's no return channel for the servers to send commands back to the computer.
You could argue that you're giving control of the terminal because you're running a third-party executable, but that's the same for any executable you run.
Wow, that's pretty cool. I've thought about moving my parents to Linux; my mom only uses the internet, and while my dad needs his computer for work, the software he uses supports Linux. I'm afraid I'm not going to be able to support Windows for them for much longer. I use Linux full time, and Windows is slowly changing. I can still talk them through most problems over the phone, but little changes here and there have made walking them through an issue really time consuming, which is frustrating for all of us.
My chief concern with installing Linux was having to teach them how to communicate what is happening over the phone all over again. Outside of that, I'm pretty confident Linux is a good choice for my parents. My dad actually worked for Digital Electronics for years, and he's been interested in Linux for as long as I've been using it, but I think Linux would actually be better for my mom, because she literally doesn't care about her computer as long as it works. Her computer issues are generally the "the computer keeps telling me something and I want it to go away" type. Fixing those problems on the phone with Windows is a mess, but are basically trivial in Linux. My dad's issues are generally "I broke the internet," so this wouldn't be as helpful for him.
I'm really excited about this. I might honestly go buy an SSD to install Linux on my Mom's computer today. That way I could just drop it in her computer next time I'm at her house. My hope is that the boost in speed from Windows---> Linux, and the boost in speed from a 5400 rpm drive --> SSD would keep her happy long enough to get used to Linux. She's been complaining a lot about speed recently, and last time I was there I discovered she managed to her default user folder from the internal drive to an external USB backup drive. I have no idea how she did this, but it means she keeps running out of space because the backup process now backs up the backup drive recursively.
Yeah, I've used it at times. It's great when it works, but getting remote desktop working is always a bigger pain than just trying to explain the problem over the phone. The individual issues aren't that big, but it means a 20 minute phone call turns in to a 1 hour phone call because we spend 20 minutes trying to get screen sharing working.
For one thing, I'm generally away from my computer when they call me, and all I have is my phone. If that isn't an issue, then port forwarding is an issue, or the desktop sharing they have on their computer is out of date, or they only have RDC, and I can't find a Windows computer. Sharing the desktop via chrome works pretty well, it still can be an exercise in frustration. For instance, my dad is a trader, and has 8 monitors. Getting him to share the correct screens takes forever. (I don't know how Windows decides where to open a window, but it seems like it tries to find a monitor my dad isn't looking at and opening it behind a window marked stay-on-top.)
I might use it if the problem was extremely urgent and extremely complicated, but I live about 30 minutes from them, so I'd just head over to their house if it was that bad. Screen sharing software was just one more thing to go wrong on their computers. This way, I don't have to worry about whether they have a version with a critical vulnerability, or if they'll fall for a social engineering attack and click on a teamviewer invite.
This software solves my concern about not being able to see what the hell my parents are doing when I'm telling them shell commands. This makes it really easy. They'd already be using Linux if I knew I'd always be able to use desktop sharing to look at their computer, and port forwarding/security/etc wasn't a concern, because connecting to a remote X server is incredibly easy. I already fix internet issues by SSHing in to the router (with key-based authentication) and then connecting to whatever piece of hardware needs to be tinkered with. I could probably do the same thing for an actual desktop, but I've fixed misbehaving servers via ssh on my phone before, and typing commands on a phone keyboard is an exercise in frustration.
In any case, I sat down with my dad and created a clean image of his desktop a while back. When he really messes something up he just reimages his computer. He likes the fact that I gave him the ability to bring his computer back from the dead himself. All his files are installed on a separate disk, which is constantly backed up, so he never loses more than about 20 minutes of work.
>Screen sharing software was just one more thing to go wrong on their computers. This way, I don't have to worry about whether they have a version with a critical vulnerability, or if they'll fall for a social engineering attack and click on a teamviewer invite.
It's no more of a risk really with TeamViewer installed. An attacker can use gotomypc or similar or just send a TeamViewer invite binary (or link to download it and give the attacker access).
Wasn't there some story a few months back about TeamViewer accounts being hacked in some unknown way and their access used to infect machines? Was that ever clearly resolved? (I remember speculation of TeamViewer themselves being compromised, or just a massive password-reuse attack, or ...)
It's never been clearly resolved, but also hasn't developed. So far it looks like TV was correct and the breaches were the result of password reuse from other sites who did have passwords compromised.
I suggested this in a recent similar thread: if this is a desktop, you could switch to an entry-level server motherboard with IPMI.
Then run the IPMI cable to OpenVPN on (eg) an RPi or even directly on the router.
You can configure and soak-test the router/RPi/etc locally, and IPMI is OOB.
Using an RPi/similar has some nice properties: you could VNC to that and then go from there to the IPMI console, and also recovery images stored directly on the RPi would upload quickly etc.
This is another great option, with much more features than shellshare. At the time I started working on shellshare, it only allowed read/write sessions, so I wrote it anyway.
Linux tends to require configuration/debugging from the console. Don't get me wrong, I use linux every day, but I would never push it on someone who is not interested in solving their own tech problems.
If it's setup and working it requires no configuration/debugging. And it sounds like whether it's windows or linux he's going to be responsible for fixing any computer problems so it may as well be on a platform less prone to problems that he can fix better.
Just being on a platform where uses can't get infected with malware from stupid flash game sites cuts out 90% of maintenance.
Connect them to a private zerotier network (https://www.zerotier.com/#try_zerotier) it's free and you can bind sshd just to the zt0 interface. Instant access from anywhere.
I may be biased, but I put zerotier on lots of hosts these days. Whether it's home raspberrypi for remote access, or vps to get all administration off the public network, or sometimes just as a VPN replacement for stuff like replication. It's pretty much fire and forget.
You can install TOR on the machine and use it for NAT traversal, by making SSH available through a hidden service. Latency is a bit high but it's easy to set up and connect to.
I have migrated my wife's (then girlfriend) computer to Linux and sometimes I had to configure something on her computer (e.g. a printer). This ended up generating lots of back and forth on the phone with me telling her commands to write in the terminal, and she reading the output out loud. I wanted an easy way to see her terminal. So shellshare was born.
Shellshare allows you to run a single command line and share your terminal online (read-only)
That'll give you an URL others can join and watch your terminal live. No sessions, no recordings, and the data is deleted every day.There aren't many users, but I use it almost every week.