SSH and Savannah

SSH access is allowed for registered users who are a member of at least one active Savannah group. If you are not a member of any group, then you can use anonymous https access.

The registered GPG keys are not used by Savannah for SSH operations, even when they include authentication-capable subkeys. We suggest you upload a GPG key because it is used by the FSF for file uploads elsewhere. But for version control repository access you have register an SSH key.

OpenSSH 8.8 SHA-1 Deprecation October 2021

OpenSSH 8.8 was released on September 26, 2021 and subsequently has been upgraded to by users of Savannah that are also following the development of OpenSSH. Most users of Stable OS software distributions will not yet have that new version and will not yet be affected.

In release 8.8 OpenSSH deprecated all use of the SHA-1 hash algorithm. The effects of this can vary depending upon the user's client side ssh options configured. It deprecates the ssh-rsa SHA1 signed host keys. If that is the only type of host key that you have cached into your known_hosts file then it will no longer be recognized and a WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! will be emitted.

There two working solutions.

1. The first and best workaround is to upgrade your ssh user key access to ED25519 keys. ED25519 keys were introduced in OpenSSH 6.5 and offers better security with faster performance using a more compact key. Using the ED25519 user key also enables using the ED25519 host key at the same time. Which is perfect! That's an excellent upgrade for both security and performance.

    ssh-keygen -t ed25519
   

   This creates a user key of type ed25519 and will place the files by default in ~/.ssh/id_ed25519.pub et al. Load this key into your ssh-agent.

    ssh-add
   

   Register this new public key in your "My Account Configuration: Change Authorized Keys" page https://savannah.gnu.org/my/admin/editsshkeys.php.

2. The second workaround comes from the OpenSSH 8.8 release notes. Provide a special client configuration on your system to enable ssh-rsa keys on your client for ssh for Savannah once. Use the exact hostname of the service you are using. The example here uses the git server but for svn it would be svn.savannah.gnu.org for example.

    ssh -o'HostkeyAlgorithms=+ssh-rsa' -o'PubkeyAcceptedAlgorithms=+ssh-rsa' git.savannah.gnu.org
   

   Having connected once ssh will update to any newer host keys that are available from the server. This needs to be done only once and then the above workaround can be removed.

For reference here are the release notes for OpenSSH 8.8. And additionally a bug ticket where we have been tracking information about this problem.

• https://www.openssh.com/txt/release-8.8
• https://savannah.nongnu.org/support/?110545

The above is up top in this document because it is a current problem. Below here continues with the previous more general documentation.

Short version

Set up your ssh key by typing in a terminal window on your local machine:

ssh-keygen -t ed25519

Then copy the contents of the resulting file ~/.ssh/id_ed25519.pub into the form at https://savannah.gnu.org/my/admin/editsshkeys.php (after logging in to the savannah web interface).

Debugging

You can test whether the problem is with your SSH setup or something on Savannah by running:

ssh yourlogin@download.savannah.gnu.org

If you get the following message:

Last login: Thu May 30 03:38:15 2024 from [...]
AGPL notice: sv_membersh is part of Savane.
In order to download the corresponding source code of Savane, run

  rsync [...]

You tried to execute:
Sorry, you are not allowed to execute that command.

Configuration file:

        /opt/savane/etc/savane/membersh-conf.pl

Available commands:

        rm:     %^rm ([[:alnum:]_/.-]+)%
        rmdir:  %^rmdir ([[:alnum:]_/.-]+)%
        rsync:  [...]
        scp:    %^scp( -[dprv])* (-t|-f) (-- )?([[:alnum:]_/.-]+)$%

Connection to download.savannah.gnu.org closed.

On VCS machines, the message you get is,

Hello yourlogin!  You've successfully authenticated, but interactive
shell access is not allowed.

Connection to git.savannah.gnu.org closed.

Then things are working okay for you. That illustrates that the login was successful and the access security on the server prevented the action. (Note that sv_membersh will offer the source code of Savane every time you invoke it unless you disable that offer in your Savannah account configuration, the 'Quiet SSH member shell' checkbox.)

If you fail an ssh login too many times in a short period of time then your IP address may be banned for a short time. Currently this is implemented by fail2ban using the default six failures in one minute bans your IP for ten minutes. This is only a temporary ban for ten minutes to rate limit hostile attacks. Wait ten minutes and try again.

Detailed version

Usually, if you can't access your version control (= VC, that is, cvs, svn, git, etc.) trees or your download area, it means your ssh access is not correctly configured. The remedy is to create a ssh key and/or register it properly.

If you're not member of any Savannah group, no account will be created on the system - you will have your web account, but not system access. A system account will be created after you become a member of at least one active group.

First, you need to create the ssh key. Typically, this is done by running the terminal command:

ssh-keygen -t ed25519

The public key will be created in the file ~/.ssh/id_ed25519.pub by default. It will ask you for a passphrase. This passphrase is used to encrypt your private key. Only you knowing this passphrase will be able to decrypt your private key and therefore only you will be able to use your private key. When using ssh for version control your passphrase is used locally by ssh. Savannah is NOT sent this passphrase. The passphrase decrypts your local ssh key which is used to authenticate your identity to the ssh daemon on Savannah. Your Savannah web password is not used for version control access. Only ssh is used for authenticated access for version control.

You must register your public key on the "My Account Configuration: Change Authorized Keys" page (https://savannah.gnu.org/my/admin/editsshkeys.php). After submitting, verify that the number of keys is what you expected.

You can register several public keys, which is often needed when you connect to Savannah from different computers. You can delete them when you do not use that key pair anymore.

Q: RSA or DSA?

We recommend against using DSA keys. We recommend using ED25519 keys.

Full details are at Jim's page. In short, on a system whose OpenSSL library has a weak pseudo-random number generator or PRNG (such as the one that shipped with Debian Etch in 2007-2008), DSA private keys can be easily deduced by an attacker that sniffed enough of your traffic.

This issue is not officially documented by the OpenSSH project, but the following posts in Debian mailing lists tend to confirm it:

• http://lists.debian.org/debian-devel/2008/05/msg00341.html
• http://lists.debian.org/debian-devel-announce/2008/05/msg00004.html

DSA keys are silently disabled on Alioth (prefixed by #DISABLED ON ALIOTH, use RSA keys instead#). Not sure about other Debian official services.

Remembering your passphrase

The ssh-agent program can remember your passphrase during your graphical X session (e.g., during your Gnome or KDE session).

ssh-agent may be already started for you (that's the case for most distros). Check its present using:

$ ssh-add -l
2048 e4:ff:b0:0c:ec:93:66:29:49:7e:04:2b:fd:ba:bf:d9 $HOME/.ssh/id_rsa (RSA)

If it says:

Could not open a connection to your authentication agent.

Then your ssh-agent is not configured properly. Fix that first.

Once ssh-agent is started, you need to register your password using ssh-add:

$ ssh-add
Enter passphrase for /home/me/.ssh/id_rsa:

# or:

$ ssh-add ~/.ssh/myotherkey
Enter passphrase for ~/.ssh/myotherkey:

After that, ssh will not ask for your passphrase anymore.

Verifying host fingerprints

If you get a warning about a fingerprint change, you can check the host fingerprint you have stored with for example:

$ ssh-keygen -l -F git.savannah.gnu.org

Your ~/.ssh/known_hosts file may have hostnames either plain or hashed. The newer default is hashed and the hostname will display as in the above. If plain then the hostname will display plainly instead of hashed. The md5 hash the important part.

The keys currently in use on vcs.savannah.gnu.org are the following, reported in all of the many various formats.

1024 80:5a:b0:0c:ec:93:66:29:49:7e:04:2b:fd:ba:2c:d5 (RSA)
256 65:b8:1c:2f:82:7c:0e:39:e1:4a:63:f2:13:10:e8:9c (ECDSA)
256 14:7b:c8:98:dd:06:08:97:8c:00:9d:d2:ae:85:c8:82 (ED25519)

1024 SHA256:FYkx0iik+iBeCLRzvUyUSTRT98TEBBJoYuQsTXbyGL8 (RSA)
256 SHA256:qRLLJ4w/GAeiDyYnbx4yWJbZXwGiYYxgNty7lAfUyuM (ECDSA)
256 SHA256:o/oI4CKKcWc4cZvDFEdmOXsE3tiPP8bWa04h4bQjtV4 (ED25519)

Here are samples of ~/known_hosts file entries that would be created upon TOFU (Trust On First Use) by ssh when connecting to the version control system server. Here I a giving an example without HashKnownHosts set because showing the hash here would not be useful for an example. The HOSTNAME.or.HASH.here is meant as a generic holder for that field because your system will have something different there and there are too many possible host names to document all of them.

HOSTNAME.or.HASH.here ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAzFQovi+67xa+wymRz9u3plx0ntQnELBoNU4SCl3RkwSFZkrZsRTC0fTpOKatQNs1r/BLFoVt21oVFwIXVevGQwB+Lf0Z+5w9qwVAQNu/YUAFHBPTqBze4wYK/gSWqQOLoj7rOhZk0xtAS6USqcfKdzMdRWgeuZ550P6gSzEHfv0=
HOSTNAME.or.HASH.here ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBP9c1Z2f4OHxymvLxqxQ/hY1g0ol0/iiXUrVFGZBBq4h5gD05c7Gw9rRrcrvF9XvumBvOghOQzDSZZLRWvFGocA=
HOSTNAME.or.HASH.here ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMnMLHxGS/b6Su98mL/J58FkpEJY/X1mONqhPBuFX5sJ

On the server-side (for Savannah Hackers):

root@vcs-noshell:/# ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key
1024 80:5a:b0:0c:ec:93:66:29:49:7e:04:2b:fd:ba:2c:d5 /etc/ssh/ssh_host_rsa_key.pub

Detailed troubleshooting

Lots more details of above and other less usual cases follow.

This following section is mostly about using ssh for cvs access and hasn't been updated for the many more recently added version control systems such as bzr, hg and git. The concepts are all the same however even if the details for other systems might be different.

• If, when (for example) you try to use cvs, you're rejected with Permission denied, that means that your key is not recognized. Generally, it means that your key is not a correct ssh2 key (the key registration page contains a sample key for you to compare). If you think you have done everything correctly, use the support manager (https://savannah.gnu.org/support/?group=administration) or write to savannah-help-public@gnu.org explaining your problem, providing copy/paste from the errors messages. It would also be good to provide the output from the following commands:

  ssh -v yourlogin@cvs.savannah.gnu.org  # ssh connection
  ssh-keygen -lf ~/.ssh/id_rsa.pub       # your key fingerprint
  cvs -t -d:ext:yourlogin@cvs.savannah.gnu.org/cvsroot/yourgroup co yourgroup
  

(Or whatever VC command, if you're not using cvs.)

• Another reason for CVS failure can be that the CVS_RSH environment variable isn't set to ssh, as in:

  export CVS_RSH=ssh  # Bourne-compatible shells
  setenv CVS_RSH ssh  # C shells
  

  Without this, cvs will be trying to use rsh instead of ssh for the connection, and rsh is not allowed (it's insecure by design):

  $ cvs commit -m 2021.08.30.103430
  cvs commit: Examining .
  cvs.sv.gnu.org: Connection timed out
  cvs [commit aborted]: end of file from server (consult above messages if any)
  

  As of 2020, distros often add a symlink to ssh instead of a real rsh; in this case, CVS_RSH isn't needed.

• Another problem can arise when you are trying to connect from behind a broken NAT router. During session setup, after the password has been given, OpenSSH sets the TOS (type of service) field in the IP datagram. Some broken routers are known to choke on this. This type of broken router is thankfully very infrequently seen these days. The effect is that your session hangs indefinitely after you gave your password. Here is the example output from such an ssh session:

  user@localhost:~$ ssh -vvv {user-name}@cvs.savannah.gnu.org
  OpenSSH_4.7p1 Debian-8ubuntu1.2, OpenSSL 0.9.8g 19 Oct 2007
  debug1: Reading configuration data /etc/ssh/ssh_config
  [...]
  Enter passphrase for key '{homedir}/.ssh/id_rsa':
  debug1: read PEM private key done: type RSA
  debug1: Authentication succeeded (publickey).
  [...]
  debug2: fd 5 setting TCP_NODELAY
  debug2: callback done
  debug2: channel 0: open confirm rwindow 0 rmax 32768
  

and from here on the session hangs.

The fix is to make ssh send all its traffic via netcat, because netcat won't set the TOS field. For this to work, you need to have netcat installed. You can test this by entering at the command line:

user@localhost:~$ which nc

and if you get a path back, like:

/bin/nc

then you probably have netcat installed. For the very cautious, you could also issue:

user@localhost:~$ nc -h

and look at the upcoming help text. If you don't have netcat, you can find it at http://netcat.sourceforge.net/. You may also want to try the packaging system which comes with your operating system distribution.

Once you found that you have netcat installed, issue the following command to test whether the netcat route solves your problem:

ssh -o "ProxyCommand nc %h %p" {user-name}@cvs.savannah.gnu.org

where {user-name} is your savannah login name. For a successfull login, you should get an output similar to this (with no hanging, i.e. you get a prompt afterwards):

user@localhost:~$ ssh -o "ProxyCommand nc %h %p" {user-name}@cvs.savannah.gnu.org
Enter passphrase for key '{home-dir}/.ssh/id_rsa':
Last login: {datetime} from {ip-adr}
You tried to execute:
Sorry, you are not allowed to execute that command.
Connection to cvs.savannah.gnu.org closed.
user@localhost:~$

If you find that your login works via the netcat route, then you can make it permanent by adding a directive to the ssh config file '\~/.ssh/config' (or, if that file doesn't exist, create it):

ProxyCommand nc %h %p

Here's an example ssh config file in a user's home folder (/home/user/.ssh/config):

# This is the ssh client user configuration file.  See
# ssh_config(5) for more information.  This file provides defaults for
# this user, and the values can be changed on the command line.
#
# Configuration data is parsed as follows:
#  1. command line options
#  2. user-specific file
#  3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.
#
# Directive to overcome TOS issue with our NAT router. During session setup,
# OpenSSH sets the TOS (type of service) field after the user has submitted
# the password. Some routers are known to choke on this, with the result
# that the session hangs during buildup. As workaround we send our traffic
# via netcat which doesn't set the TOS field.
ProxyCommand nc %h %p

It's advisable to put the comments as well, otherwise six months later you may find yourself wondering what that directive is all about??

You could also add this directive to your global ssh config file (/etc/ssh/ssh_config), but this change would be system wide, and not all users on your system may appreciate that change.

• I have several SSH keys, how do I get the SSH client to select the appropriate one?

• You can use 'ssh-agent' and 'ssh-add' to remember your key and passphrase. Then the SSH client will try all the remembered keys.

• You can explicitly specify the key to use in your '\~/.ssh/config':

  Host cvs.*gnu.org
    IdentityFile ~/.ssh/id_rsa_savannah
  

• You can also use a wrapper script:

  echo <<EOF > ~/bin/ssh_savannah
  #!/bin/bash
  /usr/bin/ssh -i ~/.ssh/id_rsa_savannah $*
  EOF
  export CVS_RSH=~/bin/ssh_savannah
  

• My key has several lines, how do I enter it? We only support free implementations of SSH, such as http://www.openssh.org/. If your public key is several lines long, and begins with ---- BEGIN SSH2 PUBLIC KEY ----, then you are using a proprietary version that we do not support.

• When you try to use cvs, it will reports the authenticity of host subversions.gnu.org cannot be established, RSA key fingerprint is 80:5a:b0:0c:ec:93:66:29:49:7e:04:2b:fd:ba:2c:d5. Why RSA here and not DSA? This is the RSA fingerprint of the Savannah site-wide server key. It is used to verify that the site you are connecting to is well GNU Savannah, and not a fake website. It is totally different from your SSH key.

• What about authorized_keys? Upon attempted login, this user key is checked against the Savannah MySQL database, using the AuthorizedKeysCommand command defined in vcs0:/etc/ssh/sshd_config.