problem login using keys authentication only (password-less)

7 posts / 0 new
Last post
kilshd
Offline
Last seen: 5 years 2 months ago
Joined: 16.08.2015 - 14:19
problem login using keys authentication only (password-less)

I have a Windows server (windows 7)

That is the backup server and runs cwRsyncServer

User: danny

 

I have a Linux client (Ubuntu 12.04).

User: daniel

 

I need to be able to back up my Linux on a Windows server.

i want to use Cron for automatic daily backup and therefor i need to be able to connect to the Windows server without password (using only key authentication)

The problem is, that no matter what I do, I'm being prompt for password .

This makes it impossible to use any type of automatic backups (via a script)

What am I doing wrong> is there a detailed procedure for that (I did follow the manual and generated keys but it didn't work for me…)?

  

Here is what I did:

On Ubuntu (rsync client):

---------------------------

 1.   ssh-keygen -t rsa

      Generated pass phrase 12345

2.   ssh-copy-id -i ~/.ssh/id_rsa.pub danny@192.168.0.7

3.   Logged in to danny@192.168.0.7 using a password and verified the public key was copied from the Ubuntu client to the windows server

 

On windows (rsync server):

--------------------------

activate user (dabby) + generateted pass pdrase 12345

 

Edited the sshd_conf:

1. Uncommented these 2 lines:

   RSAAuthentication yes

   PubkeyAuthentication yes

2. Uncommented and changed

   #PasswordAuthentication yes to PasswordAuthentication no

3. Restart open ssh service.

 

Form ubuntu client tried to login with:

ssh -vvv -i ~/.ssh/id_rsa   danny@192.168.0.7

 

I got:

 

OpenSSH_5.9p1 Debian-5ubuntu1.6, OpenSSL 1.0.1 14 Mar 2012

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: /etc/ssh/ssh_config line 19: Applying options for *

debug2: ssh_connect: needpriv 0

debug1: Connecting to 192.168.0.7 [192.168.0.7] port 22.

debug1: Connection established.

debug3: Incorrect RSA1 identifier

debug3: Could not load "/home/daniel/.ssh/id_rsa" as a RSA1 public key

debug1: identity file /home/daniel/.ssh/id_rsa type 1

debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048

debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048

debug1: identity file /home/daniel/.ssh/id_rsa-cert type -1

debug1: Remote protocol version 1.99, remote software version OpenSSH_5.2

debug1: match: OpenSSH_5.2 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.6

debug2: fd 3 setting O_NONBLOCK

debug3: load_hostkeys: loading entries for host "192.168.0.7" from file "/home/daniel/.ssh/known_hosts"

debug3: load_hostkeys: found key type RSA in file /home/daniel/.ssh/known_hosts:2

debug3: load_hostkeys: loaded 1 keys

debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug2: kex_parse_kexinit: 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-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,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-256-96,hmac-sha2-512,hmac-sha2-512-96,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-256-96,hmac-sha2-512,hmac-sha2-512-96,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-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,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

debug2: mac_setup: found hmac-md5

debug1: kex: server->client aes128-ctr hmac-md5 none

debug2: mac_setup: found hmac-md5

debug1: kex: client->server aes128-ctr 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: 129/256

debug2: bits set: 537/1024

debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

debug1: Server host key: RSA 7b:18:02:e2:01:b2:42:88:4b:61:ce:c4:0c:d7:8e:bf

debug3: load_hostkeys: loading entries for host "192.168.0.7" from file "/home/daniel/.ssh/known_hosts"

debug3: load_hostkeys: found key type RSA in file /home/daniel/.ssh/known_hosts:2

debug3: load_hostkeys: loaded 1 keys

debug1: Host '192.168.0.7' is known and matches the RSA host key.

debug1: Found key in /home/daniel/.ssh/known_hosts:2

debug2: bits set: 524/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: 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/daniel/.ssh/id_rsa (0x7f46110d64e0)

debug1: Authentications that can continue: publickey,password,keyboard-interactive

debug3: start over, passed a different list publickey,password,keyboard-interactive

debug3: preferred gssapi-keyex,gssapi-with-mic,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: /home/daniel/.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

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

danny@192.168.0.7's password:

itefix
Offline
Last seen: 22 hours 16 min ago
Joined: 01.05.2008 - 21:33
Not sure if you run a

Not sure if you run a combination we support here - which version of cwRsyncServer and ssh do you run at the windows side ?

kilshd
Offline
Last seen: 5 years 2 months ago
Joined: 16.08.2015 - 14:19
At the time I installed

cwRsyncServer_3.0.1. It comes with OpenSSH version OpenSSH_5.2p1

On my Ubuntu server I have OpenSSH_5.9p1 and rsync version 3.0.9 protocol version 30

According to the attached printout from the SSH connection (using –vvvv) everything looks ok but the key authentication fails.

 

I have a strong feeling it might be something I'm doing wrong… 

 

this is my sshd_config file on Windows:

 

 

#$OpenBSD: sshd_config,v 1.74 2006/07/19 13:07:10 dtucker 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 change a

# default value.

 

#Port 22

#Protocol 2,1

#AddressFamily any

#ListenAddress 0.0.0.0

#ListenAddress ::

 

# 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

 

# Lifetime and size of ephemeral version 1 server key

#KeyRegenerationInterval 1h

#ServerKeyBits 768

 

# Logging

# obsoletes QuietMode and FascistLogging

SyslogFacility AUTH

LogLevel INFO

 

# Authentication:

 

#LoginGraceTime 2m

#PermitRootLogin yes

#StrictModes yes

#MaxAuthTries 6

 

RSAAuthentication yes

PubkeyAuthentication yes

#AuthorizedKeysFile.ssh/authorized_keys

 

# 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

 

#AllowTcpForwarding yes

#GatewayPorts no

#X11Forwarding no

#X11DisplayOffset 10

#X11UseLocalhost 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

#PermitTunnel no

 

# no default banner path

#Banner /some/path

 

# override default of no subsystems

Subsystemsftp/bin/sftp-server

 

# Example of overriding settings on a per-user basis

#Match User anoncvs

#X11Forwarding no

#AllowTcpForwarding no

#ForceCommand cvs server

 

itefix
Offline
Last seen: 22 hours 16 min ago
Joined: 01.05.2008 - 21:33
Sorry, this is a quite old

Sorry, this is a quite old version and not supported any longer. We try to help for the free software available at our website. Anyway, I can't see that you add your public key to the ~/.ssh/authorized_files file at the Windows side. Please check if .ssh/authorized_keys contains tha public key.

kilshd
Offline
Last seen: 5 years 2 months ago
Joined: 16.08.2015 - 14:19
on my first post, at

on my first post, at paragraph 2 and 3 i wrote:

2.   ssh-copy-id -i ~/.ssh/id_rsa.pub danny@192.168.0.7

3.   Logged in to danny@192.168.0.7 using a password and verified the public key was copied from the Ubuntu client to the windows server

 

i just re-checked and the public key from Ubuntu (client) is in the "authorized_files" file on Windows (the rsync server).

anyway, since i access from ubuntu to windows i must pass the public key to windows, then passing the location of the private key on my ubuntu using the -i  switch.

i made another test, i opened the bash shell from copssh, add public key that was generated by the copssh and tried to connect to ubuntu (from windows to ubuntu). it worked with no problems.

so the conclusion is that:

1. my ubuntu generate keys that the copssh can't work with

2. there is a problem with the copssh server

3. both 1 and 2 :)

P.S

I never used cwRsyncServer with SSH before. i always used it to sync files on my LAN. now i added a remote back up location and i stumbled on this issue...

kilshd
Offline
Last seen: 5 years 2 months ago
Joined: 16.08.2015 - 14:19
Today I made another test, I

Today I made another test, I installed Copssh_4.1.0 and even the service stopped running after the first user activation, it did provide a log. There I saw earlier entries from running cwRsyncServer_3.0.1. I got the impression that the public key on the server side cannot be access because of insufficient permissions.

Which permissions should I set?

Is there a way to view a log from cwRsyncServer_3.0.1?

 

I also tried to connect from the Windows server to itself using keys authentication and it didn't work.

ssh –vvv  –i danny.key danny@192.168.0.7 (or localhost)

 it complained about white spaces in the key file (that was generated by ssh-keygen on that same PC)

 

 

 

 

kilshd
Offline
Last seen: 5 years 2 months ago
Joined: 16.08.2015 - 14:19
[SOLVED]

I finally made it work!!

It was a permissions issue as I wrote before.

After inspecting the log I saw these 2 lines:

2015.08.17 19:06:44 -  Authentication refused: bad ownership or modes for file /home/danny/.ssh/authorized_keys

 

2015.08.17 19:04:50 -  Connection closed by 192.168.0.7

and then i figure it out:

SSH does not allow group write permissions on ~/.ssh directory

so, it must be changed to 700

authorized_keys permissions should be 600

Another way is to uncomment the strictModes and set it to no (less secure but works)