Password required when trying to ssh into a server using Cygwin on Windows 7

3

1

I'm trying to set up a server at our company, and one of the things I'd like to be able to do is host public Git repositories on it which I can access over ssh. Both the server and the workstation I'm using to access it are running 64-bit Windows 7. I've been following this guide to do that and I'm currently at the stage where I'm trying to access my server with git@atp-dev1 where atp-dev1 is a known host.

However, I'm at the point where I should be able to ssh into the server without the need to provide a password, yet it still asks me for a password each time anyway. These are the steps I've taken:

  • Configured the server using ssh-host-config. StrictModes is set to 'yes'.
  • Generated an ssh keypair called 'gitolite-admin' on my workstation.
  • Copied the public key over to the server's authorized_keys file using ssh-copy-id and confirmed that it's there.
  • Configured the permissions of my server's .ssh folder to 700 and .ssh/authorized_keys to 600 (I've tried setting the permissions on my workstation to match this, but some other issue with Cygwin is preventing me from changing permissions from -rw-r--r--).

I open up a Cygwin64 terminal and enter the following: ssh -i ~/.ssh/gitolite-admin git@atp-dev1. It then prompts for a password. Doing this with -vvv included, I get the following output:

$ ssh git@atp-dev1 -vvv
OpenSSH_6.7p1, OpenSSL 1.0.1k 8 Jan 2015
debug1: Reading configuration data /etc/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to atp-dev1 [172.16.1.92] port 22.
debug1: Connection established.
debug1: identity file /cygdrive/c/Users/davidfallah/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /cygdrive/c/Users/davidfallah/.ssh/id_rsa-cert type -1
debug1: identity file /cygdrive/c/Users/davidfallah/.ssh/id_dsa type 2
debug1: key_load_public: No such file or directory
debug1: identity file /cygdrive/c/Users/davidfallah/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /cygdrive/c/Users/davidfallah/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /cygdrive/c/Users/davidfallah/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /cygdrive/c/Users/davidfallah/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /cygdrive/c/Users/davidfallah/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7
debug1: match: OpenSSH_6.7 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "atp-dev1" from file "/cygdrive/c/Users/davidfallah/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /cygdrive/c/Users/davidfallah/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
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-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-ed25519,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@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: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@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: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
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
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
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
debug2: mac_setup: setup umac-64-etm@openssh.com
debug1: kex: server->client aes128-ctr umac-64-etm@openssh.com none
debug2: mac_setup: setup umac-64-etm@openssh.com
debug1: kex: client->server aes128-ctr umac-64-etm@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA aa:84:ea:95:b6:b9:ba:52:fa:14:73:62:97:12:30:95
debug3: load_hostkeys: loading entries for host "atp-dev1" from file "/cygdrive/c/Users/davidfallah/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /cygdrive/c/Users/davidfallah/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys
debug3: load_hostkeys: loading entries for host "172.16.1.92" from file "/cygdrive/c/Users/davidfallah/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /cygdrive/c/Users/davidfallah/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug1: Host 'atp-dev1' is known and matches the ECDSA host key.
debug1: Found key in /cygdrive/c/Users/davidfallah/.ssh/known_hosts:3
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: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /cygdrive/c/Users/davidfallah/.ssh/id_rsa (0x6000684b0),
debug2: key: /cygdrive/c/Users/davidfallah/.ssh/id_dsa (0x600078a40),
debug2: key: /cygdrive/c/Users/davidfallah/.ssh/id_ecdsa (0x0),
debug2: key: /cygdrive/c/Users/davidfallah/.ssh/id_ed25519 (0x0),
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
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: Offering RSA public key: /cygdrive/c/Users/davidfallah/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Offering DSA public key: /cygdrive/c/Users/davidfallah/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /cygdrive/c/Users/davidfallah/.ssh/id_ecdsa
debug3: no such identity: /cygdrive/c/Users/davidfallah/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /cygdrive/c/Users/davidfallah/.ssh/id_ed25519
debug3: no such identity: /cygdrive/c/Users/davidfallah/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: userauth_kbdint: disable: no info_req_seen
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred:
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
git@atp-dev1's password:
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
Authenticated to atp-dev1 ([172.16.1.92]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Remote: Ignored authorized keys: bad ownership or modes for directory /home/git
debug1: Remote: Ignored authorized keys: bad ownership or modes for directory /home/git
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0

An interesting thing I notice in that output is that, after being forced to authorise through entering the password, it says that authorized_keys was not read due to "bad ownership or modes for directory" within the Cygwin home directory on the server (/home/git). I don't know why this is, as I'm pretty sure I've set the appropriate permissions for the home directory, the .ssh directory and the .ssh files.

If it's relevant, on my workstation I've modified /etc/passwd to make Cygwin use the same home directory as Windows uses (under C:\Users\) instead of under C:\cygwin64\home. On the server, it uses C:\cygwin64\home\git\ as the Cygwin home directory.

Finally, if it's at all relevant, my workstation's /etc/fstab file is:

# For a description of the file format, see the Users Guide
# http://cygwin.com/cygwin-ug-net/using.html#mount-table

# This is default anyway:
none /cygdrive cygdrive binary,noacl,posix=0,user 0 0

EDIT

The etc/sshd_config file on the server is:

#   $OpenBSD: sshd_config,v 1.93 2014/01/10 05:59:19 djm Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/bin:/usr/sbin:/sbin:/usr/bin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# The default requires explicit activation of protocol 1
#Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh_host_rsa_key
#HostKey /etc/ssh_host_dsa_key
#HostKey /etc/ssh_host_ecdsa_key
#HostKey /etc/ssh_host_ed25519_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Ciphers and keying
#RekeyLimit default none

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#RSAAuthentication yes
#PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile  .ssh/authorized_keys

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
#UsePAM no

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# override default of no subsystems
Subsystem   sftp    /usr/sbin/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#   X11Forwarding no
#   AllowTcpForwarding no
#   PermitTTY no
#   ForceCommand cvs server

Strange behaviour: I've just tried to double-check the permissions in /home/git and finding I'm completely locked out of that folder - I can't even access it as administrator. I'll probably need to speak with our IT department to resolve this.

EDIT 2

Managed to reclaim ownership of /home/git. Not sure why I lost it in the first place. These are the permissions for the home directory and ssh folder:

From home/git:

drwxrwx---+ 1 git          ATP-DEV1+None    0 Mar 18 17:05 .
drwxrwxrwt+ 1 davidfallah  Domain Users     0 Mar 18 15:09 ..
-rw-------  1 ATP-DEV1+git ATP-DEV1+None 1099 Mar 19 09:31 .bash_history
-rwxr-xr-x  1 ATP-DEV1+git ATP-DEV1+None 1494 Mar 18 14:09 .bash_profile
-rwxr-xr-x  1 ATP-DEV1+git ATP-DEV1+None 6054 Mar 18 14:09 .bashrc
-rwxr-xr-x  1 ATP-DEV1+git ATP-DEV1+None 1919 Mar 18 14:09 .inputrc
-rwxr-xr-x  1 ATP-DEV1+git ATP-DEV1+None 1236 Mar 18 14:09 .profile
drws------+ 1 git          Domain Users     0 Mar 18 17:59 .ssh

From home/git/.ssh:

drws------+ 1 git Domain Users    0 Mar 18 17:59 .
drwxrwx---+ 1 git ATP-DEV1+None   0 Mar 18 17:05 ..
-rw-------  1 git Domain Users  405 Mar 18 18:00 authorized_keys

EDIT 3

After setting StrictModes to no on the server and restarting the ssh service, I'm able to access my server without a password using:

ssh git@atp-dev1 -i ~/.ssh/gitolite-admin

This is a less than ideal situation since it compromises security a little, but it makes me fairly confident that this is all an issue with permissions. I'm fairly sure the permissions on the server are correct, but as I mentioned above and in this post, I'm unable to change permissions on my workstation and this is likely the blocking issue.

Tagc

Posted 2015-03-19T14:16:15.663

Reputation: 194

1You didn't mention whether you turned off password authentication in /etc/ssh/sshd_config. My hunch is you still won't be permitted to login at all and get immediately rejected when you turn it on, but that'll help troubleshoot by eliminating the possibility that it's asking you for a password because you allow password authentication. Also, verify with ls -la that the permissions of ~/.ssh and ~/.ssh/authorized_keys are what you set them to. If it's world writable, you may need to tweak the underlying NTFS permissions using Windows to deny other users. – allquixotic – 2015-03-19T14:31:27.393

See also: http://cygwin.com/cygwin-ug-net/ntsec.html

– allquixotic – 2015-03-19T14:38:46.533

@allquixotic I've posted /etc/sshd_config and 'PasswordAuthentication' appears to be set to its default value 'yes', if that's what you mean. I can try changing that. I also tried double-checking permissions but something really weird has happened, which I'll try to get resolved. I've edited OP. – Tagc – 2015-03-19T14:46:29.110

Yeah, try uncommenting and setting PasswordAuthentication no. As for the permissions issue, check it in Windows Explorer. Try to go to c:\cygwin64\home\git. If you don't have access, but you are an administrator on the system, try taking ownership of it (in Windows Explorer). – allquixotic – 2015-03-19T14:47:55.773

@allquixotic Thanks, managed to get back into it. I've updated OP with permissions - I'm working on changing sshd_config now (I guess the daemon is preventing it from being modified). – Tagc – 2015-03-19T15:03:31.753

@allquixotic I made that change and now I get flat out 'permission denied' when trying to ssh in from a workstation, as you suggested might happen. – Tagc – 2015-03-19T15:14:18.027

OK, and are you sure you have the public key on the client side stored as id_rsa in ~/.ssh with similarly restrictive permissions? – allquixotic – 2015-03-19T15:48:44.490

@allquixotic I have an ssh keypair gitolite-admin and gitolite-admin.pub. I can confirm that the public gitolite-admin key is stored within /home/git/.ssh/authorized_keys, which has permissions -rw-------, and matches the public key I offer from my workstation with ssh git@atp-dev1 -i ~/.ssh/gitolite-admin. By running that command with -vvv included, I can see that I am offering that key to the host when I try to ssh into it as well. What about the "bad ownership or modes for directory" I mentioned in the OP? – Tagc – 2015-03-19T16:01:59.330

@allquixotic I forgot to mention, though - the permissions on the client-side are not as restrictive as on the server-side. As I mentioned in the OP, I'm unable to change my permissions properly on my workstation (permissions are fixed at -rw-r--r--). I'll try creating a new question to resolve that and I'll also try seeing what happens when I set StrictModes to no on the server. – Tagc – 2015-03-20T08:01:23.940

No answers