Edit detail for SshAccess revision 24 of 24

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Editor: karlberry
Time: 2011/08/15 23:39:46 GMT+0
Note: mention sv_authorized_keys cron

changed:
-* What about ``authorized_keys``? ``authorized_keys`` is maintained on the server side, at Savannah. This is done automatically, based on the public keys you uploaded to the web interface.
-
-
-From jexinwej Sat Aug 4 21:45:51 +0000 2012
-From: jexinwej
-Date: Sat, 04 Aug 2012 21:45:51 +0000
-Subject: 1
-Message-ID: <20120804214551+0000@savannah.gnu.org/maintenance>
-In-Reply-To: 1
-
-1
-
-From jexinwej Sat Aug 4 21:51:59 +0000 2012
-From: jexinwej
-Date: Sat, 04 Aug 2012 21:51:59 +0000
-Subject: 1
-Message-ID: <20120804215159+0000@savannah.gnu.org/maintenance>
-In-Reply-To: <20120804214549 0000@savannah.gnu.org/maintenance>
-
-1
* What about ``authorized_keys``? ``authorized_keys`` is maintained on the server side, at Savannah. This is done automatically, based on the public keys you uploaded to the web interface.  (Savannah admin info: specifically, in /etc/ssh/authorized_keys/USERNAME on the subhosts; a cron job sv_authorized_keys runs on each subhost.)


Short version

Set up your SSH key by typing in a terminal:

ssh-keygen

Then copy ~/.ssh/id_rsa.pub in https://savannah.gnu.org/my/admin/editsshkeys.php (once logged in to savannah).

Detailed version

Generally, if you can't access your version control (= VC, that is, CVS, SVN, etc.) trees or your download area, it means your SSH access is not correctly configured. The only thing to do is to create a ssh-key and register it.

Note that if you're not member of any project, no account will 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 project.

First, you need to create the ssh-key. In general, this is done by using:

ssh-keygen

It will ask you for a passphrase. Only this passphrase will be accepted for VC or scp authentication, not the Savannah password. The public key will be placed at '~/.ssh/id_rsa.pub'.

You must register your public key in the Account Maintenance page (https://savannah.gnu.org/my/admin/editsshkeys.php). Make sure there are no line breaks except between keys - more information in the Account Maintenance page. After submitting, verify that the number of keys in your file is what you expected.

You can publish 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.

Wait for the next cron job (in the worst case, 1 hour).

Try to download your CVS tree (take a look at your CVS project page - or read CvsImportExistingProject)

Q: RSA or DSA?

We recommend using only RSA keys, not DSA.

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.

Note that this issue is not officially documented by the OpenSSH project. The following posts in Debian mailing lists tend to confirm it:

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:

$ echo $SSH_AGENT_PID - $SSH_AUTH_SOCK
3536 - /tmp/keyring-6Q9l0p/ssh

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 you your passphrase anymore.

Verifying host fingerprints

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

$ ssh-keygen -l -f ~/.ssh/known_hosts | grep cvs.sv.gnu.org
1024 80:5a:b0:0c:ec:93:66:29:49:7e:04:2b:fd:ba:2c:d5 cvs.sv.gnu.org

or if your known_hosts file is hashed:

$ ssh-keygen -F cvs.sv.gnu.org > tmpkey
$ ssh-keygen -l -f tmpkey
1024 80:5a:b0:0c:ec:93:66:29:49:7e:04:2b:fd:ba:2c:d5 |1|/PZ6wITZ4GG+4XtGUy1FgzqaH8M=|uci92Jr08MGVxZAeofx2JHS/lfw=

To verify the keys currently in use at Savannah:

$ ssh-keyscan -t rsa,dsa cvs.sv.gnu.org > tmpkey
# cvs.sv.gnu.org SSH-2.0-OpenSSH_4.3p2 Debian-9
# cvs.sv.gnu.org SSH-2.0-OpenSSH_4.3p2 Debian-9
$ ssh-keygen -l -f tmpkey
1024 4d:c8:dc:9a:99:96:ae:cc:ce:d3:2b:b0:a3:a4:95:a5 cvs.sv.gnu.org
1024 80:5a:b0:0c:ec:93:66:29:49:7e:04:2b:fd:ba:2c:d5 cvs.sv.gnu.org

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
root@vcs-noshell:/# ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key
1024 4d:c8:dc:9a:99:96:ae:cc:ce:d3:2b:b0:a3:a4:95:a5 /etc/ssh/ssh_host_dsa_key.pub

Troubleshooting

  • If, when (for example) you try to use CVS, you're rejected with Permission denied (publickey)., that means that your key is not recognized. It could be a matter of time (cron job) or, 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:

    cvs -t -d:ext:yourlogin@cvs.savannah.gnu.org/cvsroot/yourproject co yourproject
    ssh -v yourlogin@cvs.savannah.gnu.org
    
  • Another reason for rejection as above can be that you failed to execute the command:

    export CVS_RSH=ssh
    

    before trying to access CVS on a GNU/Linux machine, or:

    setenv CVS_RSH ssh
    

    if you are using a Macintosh under OS/X since without this setting your machine will be trying to use rsh instead of ssh for the connection.

  • Another problem can arise when you are trying to connect from behind a NAT router using OpenSSH?. During session setup, after the password has been given, OpenSSH? sets the TOS (type of service) field in the IP datagram. Some routers are known to choke on this. 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? Well, note that we only support free implementations of SSH, such as http://www.openssh.org. If you 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 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? authorized_keys is maintained on the server side, at Savannah. This is done automatically, based on the public keys you uploaded to the web interface. (Savannah admin info: specifically, in /etc/ssh/authorized_keys/USERNAME on the subhosts; a cron job sv_authorized_keys runs on each subhost.)