Shell access in general

Savannah does not provide shell accounts for users, since running arbitrary commands is far too large an attack vector. We do use the Unix login mechanism and SshAccess but only certain commands can be run to do, e.g., vc operations. (Validation is done against databases on internal.)

Savane distributes sv_membersh, a simple Perl script, that loads another Perl script in /etc for configuration. Using a Perl script as a login shell may yeld some efficiency concerns. However, this is what we currently do on Savannah; efficiency here has not been a problem.

Another tool is rssh ( This package does not check the command line arguments to cvs (in util.c), though it faced some security issues that sv_membersh was also vulnerable to ( It is interesting to check upon that tool even if we do not use it for that reason. This package is in C but looks somewhat bloated, so maybe it is not a good idea to use it (plus we'd have to patch the CVS validation).

Shell access (as root) for Savannah workers

For those working on savannah itself (support requests, development, etc.), shell and root access may be needed. (It is not needed to handle new project submissions, and it's a good idea to do those for a while before worrying about things at the shell level.) Generally, the idea to date has been to log in directly as root, with your ssh keys installed in the necessary places. For most hosts, ssh has to go through or another known location, as they are not open to the whole Internet.

So, the first step is to get ssh access to fencepost. If you don't have that already, see After that, an existing savannah worker can enable your access to savannah. (By adding the key to mgt:/root/.ssh/authorized_keys (in the right section, please) and running mgt:/root/bin/push-root-authkeys. See comments in those files.)

You may find it convenient to automatically proxy ssh through fencepost, along these lines:

Host *
  User root
  ProxyCommand ssh -W %h:%p
Host *
  User root
  ProxyCommand ssh -W %h:%p

Beware of unintentionally trying to do normal vc checkouts as root as a result, though. Understand what you're doing. SavannahArchitecture lists the various hosts.

FYI, you can also log in to (as user list) from; see ListServer for tasks that this is needed for.

Shell access (as separate user) for Savannah workers

Some sv workers like to have personal accounts on the servers. The best approach for this is to have it be completely separate from normal user-level savannah access. Here was the process for luca in April 2014:

  1. Set up a normal account in the web interface to avoid someone later claiming the name. But this should not be used for other purposes.

  2. On internal, get the assigned uid:

    mysql -u root -p select uidnumber from savane.user where user_name='luca'; ... 130932 ...

This number is different from the user_id field which shows up in the savannah profile as the "Id:"

  1. On mgt, add the obvious passwd entry using that uid. It's not technically necessary that the uid's match, but it seems cleaner to avoid possible conflicts.

  2. In Luca's case, the only need was for access to, for audio-video maintenance. So the account on mgt can't log in. On dl, copy in the new passwd entry, make the shell /bin/bash, make the /etc/shadow entry.

  3. On dl, add luca to savannahroot in /etc/group. This allows sudo.

  4. On dl, create /etc/ssh/authorized_keys/luca with his pub keys. This lets him log in.

Bitter truth: the above is the clean way to do it. However, previous sv shell accounts that have been set up (karl, rdoyle, mjflick) conflated shell access and savannah web access. Obviously this can work and be a bit more convenient, and equally obviously it makes the default VC checkout paths and other things fail. I (Karl) am not going to explain all that here. If you don't know what I'm talking about or can't figure it out, don't create such an account :).