Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WOW! and security? #14

Closed
bketelsen opened this issue Apr 23, 2016 · 11 comments
Closed

WOW! and security? #14

bketelsen opened this issue Apr 23, 2016 · 11 comments

Comments

@bketelsen
Copy link

  1. This is freakin amazing, thank you!! Works flawlessly in both directions from linux -- mac in and outside of neovim. Thank you thank you thank you
  2. To experiment I did:
    cat somelinuxbinary | lemonade copy on linux
    and lemonade paste > somelinuxbinary on mac
    then file somelinuxbinary and it showed ELF 64bit binary (as you would expect)
    this scared the daylights out of me. How can lemonade be secured other than the network masking?
@pocke pocke added the question label Apr 25, 2016
@pocke
Copy link
Member

pocke commented Apr 25, 2016

Thanks for using!

Hmm, do you need IP blocking?
Lemonade supports IP blocking as a configuration.
https://github.com/pocke/lemonade#server
If you write allow section in lemonade.toml, lemonade blocks access from not allowed IP.

And lemonade doesn't provide other function of security(e.g. encryption).

@bbatha
Copy link

bbatha commented Apr 28, 2016

This seems like a super handy tool. The security of this unfortunately scares the bejesus out of me. Copy/Paste is begin enough but the open command is down right frightening. Could you please add some kind of encryption and authorization layer? Also a way to disable features like open would be much appreciated.

@bketelsen
Copy link
Author

been using this for several days now, and just want to say it's an amazingly useful tool. Security question still remains, but what a great addition to my vim/ssh toolbelt.

@pocke
Copy link
Member

pocke commented May 1, 2016

Hmm, maybe we can use ssh port forwarding for encryption and authorization(but I have not tried it).
https://help.ubuntu.com/community/SSH/OpenSSH/PortForwarding

Sorry, I'm not familiar with encryption technology. so, I'm not going to implement an encryption feature into lemonade.
But I accepting PR!

@Perlence
Copy link

Perlence commented May 1, 2016

Remote SSH port forwarding works well. I start lemonade server on Windows and allow 127.0.0.1 only, then connect to Linux server:

lemonade server -allow 127.0.0.1 &
ssh -R 2489:127.0.0.1:2489 user@host

@bketelsen
Copy link
Author

Maybe just mentioning this scheme in the read me is enough?

Sent from my iPhone

On May 1, 2016, at 10:56 AM, Sviatoslav Abakumov notifications@github.com wrote:

Remote SSH port forwarding works well. I start lemonade server on Windows and allow 127.0.0.1 only, then connect to Linux server:

lemonade server -allow 127.0.0.1 &
ssh -R 2489:127.0.0.1:2489 user@host

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

pocke added a commit that referenced this issue May 2, 2016
@pocke
Copy link
Member

pocke commented May 2, 2016

https://github.com/pocke/lemonade#secure-tcp-connection
added.

@beaugunderson
Copy link

beaugunderson commented Jul 13, 2016

you can add this to your ~/.ssh/config for a given host too:

Host example.com
  # forward local port 2489 for lemonade copy/paste server
  RemoteForward 2489 127.0.0.1:2489

@kiryl
Copy link

kiryl commented Dec 4, 2016

Port forwarding doesn't really solve the security concern.

Consider situation when client is on shared machine. All local user will have access to clipboard on your server. That's not very secure.

I would rather purpose to modify the client to be able connect via Unix socket. OpenSSH already can forward a TCP socket to Unix socket on remote machine.

Or even better to change both client and server to use stdin/stdout for connection, so it can wrapped into any transport user likes.

@xelra
Copy link

xelra commented Mar 9, 2017

@kiryl Having the client create a local socketfile instead of communicating via TCP would indeed solve the problem of the remote machine being used by multiple users. In case the local machine is Windows and is used by multiple users too, it wouldn't solve the problem, because OpenSSH (Cygwin) cannot bind to named pipes on Windows. So locally you have to bind to a TCP port like this ssh -L 2489:/tmp/lemonade.socket user@server. This is probably acceptable for most users though.

An option --no-open or --disallow-open is desperately needed though. Remotely executing (or like above, other users of the local machine) anything is something that one really needs to be able to disable.

@niko
Copy link

niko commented Feb 23, 2018

It would be nice if the client would support a unix file socket. One could the forward the file socket via ssh and "secure" the connection via file socket access rights.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants