SOLVED SSH in the GUI is not SSH in the shell/rest of the system

[qubus]

Hi all

I'm on FreeNas 11.3U2 and trying to do a first data transfer between 2 boxes (both on the same freenas version),

I tried replication at first but stopped it due to the time it will take (more than 30 days). Now I decided to move individual folders via rsync.

Because of the replication tast, I have set up an ssh connection for the root user between the two boxes and it worked fine. When I try to set up a new replication in the web GUI, it still seems to work as I can browse the remote box's datasets.

However, when I try to connect via SSH in the shell, the authentication fails with "Permission denied (publickey)." And I cannot figure out why or what I'm doing wrong.

The shell command I use is to just try to connect via SSH is the following (as root):
ssh -p [port] root@[domain]

Must be something simple I'm doing wrong. Do I need to reference the configured SSH connection somehow? What do I need to do to make the GUI-configured SSH connection work in the shell?

I've had password-less SSH connections with keys between freenas and clients set up for a while and those always worked fine. This is the first time I'm setting it up between 2 freenas boxes though.

 

[qubus]

Some additional log information:

Code:

root@alpha-machine[[path]]# ssh -vvv -p [destination-port] root@[destination-dns-name]
OpenSSH_7.5p1, OpenSSL 1.0.2s-freebsd  28 May 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: resolving "[destination-dns-name]" port [destination-port]
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to [destination-dns-name] [[destination-IP]] port [destination-port].
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: Fssh_key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa type -1
debug1: Fssh_key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: Fssh_key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Fssh_key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: Fssh_key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: Fssh_key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: Fssh_key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: Fssh_key_load_public: No such file or directory
debug1: identity file /root/.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_8.0-hpn14v15
debug1: match: OpenSSH_8.0-hpn14v15 pat OpenSSH* compat 0x04000000
debug2: fd 4 setting O_NONBLOCK
debug1: Authenticating to [destination-dns-name]:[destination-port] as 'root'
debug3: put_host_port: [[destination-dns-name]]:[destination-port]
debug3: Fssh_hostkeys_foreach: reading file "/root/.ssh/known_hosts"
debug3: Fssh_record_hostkey: found key type ECDSA in file /root/.ssh/known_hosts:1
debug3: Fssh_load_hostkeys: loaded 1 keys from [[destination-dns-name]]:[destination-port]
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
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: 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-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc
debug2: MACs ctos: 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: MACs stoc: 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: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,none
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,none
debug2: MACs ctos: 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: MACs stoc: 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: compression ctos: none
debug2: compression stoc: none
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
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
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:9nzPuSCXcbyzrowHhB5LvkZRII7LVZcCVTCm4p5JcZ4
debug3: verify_host_key_dns
DNS lookup error: general failure
debug3: put_host_port: [[destination-IP]]:[destination-port]
debug3: put_host_port: [[destination-dns-name]]:[destination-port]
debug3: Fssh_hostkeys_foreach: reading file "/root/.ssh/known_hosts"
debug3: Fssh_record_hostkey: found key type ECDSA in file /root/.ssh/known_hosts:1
debug3: Fssh_load_hostkeys: loaded 1 keys from [[destination-dns-name]]:[destination-port]
debug1: Host '[[destination-dns-name]]:[destination-port]' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug2: key: /root/.ssh/id_rsa (0x0)
debug2: key: /root/.ssh/id_dsa (0x0)
debug2: key: /root/.ssh/id_ecdsa (0x0)
debug2: key: /root/.ssh/id_ed25519 (0x0)
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: Fssh_kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
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: Trying private key: /root/.ssh/id_rsa
debug3: no such identity: /root/.ssh/id_rsa: No such file or directory
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /root/.ssh/id_ecdsa
debug3: no such identity: /root/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /root/.ssh/id_ed25519
debug3: no such identity: /root/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).
root@alpha-machine[[path]]#

 

[qubus]

I figured it out... sort of.

Not sure what the GUI SSH connection and key-pair setup does exactly but it does not translate to the CLI. Meaning it doesn't actually set up a key pair for SSH you can use as you would normally do.

Anyhow, I went the usual route and created a key pair in the CLI itself. That worked how it should:

• ssh-keygen -b 4096 to generate the key
• cat .ssh/[key-name].pub
• copy the contents
• paste the contents into the public key field on the destination using the web interface
• save
• done

It should be pointed out in those GUI screens, settings and the documentation that what the GUI does is something completely separate from the rest of the system (?). It's not mentioned anywhere. Or maybe it's a bug?

Hope I can save some people the headaches and hours of searching.

If anyone knows, I would still be interested to understand why there is a difference between the GUI SSH connection setup and the rest of the system. For example, if I have an SSH connection set up in the GUI, why can I not select it when I set up an RSYNC task in the GUI but can if I set up a Replication task?

 

[ragametal]

Thanks you, i just spend 2 hours trying to figure this out and i will just stop.
I have already established an rsync taks in SSH mode but i created the keypairs using the CLI. Since the general consensus in the forums is that you should not use the CLI unless necessary, i tried to change my ways and use the web GUI to create the SSH keypairs.

I was able to create a keypair and then used such keypair to make an SSH connection and assigned it to my rsync user.

But when i tried to make an rsync task (SSH Mode), with the same user i used to establish the SSH connection, i got an error saying

In order to use rsync over SSH you need a user with a private key (DSA/ECDSA/RSA) set up in home dir

I was surprised by this error because i used the same user for the Rsync task and the SSH connection and, as i mentioned before, this SSH connection was associated with the keypair i created via the web GUI.

It appears there is no way to assign a keypair to a user via the web gui, hence the error mentioned above. the GUI only allows to assign the keypairs to an SSH connection.

It also appears there is no way to assign an SSH connection created via the GUI to an Rsync Task. I honestly don't know how to use such SSH connection.

I just went back and created my user keypairs in the CLI to establish my Rsync task SSH connection and everything is good in the world again.

But I'm curious now. Does anybody knows the purpose or how to use these Tools from the GUI ("SSH keypairs" & SSH connections")?

 

[Patrick M. Hausen]

Does anybody knows the purpose or how to use these Tools from the GUI ("SSH keypairs" & SSH connections")?

I used them without problems for replication tasks. Root user to root user.

 

[ragametal]

I used them without problems for replication tasks. Root user to root user.

Thanks for the clarification in pointing out a possible use for this tool.