Still unable to 'git push' or ssh to sourceware

2015-11-09 Thread 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 mgeis...@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 0x0c00
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-sha...@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-...@openssh.com,ssh-rsa-cert-...@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ssh-ed25519-cert-...@openssh.com,ssh-dss-cert-...@openssh.com,ssh-dss-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-dss
debug2: kex_parse_kexinit: 
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se
debug2: kex_parse_kexinit: 
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se
debug2: kex_parse_kexinit: 
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-...@openssh.com,hmac-ripemd160-...@openssh.com,hmac-sha1-96-...@openssh.com,hmac-md5-96-...@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: 
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-...@openssh.com,hmac-ripemd160-...@openssh.com,hmac-sha1-96-...@openssh.com,hmac-md5-96-...@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: none,z...@openssh.com,zlib
debug2: kex_parse_kexinit: none,z...@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-...@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-...@lysator.liu.se
debug2: kex_parse_kexinit: 
hmac-md5,hmac-sha1,umac...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: 
hmac-md5,hmac-sha1,umac...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: none,z...@openssh.com
deb

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

2015-11-09 Thread 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

2015-11-09 Thread 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

2015-11-10 Thread Corinna Vinschen 
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


pgptQiupHXZVK.pgp
Description: PGP signature

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

2015-11-12 Thread 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