[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Savannah-cvs] [126] more about ssh debugging
From: |
karl |
Subject: |
[Savannah-cvs] [126] more about ssh debugging |
Date: |
Fri, 02 Jan 2015 22:23:57 +0000 |
Revision: 126
http://svn.sv.gnu.org/viewvc/?view=rev&root=administration&revision=126
Author: karl
Date: 2015-01-02 22:23:48 +0000 (Fri, 02 Jan 2015)
Log Message:
-----------
more about ssh debugging
Modified Paths:
--------------
trunk/sviki/SshAccess.mdwn
Modified: trunk/sviki/SshAccess.mdwn
===================================================================
--- trunk/sviki/SshAccess.mdwn 2014-12-09 16:44:10 UTC (rev 125)
+++ trunk/sviki/SshAccess.mdwn 2015-01-02 22:23:48 UTC (rev 126)
@@ -1,54 +1,75 @@
+ssh and savannah
+================
+
Short version
-------------
+Set up your ssh key by typing in a terminal window on your local machine:
-Set up your SSH key by typing in a terminal window on your local machine:
-
ssh-keygen
Then copy the contents of the resulting file `~/.ssh/id_rsa.pub` into
the form at <https://savannah.gnu.org/my/admin/editsshkeys.php>
(after logging in to the savannah web interface).
+Debugging
+---------
+Zeroth: if you just registered your ssh key a few minutes ago, please
+wait for an hour and try again.
+
+First: ssh != gpg. GPG keys are not used for Savannah operations. You
+have to create and register an ssh key.
+
+Second: ssh access is relevant only for members of a given project,
+primarily to access the source and webpages repositories. If you are
+not a project member, you can do anonymous checkouts, but not member
+checkouts using ssh; details on the various Source Code Manager pages.
+
+Third: you can test whether the problem is with your ssh setup or
+something on Savannah by running:
+
+ ssh vcs.savannah.gnu.org
+
+If you get a message "Permission denied", ssh is almost certainly set up
+improperly: to repeat, either your ssh key does not exist on your host,
+or is not registered on Savannah. Running `ssh -vvv` might yield more
+clues. (If, on the other hand, you get a human-written message from the
+host about "Interactive shell login is not allowed ...", that means the
+ssh connection succeeded and something else is awry.)
+
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.
-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
+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:
+First, you need to create the ssh key. Typically, this is done by
+running the terminal command:
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'.
+will be created in the file `~/.ssh/id_rsa.pub` by default.
-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 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 publish several public keys, which is often needed when you
-connect to Savannah from different computers. You can delete them when
+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.
-Wait for the next cron job (in the worst case, 1 hour).
+Wait for the next cron job (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
@@ -59,8 +80,8 @@
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:
+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>
@@ -71,9 +92,8 @@
Remembering your passphrase
---------------------------
-
The `ssh-agent` program can remember your passphrase during your
-graphical X session (e.g. during your Gnome or KDE session).
+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:
@@ -92,15 +112,15 @@
$ ssh-add ~/.ssh/myotherkey
Enter passphrase for ~/.ssh/myotherkey:
-After that, `ssh` will not ask you your passphrase anymore.
+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 your stored with:
+fingerprint you have stored with, e.g.,:
- $ ssh-keygen -l -f ~/.ssh/known_hosts | grep cvs.sv.gnu.org
+ $ ssh-keygen -l -f ~/.ssh/known_hosts | grep vcs.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:
@@ -111,27 +131,24 @@
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-keyscan -t rsa cvs.sv.gnu.org > tmpkey
+ ...
$ 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
+ 1024 80:5a:b0:0c:ec:93:66:29:49:7e:04:2b:fd:ba:2c:d5 cvs.sv.gnu.org (RSA)
On the server-side (for Savannah Hackers):
address@hidden:/# 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
- address@hidden:/# 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
----------------
+Detailed troubleshooting
+------------------------
+Lots more details of above and other less usual cases follow.
-- If, when (for example) you try to use CVS, you're rejected with
- `Permission denied (publickey).`, that means that your key is not
+- If, when (for example) you try to use cvs, you're rejected with
+ `Permission denied`, 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
+ 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>)
@@ -141,22 +158,21 @@
messages. It would also be good to provide the output from the
following commands:
+ ssh -v address@hidden # ssh connection
+ ssh-keygen -lf ~/.ssh/id_rsa.pub # your key fingerprint
cvs -t -d:ext:address@hidden/cvsroot/yourproject co yourproject
- ssh -v address@hidden
+
+ (Or whatever VC command, if you're not using cvs.)
- Another reason for rejection as above can be that you failed to
- execute the command:
+ set the `CVS_RSH` environment variable to `ssh`, as in:
- export CVS_RSH=ssh
+ export CVS_RSH=ssh # Bourne-compatible shells
+ setenv CVS_RSH ssh # C shells
- before trying to access CVS on a GNU/Linux machine, or:
+ 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).
- 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
@@ -177,7 +193,7 @@
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:
@@ -270,22 +286,23 @@
> /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
+
+- My key has several lines, how do I enter it? 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
+ <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`? `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.)
+ public keys you upload 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 vm.)
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Savannah-cvs] [126] more about ssh debugging,
karl <=