SOLVED Cannot setup ZFS replication - "Permission denied (publickey,password)"

[Woolbox]

I spent hours trying to understand this. As I wrote the post above, I was at a complete loss.

However after putting it into words, thinking about it for a few minutes, then re-reading documentation - I discovered that the public key of PUSH was not set on the root user on PULL.

Now the SSH connection works and I can try and setup my replication tasks again.

Oh, I feel so stupid! :(

 

[jgreco]

Don't you love SSH.

 

[Woolbox]

Sure - and know I know more about it that I ever had too ;)

Replication jobs are slowly doing their thing now, so all is well and good - except I feel so embarrassed

I hope my thread will at least will help some other poor guy at some point.

 

[Mike K]

Could you do me a favor and specify exactly what you did in your "AHA!" moment to get this working? I have a similar configuration and a similar problem connecting. I have a physical PUSH server attempting to connect to a virtual PULL server. When I create a replication task it errors out complaining about the password. I've put the Key from the PUSH as found on "View Public Key" button into the 'root' user on PULL, but it won't connect. I've gone to the command line as suggested in the instructions and I see the following:

Code:

ebug1: Found key in /etc/ssh/ssh_known_hosts:13                               
debug1: ssh_ecdsa_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: /data/ssh/replication (0x802830100), explicit                     
debug1: Authentications that can continue: publickey,password                  
debug1: Next authentication method: publickey                                  
debug1: Offering RSA public key: /data/ssh/replication                         
debug2: we sent a publickey packet, wait for reply                             
debug1: Authentications that can continue: publickey,password                  
debug2: we did not send a packet, disable method                               
debug1: Next authentication method: password                                   
root@192.168.1.21's password:      

If I look at /var/log/auth.log I don't see much:

Code:

[root@freenas ~]# cat /var/log/auth.log                                        
Oct 19 16:43:55 freenas newsyslog[1529]: logfile first created                 
Oct 20 21:53:08 freenas sshd[38746]: Server listening on :: port 22.           
Oct 20 21:53:08 freenas sshd[38746]: Server listening on 0.0.0.0 port 22.      
Oct 21 04:26:19 freenas sshd[48259]: Connection closed by 192.168.1.16 [preauth]
Oct 21 04:27:02 freenas sshd[48274]: Connection closed by 192.168.1.16 [preauth]
Oct 21 04:32:51 freenas sshd[48391]: Failed password for root from 192.168.1.16
port 53248 ssh2                                                                
Oct 21 04:32:52 freenas sshd[48391]: Failed password for root from 192.168.1.16
port 53248 ssh2                                                                
Oct 21 04:32:52 freenas sshd[48391]: Failed password for root from 192.168.1.16
port 53248 ssh2                                                                
Oct 21 04:32:52 freenas sshd[48391]: Connection closed by 192.168.1.16 [preauth]

Both PUSH and PULL are v9.3. I'm stuck at this point and any assistance would be welcome! Thanks.

 

[Woolbox]

I'm by no means an expert, but I cautious guess: Did you select another user than 'root' on PUSH for the replication, but still copied the public key to the 'root' user on PULL?

 

[panjlaprateek]

So, i had the same issue as Woolbox .
However, in my case

sourceserver:/ ssh root@targetserver was working fine, no issues from normal shell. This confirmed that ssh publickey access was setup correctly, atleast from sourceserver to targetserver.

but the replication task kept failing with permission denied error.
ssh -vvv didn't help me figure out the issue.

However, what I changed to make it work may help someone else.

It worked if I replaced the long sshcmd command string in autorepl.py with just "ssh" on the server I was trying to replicate from.
Not sure if this issue is just for the "fast Cipher" option. I am using that while replicating

Old command in /usr/local/www/freenasUI/tools/autorepl.py

sshcmd = (
'/usr/bin/ssh -c arcfour256,arcfour128,blowfish-cbc,'
'aes128-ctr,aes192-ctr,aes256-ctr -i /data/ssh/replication'
' -o BatchMode=yes -o StrictHostKeyChecking=yes'
# There's nothing magical about ConnectTimeout, it's an average
# of wiliam and josh's thoughts on a Wednesday morning.
# It will prevent hunging in the status of "Sending".
' -o ConnectTimeout=7'


New Command



sshcmd = (
'ssh '
# There's nothing magical about ConnectTimeout, it's an average
# of wiliam and josh's thoughts on a Wednesday morning.
# It will prevent hunging in the status of "Sending".
' -o ConnectTimeout=7'
)



I am wondering if that would be lost when the system is rebooted.

Both Freenas systems are at latest stable versions.
FreeNAS-9.10.1-U4 (ec9a7d3)