Hi Tim,

We are currently beta testing a method of using direct ssh connections between the p4 client and server. It works well on unix. We are still trying to finish testing it on windows.

This model, as opposed to the port forwarded model, should be much more secure in that there is no port that a random user can use to access the server (during port forwarding, the port is open for general consumption and use). Additionally, using port forwarding people can still become another perforce user with a '-u foo' on the command line (which is a problem if the protect table is being used to implement ACL's on the source code). Since perforce user passwords are not secure (environment variables, etc.), if one does not know foo's password, it is relatively easy to get it.

In the ssh direct scheme, the user-id that is used for authentication is the perforce user-id, not the local/network (ldap) user-id. This is crucial if one wants to restrict perforce server access to the _perforce user_ that has given the public ssh key to the server as opposed to the computer login user account. This will prevent perforce user joe from ever becoming perforce user foo (assuming foo's private ssh keys are secure).

If we can verify that it works, we will certainly deposit the code in the perforce public depot. (It already has documentation.)

-sandy

======== Dear All,

I am currently looking at providing remote access to a Perforce database

via dialup connections. Unfortunatly this means that we can no-longer simply verify the IP address as a means of security. Also, the users would need to be able to download the source code directly to their laptops so using ssl/telnet to a secure server also isn't an option.

Any suggestions about how we could implement this without compramising security would be greatly appreciated.

thanks, Tim