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.)
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
This package does not check the command line arguments to
util.c), though it faced some security issues that
sv_membersh was also
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
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 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
http://www.gnu.org/software/README.accounts.html. 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
You may find it convenient to automatically proxy ssh through fencepost, along these lines:
Host *.savannah.gnu.org User root ProxyCommand ssh -W %h:%p fencepost.gnu.org Host *.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.
FYI, you can also log in to lists.gnu.org (as user list) from email@example.com; 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
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.
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:" https://savannah.gnu.org/users/luca.
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.
In Luca's case, the only need was for access to download.sv.gnu.org, 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
On dl, add luca to savannahroot in /etc/group. This allows sudo.
On dl, create
/etc/ssh/authorized_keys/lucawith 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 :).