<html>
<head>
<style>
.sw_message P{margin:0px;padding:0px;}
.sw_message {FONT-SIZE: 12pt;FONT-FAMILY:Tahoma,Arial,Helvetica,sans-serif;background:white;}
.sw_message blockquote{margin-left:5px;padding-left:5px;border-left:2px solid #144fae;color: #144fae;}
.sw_message blockquote blockquote{border-left:2px solid #006312;color: #006312;}
.sw_message blockquote blockquote blockquote{border-left:2px solid #8e5656;color: #8e5656;}
.sw_message blockquote blockquote blockquote blockquote{border-left:2px solid #888;color: #888;}
</style>
</head>
<body class="sw_message">
IMO cut and paste in the situation you're describing is not the perfect way. Better way would be:<br><br>Have a secure linux machine running an sshd at your home (or another physically-controlled location?).<br>Close off iptables and ip6tables for inbound sshd except for your vserver's IP<br>(hint: "ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_4096_key -b 4096" (don't put a password when it asks))<br>and edit sshd_config to point it to the new key. Also in the config, force your local sshd <br>server to insist upon only using these 2 ciphers ("Ciphers aes256-ctr,aes256-cbc"). <br>Restart the local sshd (maybe "service sshd restart") and verify that you can NOT connect <br>from the vserver to the home box using a different cipher (ssh -l someuser -c aes128-ctr your.home.ip.here).<br>A test ssh connection without the "-c aes128-ctr" should work, the one with it should fail.<br><br>You would do transfers of important files to and from the vserver via an 'sftp' session which you start <br>from your vserver, and you are connecting into your home machine (sftp someuser@your.home.ip.here). <br>Don't make the connection in the reverse direction, you can push and pull files with the one. And don't<br>let anyone steal your ssh_host_rsa_4096_key off the home box. (could even shred/delete/regenerate it <br>now and then). In general, turn off the home sshd when you aren't using it.<br><br>The above setup should be pretty good in terms of the network transfer if the data hasn't already been <br>compromised, of course. The certainty that it hasn't been is not necessarily guaranteed if it's already<br>been thrown through a network card in a less-solid way, such as the contents having been viewed <br>via 'cat', 'nano', etc. via a connection in the 'wrong' direction.<br><br>If you are deleting files from your vserver's hard drive after copying them out for backup, try doing <br>"shred" on the file first, and then "rm". It may help do the deletion better, depending upon how your vserver <br>hosting is set up.<br><br><br><br><br><div>On Monday 26/08/2013 at 10:53 pm, Tony Xue wrote: </div><blockquote type="cite"><div><div><div><div><div><div>Hi,<br><br></div>I have been discovering simple and secure way of protecting the Tor key files recently, in order to achieve the safety of the keys on VPS.<br><br></div>So I created a folder on Linux called /tor and it is stored in the RAM file system. I put my key file into that folder and link it back to the data directory folder of Tor. I also backed up the key files in case my server need to be restarted and the RAM would be cleaned up. I left the key in RAM for some undesired failures, errors or configuration which need to restart the Tor software.<br><br></div>If the server gets down, I would probably do the simple cut and paste in the SSH client to restore my key files. Or in a higher level way if cut&paste is not safe enough.<br><br></div>I am not sure whether this is a good way to protect my key files on a VPS. Does anyone have any comment on that or a better way?<br><br><br></div>Tony<br></div>_______________________________________________<br>tor-relays mailing list<br>tor-relays@lists.torproject.org<br><a target="_blank" href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays</a><br><br></blockquote><br>
</body></html>