|Host||Protocol||Key Length||Key Fingerprint|
NOTE: For SVN, the fingerprints are not listed. Instead you should check our Subversion documentation on using a web browser to check the server certificate.
SSH (Secure SHell) is used by SourceForge.net to provide secure access to the project CVS, project Git servers, and shell servers. In order to access these resources, you must be a project developer and have a SSH client.
SSH provides security in several ways:
- All data sent between the client (your workstation) and the server is encrypted. This prevents someone from eavesdropping on the network and stealing your password, or secretly tampering with the data sent between you and the server.
- A special handshake is done when your client connects to the server. Your client is responsible for providing your account username and some form of authentication data matching what the server has on file for your account. This authentication data typically takes the form of either a password or data produced using a shared SSH keys.
- Shared SSH keys are comprised of a SSH private key stored on your workstation which matches a SSH public key stored on the server. SourceForge.net hosts accept SSH key authentication, preventing password exposure.
- As part of the connect handshake, your client also verifies a key, called the SSH host key, provided by the host you are accessing. Your SSH client checks to see whether you have successfully connected to this host in the past. If this is the first time you are connecting to this host, you will be asked to confirm that the SSH host key matches what you think it should be.
- By personally verifying this SSH host key data, you prevent someone from running a server that claims to be a SourceForge.net server (such as by taking over your DNS server and directing you to their own machine). You also ensure that you have not miskeyed the hostname, accidentally connecting to a server operated by someone other than SourceForge.net.
SSH Host Key Verification
The SSH host key is typically represented on disk as a long stream of letters and numbers. For ease of comparison, a special checksum, called a fingerprint, is generated from this host key data. This allows you to quickly verify that the host key matches what you are expecting.
When you are prompted to verify the SSH host key fingerprint, you will compare the on-screen fingerprint data with the fingerprint data stored in this document. After verifying that the fingerprint shown on screen matches the fingerprint in this document, you may approve the fingerprint in your SSH client.
After verification, the host key is then stored on disk by your SSH client for comparison behind-the-scenes when you connect to this host in the future. If your SSH client detects that this SSH host key changes unexpectedly in the future, it will prevent you from connecting to that host, thus preventing you from accidentally sending your password or private data to some other server.
The fingerprint displayed by your SSH client should exactly match the fingerprint in this document for the listed host and protocol. If it does not match exactly, you should cease your attempt to connect to the host. For the CVS hosts, you will have to compare the fingerprint of the hostnames that have matching IP addresses, as it would be impractical to list all of the hostnames here. Any SSH host key fingerprint problems should be reported to SourceForge.net staff.
Additional information on the importance of proper SSH host key validation may be found in the PuTTY SSH client manual.
Host Key Storage
After confirmation, SSH host key details are stored on the local disk; location depends on the SSH client:
- OpenSSH: Host key details are stored in the known_hosts and known_hosts2 files in the .ssh directory for your user.
- PuTTY: Host key details are stored in the Windows Registry.
Host key fingerprints are host and protocol specific. Regardless of which SSH client you use to access the host, the key fingerprint should always exactly match a fingerprint listed in this document for the host and protocol you are accessing.
Confirming Bad Key Data
Once you have addressed the issue of credential (password or key) exposure, you should remove the bad host key from wherever your client stores host key data.
Host Key Change Frequency
SSH host keys (and their fingerprints) are changed very infrequently, on the order of years. You should be suspicious of any messages from your SSH client which say that these keys have changed. Should such a warning message arise, you should immediately contact the SourceForge.net team.
When host keys change, you will see a warning.