I think the posts get a bit maimed because google anonymizes the email
addresses to prevent spam harvesting. You need to use "git at" in front of
the hostname to test your ssh keys. As for the hostname, both
git.sagemath.org and trac.sagemath.org work. But you can't use "myusername
at {git,trac}.sagemath.org" unless you are one of the server admins.
On Wednesday, June 29, 2016 at 10:56:17 AM UTC+2, Erik Bray wrote:
>
> On Wed, Jun 29, 2016 at 9:19 AM, Volker Braun <vbrau...@gmail.com
> <javascript:>> wrote:
> > You can't ssh into trac. What should work is:
> >
> > $ ssh g...@git.sagemath.org <javascript:>
> > PTY allocation request failed on channel 0
> > hello vbraun, this is git@trac running gitolite3 3.5.3.1-2 (Debian) on
> git
> > 1.9.1
> >
> > R W sage
>
> I'm not so sure if this is the issue. git.sagemath.org and
> trac.sagemath.org are both (currently) the same server, and nothing
> about the SSH or gitolite configuration cares which hostname you use:
>
> $ ssh g...@trac.sagemath.org <javascript:>
> Enter passphrase for key '/home/embray/.ssh/id_rsa':
> PTY allocation request failed on channel 0
> hello embray, this is git@trac running gitolite3 3.5.3.1-2 (Debian) on git
> 1.9.1
>
> R W gitolite-admin
> R W sage
> Connection to trac.sagemath.org closed.
>
> It's possible that gitolite is not working correctly. I had a problem
> with this myself recently, but thought maybe it was just something
> with me, since I was messing around with my keys quite a bit in
> gitolite. But it's possible something else is stuck somehow (though
> it was definitely working at one point).
>
> For anyone unfamiliar, gitolite is the program that manages
> authorization for git repositories when connecting via SSH as the
> "git" user. When you add a new SSH key (i.e. through the Trac
> interface) it adds your key to gitolite in such a way that it
> associates that key with your username. It is then *supposed* to
> regenerate the .ssh/authorized_keys for git. But it's possible it's
> not correctly regenerating the authorized_keys file, and so you'll get
> permission denied even though you think you've added your key.
>
>
> Tara: I just confirmed in the gitolite logs that you did add your new
> keys, but that the update to the authorized_keys file seems to have
> failed. I have manually added your public key for now so you should
> be able to connect now, I think. In the meantime I will investigate
> why gitolite seems to be stuck.
>
> > On Tuesday, June 28, 2016 at 11:26:32 PM UTC+2, tara fife wrote:
> >>
> >> I wasn't able to push changes to trac, and I thought the problem had to
> do
> >> with the ssh key, so I reset it, and now I can't connect at all. I'm
> using
> >> an Ubuntu 14.04, and I've also tried to connect via a Kbuntu 12.04.
> >>
> >> When I run ``ssh -v g...@trac.sagemath.org``, I get the following
> error.
> >>
> >> OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
> >> debug1: Reading configuration data /etc/ssh/ssh_config
> >> debug1: /etc/ssh/ssh_config line 19: Applying options for *
> >> debug1: Connecting to trac.sagemath.org [104.197.143.230] port 22.
> >> debug1: Connection established.
> >> debug1: identity file /home/tara/.ssh/id_rsa type 1
> >> debug1: identity file /home/tara/.ssh/id_rsa-cert type -1
> >> debug1: identity file /home/tara/.ssh/id_dsa type -1
> >> debug1: identity file /home/tara/.ssh/id_dsa-cert type -1
> >> debug1: identity file /home/tara/.ssh/id_ecdsa type -1
> >> debug1: identity file /home/tara/.ssh/id_ecdsa-cert type -1
> >> debug1: identity file /home/tara/.ssh/id_ed25519 type -1
> >> debug1: identity file /home/tara/.ssh/id_ed25519-cert type -1
> >> debug1: Enabling compatibility mode for protocol 2.0
> >> debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.7
> >> debug1: Remote protocol version 2.0, remote software version
> >> OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.7
> >> debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.7 pat OpenSSH_6.6.1*
> compat
> >> 0x04000000
> >> debug1: SSH2_MSG_KEXINIT sent
> >> debug1: SSH2_MSG_KEXINIT received
> >> debug1: kex: server->client aes128-ctr hmac-m...@openssh.com none
> >> debug1: kex: client->server aes128-ctr hmac-m...@openssh.com none
> >>
> >>
> >> debug1: sending SSH2_MSG_KEX_ECDH_INIT
> >> debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
> >> debug1: Server host key: ECDSA
> >> 5b:97:c8:74:a6:c4:e4:55:d1:13:8a:84:a3:85:25:6f
> >> debug1: Host 'trac.sagemath.org' is known and matches the ECDSA host
> key.
> >> debug1: Found key in /home/tara/.ssh/known_hosts:1
> >> debug1: ssh_ecdsa_verify: signature correct
> >> debug1: SSH2_MSG_NEWKEYS sent
> >> debug1: expecting SSH2_MSG_NEWKEYS
> >> debug1: SSH2_MSG_NEWKEYS received
> >> debug1: SSH2_MSG_SERVICE_REQUEST sent
> >> debug1: SSH2_MSG_SERVICE_ACCEPT received
> >> debug1: Authentications that can continue: publickey
> >> debug1: Next authentication method: publickey
> >> debug1: Offering RSA public key: /home/tara/.ssh/id_rsa
> >> debug1: Authentications that can continue: publickey
> >> debug1: Trying private key: /home/tara/.ssh/id_dsa
> >> debug1: Trying private key: /home/tara/.ssh/id_ecdsa
> >> debug1: Trying private key: /home/tara/.ssh/id_ed25519
> >> debug1: No more authentication methods to try.
> >> Permission denied (publickey).
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups
> > "sage-devel" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an
> > email to sage-devel+...@googlegroups.com <javascript:>.
> > To post to this group, send email to sage-...@googlegroups.com
> <javascript:>.
> > Visit this group at https://groups.google.com/group/sage-devel.
> > For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
