0

Problem: Can't push using Git from Windows to Linux. Also can't connect to git user over ssh.

Update #1: I changed "PasswordAuthentication" to no and tested. Key did not work, but password did. Obviously has to be something to do with the ssh-rsa key.

Update #2: Tried generating a brand new key that is different from the one on my user account. Still refuses the key, same issue.

Update #3: Problem solved and answer has been posted. Logs were actually useless due to the fact that I was using a program that couldn't read .ppk files.

Running CentOS 6.4, entire drive is encrypted, home folders are not encrypted.

I am using git on windows to push to a git repo on server. Basically following this: http://git-scm.com/book/en/Git-on-the-Server-Setting-Up-the-Server

I had it working before just fine on fedora & debian... but not sure what happened here. The first thing I thought it could have been was the home folder being encrypted, but folders are not encrypted.

I tried copying the key again and deleting the user and adding him back. I tried connecting to the 'git' user using just ssh and I got the log below. Not exactly sure what the is causing the issue.

Here is my config file on my windows machine.

Fetch & Pull is: ssh://name1/opt/git/git.project

Config file:

Host name1
    HostName name2.com
    Port 12345
    User git
    IdentityFile ~/.ssh/private_key.ppk

Here is what happens:

USER_NAME@MY-PC ~/Documents/Workspace/git.project (master)
$ ssh -vT -p 12345 -i "C:/Users/USER_NAME/.ssh/private_key.ppk" git@WEB_NAME.
com
OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007
debug1: Reading configuration data /c/Users/USER_NAME/.ssh/config
debug1: Connecting to WEB_NAME.com [--.--.--.--] port 12345.
debug1: Connection established.
debug1: identity file C:/Users/USER_NAME/.ssh/private_key.ppk type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '[WEB_NAME.com]:12345' is known and matches the RSA host key.
debug1: Found key in /c/Users/USER_NAME/.ssh/known_hosts:1
debug1: ssh_rsa_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,gssapi-keyex,gssapi-with-mi
c
debug1: Next authentication method: publickey
debug1: Trying private key: C:/Users/USER_NAME/.ssh/private_key.ppk
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key 'C:/Users/USER_NAME/.ssh/private_key.ppk':
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key 'C:/Users/USER_NAME/.ssh/private_key.ppk':
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key 'C:/Users/USER_NAME/.ssh/private_key.ppk':
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Updated Log:

USER_NAME@MY-PC /c/Windows/system32
$ ssh -vT -v -v -p SSH_PORT -i "C:/Users/USER_NAME/.ssh/git/private_key.ppk" gi
t@WEB_NAME.com
OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007
debug1: Reading configuration data /c/Users/USER_NAME/.ssh/config
debug2: ssh_connect: needpriv 0
debug1: Connecting to WEB_NAME.com [--.--.--.--] port SSH_PORT.
debug1: Connection established.
debug3: Not a RSA1 key file C:/Users/USER_NAME/.ssh/git/private_key.ppk.
debug2: key_type_from_name: unknown key type 'PuTTY-User-Key-File-2:'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'Encryption:'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'Comment:'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'Public-Lines:'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type 'Private-Lines:'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type 'Private-MAC:'
debug3: key_read: missing keytype
debug1: identity file C:/Users/USER_NAME/.ssh/git/private_key.ppk type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.6
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-g
roup-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1
28,arcfour256,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-c
tr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1
28,arcfour256,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-c
tr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],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-g
roup-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,arcfour12
8,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rij
[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour12
8,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rij
[email protected]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160
,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160
,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 123/256
debug2: bits set: 507/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: put_host_port: [--.--.--.--]:SSH_PORT
debug3: put_host_port: [WEB_NAME.com]:SSH_PORT
debug3: check_host_in_hostfile: filename /c/Users/USER_NAME/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug3: check_host_in_hostfile: filename /c/Users/USER_NAME/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug1: Host '[WEB_NAME.com]:SSH_PORT' is known and matches the RSA host key.
debug1: Found key in /c/Users/USER_NAME/.ssh/known_hosts:1
debug2: bits set: 532/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
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: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: C:/Users/USER_NAME/.ssh/git/private_key.ppk (0x0)
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mi
c,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-m
ic,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: C:/Users/USER_NAME/.ssh/git/private_key.ppk
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key 'C:/Users/USER_NAME/.ssh/git/private_key.ppk':
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
debug2: bad passphrase given, try again...
Enter passphrase for key 'C:/Users/USER_NAME/.ssh/git/private_key.ppk':
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
debug2: bad passphrase given, try again...
Enter passphrase for key 'C:/Users/USER_NAME/.ssh/git/private_key.ppk':
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
debug2: bad passphrase given, try again...
debug2: we did not send a packet, disable method
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mi
c,password

/* Password debugging deleted -- useless -- Zeveso */

debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
Improve this question
7
  • Possibly copying the former keys gives you errors. Did you try to generate all new keys from your Windows computer using puttygen and follow the instructions? The problem I have found in the past is that the putty gen key that is exported, is not the same as the linux key. You can copy the private key from fedora to debian and connect to Centos server, but the windows clients I have used for ssh will not use that same format. Putty gen may also have a "Conversion" tool that will change the linux key into the windows type on the top menus.
    – ndasusers
    Nov 19, 2013 at 5:27
  • @ndasusers Keys where generated on CentOS and imported using putty to make 'private_key.ppk'. The weird thing is that it says "debug1: ssh_rsa_verify: signature correct". I assume that means that the private_key.ppk matches the id_rsa.pub / authorized_keys file.
    – Zeveso
    Nov 19, 2013 at 10:10
  • 1
    I think that signature correct means that "WEB_NAME.com" signature matches a signature in your known_hosts file. So if you blank out your known_hosts on the windows computer you should be asked again to verify the signature of the server before connecting. That is actually a very important step, but usually we just click through it. You really should make sure the resource you are connecting to is correct because it could be a spy computer acting like your WEB_NAME.com server.
    – ndasusers
    Nov 19, 2013 at 12:53
  • 1
    I also think the way to do this is to generate the key from the client, and send the public key to the server. Not that the key pairs themselves are machine specific, but that doing things the same way each time is better. Form the habit of making ssh keys on the client. Don't even use just one key either. I make a key for github, one for each server one for each email recipient and so on. That way you have strong security with strong passwords for each and every resource.
    – ndasusers
    Nov 19, 2013 at 13:18
  • Look at this debug 3: Not a RSA1 key file C:/Users/USER_NAME/.ssh/git/private_key.ppk.
    – ndasusers
    Nov 19, 2013 at 14:28

1 Answer 1

Reset to default
3

Step 1:

chmod 700 ~/.ssh

Step 2:

chmod 600 ~/.ssh/authorized_keys

Step 3:

sed -i 's|#AuthorizedKeysFile|AuthorizedKeysFile|g' /etc/ssh/sshd_config
sed -i 's|.ssh/authorized_keys|%h/.ssh/authorized_keys|g' /etc/ssh/sshd_config

Note: Add 'sudo' as need be.

I have never had to do this with other Linux distros, really surprised I needed to do this.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .