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

Suggest using a stealth Onion service for even greater security. #48

Open
wants to merge 27 commits into
base: master
Choose a base branch
from

Conversation

fabacab
Copy link

@fabacab fabacab commented Aug 19, 2017

A stealth Onion service is a form of mutually authenticated connection between a Tor hidden service and a Tor client. The Tor server's identity is verified by virtue of its .onion address, whereas the client is authenticated by means of a pre-shared key, called a client authorization cookie. This form of client authorization over Tor is especially useful to prevent attackers from being able to connect to your SSH server and retrieve its private key fingerprint, because the Tor process will reject any connection that does not supply a valid client authorization cookie before ever passing the traffic on to sshd.

Copy link

@jchevali jchevali left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is not appropriate to illustrate inserting the client data for connecting to the stealth service into torrc through a reference to micahflee/onionshare. Really, what is the chance that people running the Tor server will be running OnionShare? I don't think there's much, and the Secure-secure-shell article wasn't mentioning this product before. If a process illustration is needed, it should derive from a standard (ordinary) Tor server setting without unnecessary additions.

@fabacab
Copy link
Author

fabacab commented Jan 29, 2018

If you read the instructions on the OnionShare wiki, you will see that they do derive from a standard Tor. OnionShare is irellevant. The link was provided because it is exactly the same content as what is needed to inform a layperson how to configure a Tor client to connect to an Onion service, except they have already been written, so I saw no need to rewrite them (yet again). :)

@jchevali
Copy link

Any information that isn't absolutely precise and relevant is surplus to requirements, and it can be a nuisance, it can pollute content. You must think like a technical writer, and must not assume everybody has your background or better, to tell at a glance what's important, what's real and what's accessory, tell the wheat from the chaff. If you don't, people of a methodical mind who read this product page (Secure-secure-shell) will at best be annoyed, or distracted, or bewildered; people who're new to these issues may be confused, they may be misguided or misled, they may think they need to use OnionShare to achieve their ends when they do not. The overall quality of Secure-secure-shell is stribika's responsibility, and his also to accept, reject, or delay indefinitely any pull requests. Yours if you wish to collaborate is to submit thoughtful, carefully crafted, best-you-can pull requests. Mine is to comment when I feel these high standards aren't adhered to.

@fabacab
Copy link
Author

fabacab commented Jan 30, 2018

Thank you for reiterating the conversation so far. It sounds to me like everyone involved is doing exactly what you describe. :) Have a pleasant day.

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

Successfully merging this pull request may close these issues.

6 participants