n2n: a Layer Two Peer-to-Peer VPN

[不指定 2010/02/25 00:02 | by ipaddr ]

http://www.ntop.org/n2n/

n2n is a layer-two peer-to-peer virtual private network (VPN) which allows users to exploit features typical of P2P applications at network instead of application level. This means that users can gain native IP visibility (e.g. two PCs belonging to the same n2n network can ping each other) and be reachable with the same network IP address regardless of the network where they currently belong. In a nutshell, as OpenVPN moved SSL from application (e.g. used to implement the https protocol) to network protocol, n2n moves P2P from application to network level.

The main n2n design features are:

  • An n2n is an encrypted layer two private network based on a P2P protocol.
  • Encryption is performed on edge nodes using open protocols with user-defined encryption keys: you control your security without delegating it to companies as it happens with Skype or Hamachi.
  • Each n2n user can simultaneously belong to multiple networks (a.k.a. communities).
  • Ability to cross NAT and firewalls in the reverse traffic direction (i.e. from outside to inside) so that n2n nodes are reachable even if running on a private network. Firewalls no longer are an obstacle to direct communications at IP level.
  • n2n networks are not meant to be self-contained, but it is possible to route traffic across n2n and non-n2n networks.

The n2n architecture is based on two components:

  • edge nodes: applications installed on user PCs that allow the n2n network to be build. Practically each edge node creates a tun/tap device that is then the entry point to the n2n network.
  • an supernode: it is used by edge nodes at startup or for reaching nodes behind symmetrical firewalls. This application is basically a directory register and a packet router for those nodes that cannot talk directly.

Edge nodes talk by means of virtual tap interfaces. Each tap interface is an n2n edge node. Each PC can have multiple tap interfaces, one per n2n network, so that the same PC can belong to multiple communities.
...

SSH Public-Key Authentication HOWTO

[不指定 2010/02/05 17:54 | by ipaddr ]

On Windows with SecureCRT

  1. Select Tools -> Create Public Key...
  2. Hit NEXT
  3. Select DSA, hit NEXT
  4. Leave Passphrase empty, and remove anything in Comment
  5. Select key length, 1024 is OK
  6. Move mouse around as instructed
  7. Save files to default locations, usually C:\Documents and Settings\YOU\Application Data\VanDyke\Identity and Identity.pub
  8. If prompted to use the key as your global key select yes.
  9. Use a text editor to view your public key Identity.pub
  10. Using your password credentials log into the server and paste the contents of the Identity.pub file into a test file, test.pub is fine. Do this as your user, not root.
  11. Run this as yourself from your home directory:
ssh-keygen -i -f test.pub >> .ssh/authorized_keys 
  1. Log out and edit the properties of the session you just used to connect.
    1. Under Connection -> Authentication : Change Primary to PublicKey then hit Properties...
    2. Enable "Use global public key setting"
    3. Enable "Use identity file"
    4. Make sure the file selected is NOT your public key, it should be C:\Documents and Settings\YOU\Application Data\VanDyke\Identity by default
    5. Hit OK
  2. You should now be able to connect using your SSH key.

On Unix with OpenSSH

  • Create users on the local and remote machines with the same username (and same UID/GID if possible)
  • On the local machine run:
Username@LOCAL_HOST $ ssh-keygen -t dsa 
  • Enter no passphrase, save keys to default locations (.ssh/id_dsa)
  • Copy the contents of
    • ~/.ssh/id_dsa.pub from the local machine
      • to:
    • ~/.ssh/authorized_keys on the remote machine.
DONE! Now you can connect without a password.
  • Using SCP (from your home directory)
Username@LOCAL_HOST $ scp -i .ssh/id_dsa File_To_Copy Username@REMOTE_HOST:/path/to/destination/File_Name 
  • Using SSH (from your home directory)
Username@LOCAL_HOST $ ssh -i .ssh/id_dsa REMOTE_HOST 

notes

  • Using the same setup as above you can copy files from the remote system to the local system:
Copy /path/path/file on remote system to current directory on local system
LOCAL_HOST$ scp -i /home/username/.ssh/id_dsa username@REMOTE_HOST:/path/path/file . 
Copy /path/path/file on remote system to /other/path/file2 on local system
LOCAL_HOST$ scp -i /home/username/.ssh/id_dsa username@REMOTE_HOST:/path/path/file /other/path/file2 


How to make SSH2 work with OpenSSH


The commercial version of SSH2 uses a different key format than the OpenSSH. This guide shows how to make them inter-operate with each other with public key authentication. It is based on descriptions from this website.

Case 1. OpenSSH server and SSH2 client

Suppose you already generated an RSA2 key pair on your SSH2 client machine, and the public key is stored at ~/.ssh2/id_rsa_1024_a.pub.
The following procedure applies to DSA key pairs too.
  1. Copy your SSH2 public key from your SSH2 client machine to your OpenSSH server like:
scp ~/.ssh2/id_rsa_1024_a.pub server:.ssh/rsa_ssh2.pub
  1. Run the OpenSSH version of ssh-keygen on the server to convert the SSH2 public key to into the format needed by OpenSSH:
ssh-keygen -i -f ~/.ssh/rsa_ssh2.pub > ~/.ssh/rsa_openssh.pub
  1. Append this newly generated OpenSSH public key to your authorization file on the server:
cat ~/.ssh/rsa_openssh.pub >> ~/.ssh/authorized_keys2 
  1. Once this is done, the .pub files you created are no longer needed so you can remove them if you like. 
Now your SHH2 client should be able to connect to the OpenSSH server with the public key authentication.

Case 2. SSH2 server and OpenSSH client

Note that RSA2 is not working on ISI's SSH2 servers at the the time the guide is written. DSA works fine, so you should generate a DSA key pair with the ssh-keygen on your OpenSSH client machine. By default, the public key is stored at ~/.ssh/id_dsa.pub.
  1. Run the OpenSSH version of ssh-keygen on the OpenSSH client machine to convert the OpenSSH public key into the format needed by SSH2: 
ssh-keygen -e -f ~/.ssh/id_dsa.pub > ~/.ssh/dsa_ssh2.pub 
  1. Copy this SSH2 public key to your .ssh2 directory on the SSH2 server:
scp ~/.ssh/dsa_ssh2.pub server:.ssh2/dsa_ssh2.pub
  1. Add this new pub key to the authorization on the server:
echo Key dsa_ssh2.pub >> ~/.ssh2/authorization 
  1. Once this is done, the temporary .pub file you created on the OpenSSH client is no longer needed so you can remove it. DO NOT remove the .pub file you just copied to the SSH2 server.
Now your OpenSSH client should be able to connect to the SSH2 server with the DSA public key authentication.

分页: 1/1 第一页 1 最后页 [ 显示模式: 摘要 | 列表 ]