diff options
| author | Tzafrir Cohen <tzafrir.cohen@xorcom.com> | 2011-06-15 16:11:40 +0000 |
|---|---|---|
| committer | Tzafrir Cohen <tzafrir.cohen@xorcom.com> | 2011-06-15 16:11:40 +0000 |
| commit | 60a54d6482d6b641e92a12749a8161f2b6311f9a (patch) | |
| tree | bf4419449db6e17eab0aacc54835883a00f7892c /README | |
| parent | 01815348667fc8a7f74ca25c986f47d7bea6f88f (diff) | |
rapid-tunneling: delete old authorized_keys entries
* rapid-tunneling-status -s (Stop) will also delete entries from authorized
keys.
* rapid-tunneling-status -r (Remove) will do that - if not connected.
* Note the authorized_keys file in the man page.
* Better initialize variables.
* More documentation updates.
git-svn-id: svn+ssh://xorcom/home/svn/debs/components/rapid-tunneling@9429 283159da-0705-0410-b60c-f2062b4bb6ad
Diffstat (limited to 'README')
| -rw-r--r-- | README | 24 |
1 files changed, 19 insertions, 5 deletions
@@ -95,6 +95,10 @@ you should run: rapid-tunneling-status +To disconnect: run + + rapid-tunneling-status -s + Server Operation ---------------- @@ -180,6 +184,13 @@ Feel free to send Tzafrir any questions or patches. Security -------- +Ideally this system should be simple to set up (assuming you have an SSH +server with a public IP address) and thus would be a handy and more secure +replacement to sending a password in the clear, or installing some Big +Binary Blob. + +The Server +~~~~~~~~~~ The remote access tarball is sent potentially over an untrusted channel (read: the Internet). It contains potentially sensitive information: a private ssh key. An imposter could try to impersionate as the client. @@ -194,17 +205,20 @@ no-X11-forwarding,no-agent-forwarding,no-pty,permitopen="127.0.0.1:65534",comman A key can also be used to flood the server's disk, which means that the support user's quota should be limited. +The Client +~~~~~~~~~~ The client then sends the connection information over the already established connection. - Alternatively, if an attacker manages to send her own key (pointing to her own RapidTunneling server) to the user, while pretending that this key comes from a trusted support contact, the attacker will gain access to the user's system. Thus the user should be careful about the key he gets. +I believe that there's no inherent issue with adding an extra key to the +user's authorized_keys file: If the user has explicitly asked for remote +support from a trusted party, the user might as well have sent the +password. If the connection was not disconnected explicitly by the user +(`rapid-tunneling-status -s`), those entries will remain and the client +should delete them manually (`rapid-tunneling-status -r`). -Ideally this system should be simple to set up (assuming you have an SSH -server with a public IP address) and thus would be a handy and more secure -replacement to sending a password in the clear, or installing some Big -Binary Blob. |