How to set up public key SSH authentication?
Built-in SSH supports password authentication only. You have to use external SSH in non-interactive mode (the external SSH field assumes standard Unix CVS CVS_RSH syntax, i.e. user name, server name and executed command are supplied by the IDE CVS support).
For example, on Windows specify following external SSH command:
> plink -i private_key_filename
Do not forget that the external SSH command must handle firewall tunneling if behind firewall. For example, on Linux:
$ /usr/bin/runsocks ssh
Finally you should test server correctness using a command shell. Following *nix response is triggered by typing noop\n.
$ ssh -l pkuzel cvs.sourceforge.net "cvs server"
Applies to: NetBeans 6.x, 5.x
Extra notes to make life 'simpler' using putty
This has worked using NetBeans 5.5
For Windows users, have a look at the following page to find out how to create the private key file using puttygen etc.: http://www.howtoforge.com/ssh_key_based_logins_putty
Once you have worked through the four pages, and have set everything up (including a running pageant), you can SIMPLY (?) enter plink in the box for external ssh! There is no need for plink -i private_key_filename.
NOTE: You probably need to go to a command line prompt and test the connection with:
(Don't include the starting '>' and replace <username> with your username and <cvs_servername> with the address of the CVS server.)
It is important to store your private keys with a passphrase because you don't know who has access to your machine. This requires you to use pageant on a Windows machine with NetBeans, as NetBeans does not ask for the passphrase and will hang if pageant is not running!
Tips for Server configuration and SSH authentication
One of the biggest problems with SSH authentication and CVS, is server permissions. When a user commits a file, the file is created under the account which the user is logged into. If permissions are not set up properly, then other users may not be able to read (or more likely) write new changes to the CVS repository.
Assuming the CVS server/repository is on a Linux machine (and your permissions are controlled with just users and groups. i.e. no ACL's), the easiest way around this problem is to create a new system group called CVS and add all users eligible to modify the repository to the CVS group. The "trick" is then setting the group of the Repository folder to CVS and setting the "suid bit" on the repository folder which should be read/writable by everyone in the group. This way, any new files which are created in the repository will be owned by the CVS group and new folders will inherit the parent folders permissions.
The command looks like this: chmod g+r,g+w,g+s /path/to/Repository
NOTE: If the repository already exists, you must do this for every folder in the repository.
Another alternative if "external" SSH techniques are uncooperative.
Though the above techniques are much easer, this tip originated after having difficulty using an external ssh command on Windows Vista SP1 (it kept hanging). The following tip applies to Windows users, but may be easily adapted to Linux by using the first technique (without using cygwin, of course). As above, this technique assumes that you have SSH access to a CVS host. However, this technique also assumes that you have CVS pserver access set up on the host for the desired repository.
Though the CVS pserver access method is generally considered insecure, it can be made secure by tunneling the CVS pserver protocol through SSH. If you enable a CVS pserver configuration on the CVS server, but block port 2401 with a firewall, this method should be as secure as pure SSH. The goal is to make the CVS pserver accessible only by the CVS host itself, while tunneling the results through an SSH connection.
Fist method (with cygwin):
1) Open a cygwin command console
2) Type: ssh -N -L 2401:localhost:2401 <username>@<cvs_server> Where <username>@<cvs_server> is an SSH username and server where you already have SSH access.
3) This creates an ssh tunnel from for 2401 on your local machine to port 2401 on the remote machine. The -N flag just prevents a remote shell from being activated... if you want a remote shell too, just omit the -N.
4) To access the remote cvs server via the command line, use something like: cvs -d :pserver:<cvsuser>@localhost:/path/to/repository logon. When using the Netbeans integrated CVS tool configured for pserver access. (Of course, the CVSROOT/passwd file has to be set up as well).
Another alternative is to use PuTTy's port forwarding capabilities. (This assumes you already know the basics of using PuTTy)
1) Configure PuTTy to log into a remote SSH session as usual
2) In the PuTTy configuration for the session, find the options for Connection->SSH->Tunnels
3) Make the source port 2401
4) Make the destination <cvs_server>:2401
5) Click the "Add" button to add the tunnel
6) Save the session
7) Now, when you remotely connect to the CVS server via SSH, a tunnel will also be mapped
8) The client usage is the same as the cygwin version
In both of these versions, you are simply mapping a local port to a port on a remote machine. As far as the CVS client is concerned the pserver is running on localhost, but the data is being tunneled via SSH to the real CVS server over and SSH link. Having port 2401 blocked on the server should not be a problem (if fact, you probably should have it blocked), since the pserver access is actually occurring locally (inside of the tunnel).
Though this is a bit more complicated, it way be useful in the interim when migrating if migrating pserver access to ssh. The benefit is that it allows individual users to share one local system account (used for ssh) while preserving the cvs "passwd" file for proper commit tracking. There are more details about CVS and ssh tunneling here: http://www.cycom.co.uk/howto/cvssshtunnel.html