Rsync files over SSH from local OMV to remote OMV server, keeps promting for remote OMV root user password on every attempt

  • Hello Members,


    As subject is self-explanatoring :), i'm adding more info about the issue that keeps me awake at night, thinking what could be wrong :)


    1.Local OMV box(2.1.1 - Stone burner x32 - Virtual Machine under Hyper-V):


    1.1 configured shared folder that needs to be RSYNC-ed over ssh to remote\another OMV box
    1.2 Enabled SSH with following settings:
    * Port 38755
    * Permit root login [ ] (unchecked)
    * Password authentication [checked ]
    * Public key authentication [checked ]
    * TCP forwarding [checked ]
    * Compression [ ] (unchecked)
    1.3 logged as root, generated Public/Private key pair (On OMV box typed:)
    * ssh-keygen -t rsa
    * keys were generated
    * added public key to remote OMV in ./ssh/authorized_keys




    2.Remote OMV box(2.1 - Stone burner x64 - Physical Machine):


    2.1 configured shared folder that will store RSYNC-ed files from local OMV box
    2.2 Enabled SSH with following settings:
    * Port 38755
    * Permit root login [ ] (unchecked)
    * Password authentication [checked ]
    * Public key authentication [checked ]
    * TCP forwarding [checked ]
    * Compression [ ] (unchecked)



    3. Test attempt to RSYNC files from Local OMV box to Remote OMV box


    3.1 logged with root on SSH at local OMV box
    3.2 performed following line: rsync -avz -e "ssh -p 38755 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" --progress /media/1d3e82d0-9413-40c5-ba43-b4cc78ec96af/localfoldertest/ 192.168.1.200:/media/746b1d41-ce5c-430e-82f4-a2a16695f57a/remotefoldertest
    3.3 received following warning: Warning: Permanently added '[192.168.1.200]:38755' (RSA) to the list of known hosts.
    3.4 received following password request: root@192.168.1.200's password:


    at the moment when I add public key from Local OMV to Remote OMV (described at 1.3), I should be able to login to server without password.


    I've searched on google, tried different things(re-creating keys, generating DSA key pair, convert to open ssh key pair, reviewed /etc/ssh/ssh_config file on both servers), still no luck...


    Any directions and ideas are greately appreciated :)


    Regards,


    Aleksandar

  • Ups, you are correct!


    I've enabled Permit root login on both servers, but still receiving same error:


    3.3 received following warning: Warning: Permanently added '[192.168.1.200]:38755' (RSA) to the list of known hosts.
    3.4 received following password request: root@192.168.1.200's password:


    Checked both "ssh_config" and sshd_config files, they are identical on both servers.


    "ssh_config"


    # Cipher 3des
    # Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
    # MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160
    # EscapeChar ~
    # Tunnel no
    # TunnelDevice any:any
    # PermitLocalCommand no
    # VisualHostKey no
    # ProxyCommand ssh -q -W %h:%p gateway.example.com
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials no



    "sshd_config"


    Protocol 2
    HostKey /etc/ssh/ssh_host_rsa_key
    HostKey /etc/ssh/ssh_host_dsa_key
    UsePrivilegeSeparation yes
    KeyRegenerationInterval 3600
    ServerKeyBits 768
    SyslogFacility AUTH
    LogLevel INFO
    LoginGraceTime 120
    StrictModes yes
    RSAAuthentication yes
    PubkeyAuthentication yes
    IgnoreRhosts yes
    RhostsRSAAuthentication no
    HostbasedAuthentication no
    PermitEmptyPasswords no
    ChallengeResponseAuthentication no
    X11Forwarding yes
    X11DisplayOffset 10
    PrintMotd no
    PrintLastLog yes
    TCPKeepAlive yes
    AcceptEnv LANG LC_*
    Subsystem sftp /usr/lib/openssh/sftp-server
    UsePAM yes
    AllowGroups root ssh
    AddressFamily any
    Port 38755
    PermitRootLogin yes
    AllowTcpForwarding yes
    Compression no
    PasswordAuthentication yes
    AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2 /var/lib/openmediavault/ssh/authorized_keys/%u
    PubkeyAuthentication yes


    restarted ssh service on both servers, tried again, no changes...


    Thanks,


    Alek

  • What are the permissions and ownership of your .ssh directory and files? ssh refuses to use the keys if those are not "pulled tight". Meaning directory .ssh should be 700. The (private) key files 600 ...


    Just my two cents

    OMV 2.x - Kralizec // Hardware: HP Microserver N54L, 4GB RAM, 2x3TB WD Red - RAID 1, Sandisk SSD 60GB for system

  • Hello to All post members,


    Tried with Disable the password (interactive login), but then I can't logon to ssh, putty gave me error: "Disconnected: No supported authentication methods available(server sent: publickey)


    Also, checked .ssh folder permission - 700 and private key - 600, all or them are fine.


    As I could conclude, this is only due the configuration on both OMV, that SSH authentication is allowed with interactive-password login, so obviosely when Rsync starts, this option is used and it's promting for root pass, despite the fact that Public key from Local OMV i stored to Remote OMV.


    Any idea how I can enable PKA for root authentication over ssh? Tring to figure out, generate key in ssh session: ssh-keygen -t rsa / add password / import public key on remote OMV / takeower private key and store in putty / tried to login to ssh via putty - received error that key isn't supported...


    I've been following this guide: [GUIDE] Enable SSH with Public Key Authentication (Securing remote webUI access to OMV)


    But it's reffered for created user account.


    Thanks,


    Alek

  • Here is output:


    root@omv1:~/.ssh# ssh -p 38755 -vvv root@192.168.1.200 -i -/.ssh/id_omv1
    OpenSSH_6.0p1 Debian-4+deb7u2, OpenSSL 1.0.1e 11 Feb 2013
    Warning: Identity file -/.ssh/id_omv1 not accessible: No such file or directory.
    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.1.200 [192.168.1.200] port 38755.
    debug1: Connection established.
    debug1: permanently_set_uid: 0/0
    debug3: Incorrect RSA1 identifier
    debug3: Could not load "/root/.ssh/id_rsa" as a RSA1 public key
    debug1: identity file /root/.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 /root/.ssh/id_rsa-cert type -1
    debug1: identity file /root/.ssh/id_dsa type -1
    debug1: identity file /root/.ssh/id_dsa-cert type -1
    debug1: identity file /root/.ssh/id_ecdsa type -1
    debug1: identity file /root/.ssh/id_ecdsa-cert type -1
    debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-4+deb7u2
    debug1: match: OpenSSH_6.0p1 Debian-4+deb7u2 pat OpenSSH*
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u2
    debug2: fd 3 setting O_NONBLOCK
    debug3: put_host_port: [192.168.1.200]:38755
    debug3: load_hostkeys: loading entries for host "[192.168.1.200]:38755" from file "/root/.ssh/known_hosts"
    debug3: load_hostkeys: loaded 0 keys
    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: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-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,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,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-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: 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,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
    debug2: kex_parse_kexinit: none
    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: sending SSH2_MSG_KEX_ECDH_INIT
    debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
    debug1: Server host key: RSA c4:0d:f7:40:5a:15:1a:3e:06:73:f6:6b:68:80:25:1c
    debug3: put_host_port: [192.168.1.200]:38755
    debug3: put_host_port: [192.168.1.200]:38755
    debug3: load_hostkeys: loading entries for host "[192.168.1.200]:38755" from file "/root/.ssh/known_hosts"
    debug3: load_hostkeys: loaded 0 keys
    debug3: load_hostkeys: loading entries for host "[192.168.1.200]:38755" from file "/root/.ssh/known_hosts"
    debug3: load_hostkeys: loaded 0 keys
    debug1: checking without port identifier
    debug3: load_hostkeys: loading entries for host "192.168.1.200" from file "/root/.ssh/known_hosts"
    debug3: load_hostkeys: loaded 0 keys
    The authenticity of host '[192.168.1.200]:38755 ([192.168.1.200]:38755)' can't be established.
    RSA key fingerprint is c4:0d:f7:40:5a:15:1a:3e:06:73:f6:6b:68:80:25:1c.



    If you analyse closely, following lines:


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


    state that on process od establishing ssh session from Local to Remote OMV box, it's searching with keys with following names "id_rsa" for private and "id_rsa.pub" for public key.
    Mine was "id_omv1" for private and "id_omv1.pub" for public key, which obviosely confuse connection process and promt for pass on every attempt.


    What I've done:


    *In putty: Generate new key pair for root login user on both OMV boxes, add public key to Local / Remote OMV, respectivelly.*
    * Disable "Enable keyboard-interactive authentication" on both OMV boxes*
    * Log on to ssh with root account on both OMVs with PKA - works fine*


    1. Delete key pair with "id_omv1" name
    2. Generate new key: ssh-keygen -t rsa, no passphrase, and exact name "id_rsa"...
    3. Copy content of public key from Local to Remote OMV info ./ssh/authorized_keys
    4. Initiated Rsync process on test files, and all works fine - problem solved ! :)


    subzero79: Thanks for refferals about full log of ssh client, really can see from that point how the session is negotiated and all relevant parameters are being checked
    @all others: Thanks for participation and suggestions toward resolving this issue.


    Regards,


    Aleksandar

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!