What ports need to be open for TortoiseSVN to authenticate (clear text) and commit?

Question

What ports need to be open for TortoiseSVN to authenticate (basic) in order to commit? I know it is not a good thing, but I believe username and password are in the clear right now.

Let me describe as much as I know about set-up, and what seems to be happening.

I am a contractor helping a state to deploy and modify a "mostly" public domain application. There is an SVN repository in a different state which contains the application, with read only privileges for everyone.

In order for me to work on the site that I want to deploy, I must create a VPN connection, and then use Remote Desktop Connection to access the machine where the deployment will reside. When I am on that machine, I can browse the repository and export or checkout anything. When I attempt to commit I am prompted with a username/password challenge, and it always fails.

When I am at my home machine, I can commit to the exact same repository and the exact same place using the exact same credentials. I have asked the repository manager to verify that the username I use has all the necessary rights to commit, and I am assured that I do.

So, even though I am getting an error message that describes something like "invalid credentials", I think that the authentication is being blocked. I am attempting to find out whether or not a default SVN installation would use the same listening SVN port, or a different one for authentication. I don't believe the authentication is encrypted.

I'd appreciate any suggestions.

Solution

What's the first part of your Subversion repository URL?

• If your URL looks like: http://subversion/repos/, then you're probably going over Port 80.
• If your URL looks like: https://subversion/repos/, then you're probably going over Port 443.
• If your URL looks like: svn://subversion/, then you're probably going over Port 3690.
• If your URL looks like: svn+ssh://subversion/repos/, then you're probably going over Port 22.
• If your URL contains a port number like: http://subversion/repos:8080, then you're using that port.

I can't guarantee the first four since it's possible to reconfigure everything to use different ports, of if you go through a proxy of some sort.

If you're using a VPN, you may have to configure your VPN client to reroute these to their correct ports. A lot of places don't configure their correctly VPNs to do this type of proxying. It's either because they have some sort of anal-retentive IT person who's being overly security conscious, or because they simply don't know any better. Even worse, they'll give you a client where this stuff can't be reconfigured.

The only way around that is to log into a local machine over the VPN, and then do everything from that system.

Comments

[Admin]

so, you are saying, for get the remote desktop, get on the local machine, I cannot do that but perhaps somewhere at the site can. I am only using the first url, so it is over port 80, works fine in repo browser, for export, now in if I go to a dir on the remote desktop machine right click and choose svn commit - from tortoise, that's when I prompted for username and password, and that's where I am blocked, and I am trying to find out what port that authentication would go over. It is not ssh, so do I assume port 80 - in a "norma" environment, or does the auth part use a different port

[David W.]

Logging onto a local machine is an easy way to handle the issue. VPNs are rather complex and all are different. The VPN usually takes over networking on your local computer, but some VPN clients allow you to split traffic based upon IP address. Then, it's up to the VPN software and how its configured. You need to contact your IT dept about how you can connect via the ports you need. They may have to configure things differently. A lot of time, developers get screwed by the VPN because the network nitwits decide to block everything for security and don't realize Developers have special needs.

[Admin]

Dave, Thanks - I have a conference call with the IT person in charge of the machine where deployment, modfication/deelopment is taking place, and I think you are correct it has to do with splitting the traffic. Thanks alot for you help...

[Sid Sarasvati]

Useful info and great answer. Thanks

[Matthieu]

+1 for the exhaustive information. I would +1 once more for the "anal-retentive" but unfortunately I can't ;)