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 internal0.)

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 yield 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).

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 fencepost.gnu.org 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 GNU accounts README. After that, an existing Savannah worker can enable your access to Savannah. (By adding the key to mgt1:/root/.ssh/authorized_keys (in the right section, please). See comments in those files.)

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

Host *.savannah.gnu.org *.sv.gnu.org
  User root
  ProxyCommand ssh -W %h:%p fencepost.gnu.org

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.

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 internal0, 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:" https://savannah.gnu.org/users/luca.

  1. On mgt1, 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 download0.savannah.gnu.org, for audio-video maintenance. So the account on mgt0 can't log in. On download0, copy in the new passwd entry, make the shell /bin/bash, make the /etc/shadow entry.

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

  4. On download0, 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 :).

Note from Bob : Having a local account on vcs0 or download0 of the same name as your Savannah account name will conflict with normal use of that account for vcs and download activities. Therefore two of us, rwp and agn, have rwplocal and agnlocal accounts with different names in order to avoid the name collision conflict. The advice further above to create an identical account name and uid probably works for audio-video because which isn't a Savannah service.