Still unable to 'git push' or ssh to sourceware

Still unable to 'git push' or ssh to sourceware

[Mark Geisert]

Apologies for my continued stumbling around with this.  I'm enough of a 
newbie in several necessary skills that I can't seem to get a handle on 
what's going wrong.

I had assumed that having sent my "SSH key for upload access", it goes to 
the same location as my original key supplied on the 
sourceware.org/cgi-bin/pdw/ps_form.cgi form.  That original 
key I supplied always provoked an 'enter passphrase' prompt when ssh or 
git contacted sourceware even though I had never supplied a passphrase 
for it.  OK, maybe sourceware requires passphrases so I generated a new 
key with a passphrase.  That's the key I sent recently as "SSH key for 
upload access".

The only way I could think of to test authentication without doing 
anything potentially damaging was this command:
     ssh -v -v mgeisert@sourceware.org appendkey < /dev/null

Here's the resulting debug log:
OpenSSH_6.9p1, OpenSSL 1.0.2d 9 Jul 2015
debug1: Reading configuration data /home/Mark/.ssh/config
debug1: /home/Mark/.ssh/config line 1: Applying options for sourceware.org
debug1: Reading configuration data /etc/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to sourceware.org [209.132.180.131] port 22.
debug1: Connection established.
debug1: identity file /home/Mark/.ssh/id_dsa.pub type 2
debug1: key_load_public: No such file or directory
debug1: identity file /home/Mark/.ssh/id_dsa.pub-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.9
debug1: Remote protocol version 1.99, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to sourceware.org:22 as 'mgeisert'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: 
curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: 
ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-dss
debug2: kex_parse_kexinit: 
chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: 
chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: 
umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: 
umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: 
diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: 
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: 
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: 
hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: 
hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug1: kex: server->client aes128-ctr umac-64@openssh.com none
debug1: kex: client->server aes128-ctr umac-64@openssh.com none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<8192) sent
debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
debug2: bits set: 1509/3072
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: got SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: ssh-rsa 
SHA256:MFNiczzfX8/nvLSRZwR3CxMyycKtMan64Zm4C373FeM
debug1: Host 'sourceware.org' is known and matches the RSA host key.
debug1: Found key in /home/Mark/.ssh/known_hosts:2
debug2: bits set: 1537/3072
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/Mark/.ssh/id_dsa.pub (0x60006b840), explicit
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering DSA public key: /home/Mark/.ssh/id_dsa.pub
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

Can anybody reading this see a any evidence of what's amiss?
Thanks much,

..mark

Re: Still unable to 'git push' or ssh to sourceware

[Yaakov Selkowitz]

On Mon, 2015-11-09 at 17:54 -0800, Mark Geisert wrote:
> Apologies for my continued stumbling around with this.  I'm enough of a 
> newbie in several necessary skills that I can't seem to get a handle on 
> what's going wrong.
> 
> I had assumed that having sent my "SSH key for upload access", it goes to 
> the same location as my original key supplied on the 
> sourceware.org/cgi-bin/pdw/ps_form.cgi form.

Incorrect.  Upload access is completely separate from shell access to
sourceware, and neither implies or requires the other.

--
Yaakov

Re: Still unable to 'git push' or ssh to sourceware

[Mark Geisert]

On Mon, 9 Nov 2015, Yaakov Selkowitz wrote:
> On Mon, 2015-11-09 at 17:54 -0800, Mark Geisert wrote:
>> I had assumed that having sent my "SSH key for upload access", it goes to
>> the same location as my original key supplied on the
>> sourceware.org/cgi-bin/pdw/ps_form.cgi form.
>
> Incorrect.  Upload access is completely separate from shell access to
> sourceware, and neither implies or requires the other.

Thanks for that.  I need to update my shell access key but I can't make 
use of the appendkey trick, catch-22.  Sounds like I should contact 
overseers then.

..mark

Re: Still unable to 'git push' or ssh to sourceware

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1790 bytes --]

On Nov  9 17:54, Mark Geisert wrote:
> Apologies for my continued stumbling around with this.  I'm enough of a
> newbie in several necessary skills that I can't seem to get a handle on
> what's going wrong.
> 
> I had assumed that having sent my "SSH key for upload access", it goes to
> the same location as my original key supplied on the
> sourceware.org/cgi-bin/pdw/ps_form.cgi form.  That original key I supplied
> always provoked an 'enter passphrase' prompt when ssh or git contacted
> sourceware even though I had never supplied a passphrase for it.  OK, maybe
> sourceware requires passphrases so I generated a new key with a passphrase.

You're missing something important.  The key you sent to sware and the
other key you sent to the cygwin-apps list are both the public part of
your keys.  This public part of a key *never* requires a passphrase.
After all it's supposed to be readable by everyone, right?

If ssh asks for a passphrase, it's your local, *private* key which is
encrypted using this passphrase.  Therefore this has nothing to do with
ssh on the remote machine.  It can't require passphrases since,
obviously, it doesn't know your private key.  The private key never
leaves your local machine.  So this asking for a passphrase is a local
problem on your machine which you would have to fix locally.

Btw., I never saw the problem that a local key without passphrase results
in ssh asking for a passphrase.  The difference in the keyfile (encrypted
vs. non-encrypted) is obvious to ssh:

  $ head -2 .ssh/my_key
  -----BEGIN RSA PRIVATE KEY-----
  Proc-Type: 4,ENCRYPTED


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Still unable to 'git push' or ssh to sourceware -- resolved

[Mark Geisert]

On Tue, 10 Nov 2015, Corinna Vinschen wrote:
> You're missing something important.  The key you sent to sware and the
> other key you sent to the cygwin-apps list are both the public part of
> your keys.  This public part of a key *never* requires a passphrase.
> After all it's supposed to be readable by everyone, right?
>
> If ssh asks for a passphrase, it's your local, *private* key which is
> encrypted using this passphrase.  Therefore this has nothing to do with
> ssh on the remote machine.  It can't require passphrases since,
> obviously, it doesn't know your private key.  The private key never
> leaves your local machine.  So this asking for a passphrase is a local
> problem on your machine which you would have to fix locally.
>
> Btw., I never saw the problem that a local key without passphrase results
> in ssh asking for a passphrase.  The difference in the keyfile (encrypted
> vs. non-encrypted) is obvious to ssh:
>
>  $ head -2 .ssh/my_key
>  -----BEGIN RSA PRIVATE KEY-----
>  Proc-Type: 4,ENCRYPTED

Many thanks for this correction to my broken mental model of passphrases 
vs passwords.  Between these nuggets-o-knowledge and a fix to my 
~/.ssh/config (i.e. IdentityFile *must* refer to a private key file) I was 
able to 'git push' my cygutils updates to sourceware with my original key.

I am now debugging a revised cygutils.cygport and figuring out where I can 
host the updated tar.xz packages for review.  I've got a place in mind.
Thanks again,

..mark