RSync over SSH private key login... (Solved Myself)

Status
Not open for further replies.

Visseroth

Guru
Joined
Nov 4, 2011
Messages
546
So I'm trying to backup a buddy's server to my own but I am unable to get Rsync over SSH to work.
I'm trying to push the data. I've been connecting to my server from his via ssh but every time I connect it asks for a password.
I've thus far read these forums, but nothing seems to work, I'm always prompted for a password...
https://forums.freenas.org/index.ph...enas-synology-with-rsync-over-ssh-sftp.55380/
https://forums.freenas.org/index.php?threads/new-to-ssh-keys.11716/

I have the id_rsa, id_rsa.pub in both locations and authorized_keys on my server, the push location.
I've verified that the pub key is in the user account being used to sync the data. Permissions are 700 on authorized_keys and 644 on the id-rsa files
I've tried connecting via ssh user@ipaddress -p port
I've tried connecting via ssh -p port -i path/to/id_rsa.pub user@ipaddress
but I'm always prompted for a password.
Any help would be appreciated to verify that rsync is actually going to sync and is able to connect without a password.
 

Visseroth

Guru
Joined
Nov 4, 2011
Messages
546
Bump
 

scrappy

Patron
Joined
Mar 16, 2017
Messages
347
Might be a silly question, but are you trying to connect to your friend's server using your username or his? If your own username, has your username been setup on your friend's server?
 

Visseroth

Guru
Joined
Nov 4, 2011
Messages
546
Not a silly question at all.
No, I created a user just for this purpose on both ends. Same user, same password. The idea was once the key was working I'd disable password login and tighten down the restrictions since this backup user account has access to everything on the sending end and to the backup folder holding everything on the receiving end.
 

Visseroth

Guru
Joined
Nov 4, 2011
Messages
546
so it seems private keys just isn't working. I'm starting to wonder if it's a bug.
If I type 'ssh-add' in the command line I get back 'Could not open a connection to your authentication agent.'
in both locations, just for redundancy I have id_rsa and id_rsa.pub in the ~/.ssh/ directory. I've also copied id_rsa.pub to the authorized_keys file.
No matter what I am always prompted for a password on connection.
 

Visseroth

Guru
Joined
Nov 4, 2011
Messages
546
Still not making any progress. The file is there, the public key is in place with ssh-rsa removed from the fire but still is not passing without the password and password authentication is disabled...

[charleybackup@RSDWHS ~/.ssh]$ ls -l
total 43
-rw------- 1 charleybackup charleybackup 394 Dec 27 04:48 authorized_keys
-rw------- 1 charleybackup charleybackup 1617 Dec 27 04:48 id_rsa
-rw------- 1 charleybackup charleybackup 1679 Dec 27 04:48 id_rsa.bak
-rw------- 1 charleybackup charleybackup 408 Dec 27 04:48 id_rsa.pub
-rwxrw---- 1 charleybackup charleybackup 182 Dec 27 04:49 known_hosts
[charleybackup@RSDWHS ~/.ssh]$ cp id_rsa freenas_rsa
[charleybackup@RSDWHS ~/.ssh]$ ssh -v charleybackup@***.***.***.*** -p *******
OpenSSH_7.5p1, OpenSSL 1.0.2k-freebsd 26 Jan 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 3: Deprecated option "useroaming"
debug1: Connecting to ***.***.***.*** [***.***.***.***] port *******.
debug1: Connection established.
debug1: identity file /mnt/tank/Users/charleybackup/.ssh/id_rsa type 1
debug1: Fssh_key_load_public: No such file or directory
debug1: identity file /mnt/tank/Users/charleybackup/.ssh/id_rsa-cert type -1
debug1: Fssh_key_load_public: No such file or directory
debug1: identity file /mnt/tank/Users/charleybackup/.ssh/id_dsa type -1
debug1: Fssh_key_load_public: No such file or directory
debug1: identity file /mnt/tank/Users/charleybackup/.ssh/id_dsa-cert type -1
debug1: Fssh_key_load_public: No such file or directory
debug1: identity file /mnt/tank/Users/charleybackup/.ssh/id_ecdsa type -1
debug1: Fssh_key_load_public: No such file or directory
debug1: identity file /mnt/tank/Users/charleybackup/.ssh/id_ecdsa-cert type -1
debug1: Fssh_key_load_public: No such file or directory
debug1: identity file /mnt/tank/Users/charleybackup/.ssh/id_ed25519 type -1
debug1: Fssh_key_load_public: No such file or directory
debug1: identity file /mnt/tank/Users/charleybackup/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.5 FreeBSD-20170903
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.5-hpn14v5
debug1: match: OpenSSH_7.5-hpn14v5 pat OpenSSH* compat 0x04000000
debug1: Authenticating to ***.***.***.***:******** as 'charleybackup'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit > compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit > compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: (Commented Out)
debug1: skipped DNS lookup for numerical hostname
debug1: Host '[***.***.***.***]:********' is known and matches the ECDSA host key.
debug1: Found key in /mnt/tank/Users/charleybackup/.ssh/known_hosts:1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: Fssh_kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-2 56,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp 521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /mnt/tank/Users/charleybackup/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /mnt/tank/Users/charleybackup/.ssh/id_dsa
debug1: Trying private key: /mnt/tank/Users/charleybackup/.ssh/id_ecdsa
debug1: Trying private key: /mnt/tank/Users/charleybackup/.ssh/id_ed25519
debug1: Next authentication method: password
charleybackup@***.***.***.***'s password:
 
Last edited:

Visseroth

Guru
Joined
Nov 4, 2011
Messages
546
bump
 

Visseroth

Guru
Joined
Nov 4, 2011
Messages
546
ok, finally came back at this and tried it again with a fresh mind (because I forgot how I was doing it) and got it to work.
So... For future reference and anyone else that comes across this, this is what I did.

From the remote machine (Machine initiating the connection) I logged into the machine via ssh.
If you don't know how to do that then use putty, a terminal, web search it.

Anyhow, I logged into the machine using the user account that is going to initiate the connection.

cd .ssh

ssh-keygen -t id_rsa
Enter id_rsa for file name
no password

cp id_rsa.pub authorized_keys
rm id_rsa.pub
scp -P (Port#) authorized_keys User@IPorDNS:/path/to/userfolder/.ssh/

permissions of authorized keys are -rw-r-----
Permissions of id_rsa are -rw-------

Test my using ssh User@IPorDNS -p (Port#)
It should log you right in without asking for a password.
 

Visseroth

Guru
Joined
Nov 4, 2011
Messages
546
Edit: You may get a error in the FreeNAS GUI that a public key is needed. I just copied id_rsa to id_rsa.pub and kept both files there (on the intiating server) to be sure that ssh will connect without asking for a password.
 

PhilipS

Contributor
Joined
May 10, 2016
Messages
179
Just FYI for anyone looking at this in the future. You are kind of backwards on your key generation. The SSH client should generate the key pair, and then the public key appended to the authorized_keys on the server. Its preferred for the private key to not need to be copied anywhere. The public key is fair game - copy away.

SSH Server - holds the public keys of clients (can be multiple) The keys themselves don't need to be secured (they are "public"), but you don't want anyone to be able to add there own public keys to the authorized_keys file. Clients should be trusted to protect their private keys.
SSH Client - holds its private key - don't want this to leak. Anyone with this private key will be able to connect to servers that hold its public key.
 

Visseroth

Guru
Joined
Nov 4, 2011
Messages
546
I'll have to try it the other way at some point but I tried the recommended way and it didn't work. Kept asking for a password and didn't like my keys. This seemed to do the trick.
 
Status
Not open for further replies.
Top