2

Problem

I cannot connect to my homeserver via passwordless SSH login from my clientcomputer/remotecomputer via my relayserver.

I get homeserver@localhost: Permission denied (publickey).

History/procedure completed so far

  1. Set up a homeserver (Kali Debian) behind NAT, installed open-ssh, generated the keys, edited the sshd_config file to not allow passwords.
  2. Set up the relaysever (AWS Ubuntu AMI), installed open-ssh, generated the keys, edited the sshd_config file to not allow passwords.
  3. Set up the clientcomputer (Kali Debian running on a VMware workstation), installed open-ssh, generated the keys.
  4. Modified the following permissions on homeserver, relayserver & clientcomuter:

    • .ssh directory permissions to 700 (drwx------)
    • public key (.pub file) to 644 (-rw-r--r--)
    • private key (id_rsa) to 600 (-rw-------)
    • home directory to 755 (drwxr-xr-x)

I then passed the authentication keys to my relay server from both my homeserver and my clientcomputer and logged in. No issue.

I added GewayPorts yes to the ssshd_config file on the relayserver.

I then completed the following commands:

On the homeserver:

ssh -fN -R 10022:localhost:22 relayserver_user@1.1.1.1

On the relayserver:

relayserver~$ sudo netstat -nap | grep 10022 -- to check the connection - seems all good:

On the clientcomputer (after I connect to the relayserver):

ssh -p 10022 homeserver_user@localhost

This is where it first says failed authentication key. Not sure whats going on because when I edit the sshd_config file on the homeserver to passwordauthentication yes the remote tunnel works without issue.

Also when I try the command for a second time it gets stuck in debug (see below).

Note that I am readying the homeserver via teamviewer.

Dumps and Logs

Dump from testing the relayserver:

tcp        0      0 0.0.0.0:10022           0.0.0.0:*               LISTEN      2878/sshd: ubuntu   
tcp6       0      0 :::10022                :::*                    LISTEN      2878/sshd: ubuntu 

Dump from the -vvv during clientcomputer when connecting to the homeserver after loggin into the relayserver 1st attempt:

OpenSSH_7.6p1 Ubuntu-4, OpenSSL 1.0.2n  7 Dec 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "localhost" port 10022
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to localhost [127.0.0.1] port 10022.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/ubuntu/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/ubuntu/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/ubuntu/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/ubuntu/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/ubuntu/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/ubuntu/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/ubuntu/.ssh/id_ed25519 type 3
debug1: key_load_public: No such file or directory
debug1: identity file /home/ubuntu/.ssh/id_ed25519-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.7p1 Debian-3
debug1: match: OpenSSH_7.7p1 Debian-3 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to localhost:10022 as 'homeserver'
debug3: put_host_port: [localhost]:10022
debug3: hostkeys_foreach: reading file "/home/ubuntu/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/ubuntu/.ssh/known_hosts:2
debug3: load_hostkeys: loaded 1 keys from [localhost]:10022
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
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
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: ssh-rsa,rsa-sha2-512,rsa-sha2-256,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
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
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
debug2: compression stoc: none,zlib@openssh.com
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:yfx8V8nVyZNs0bF1IXLB5Ud5fF1iHYgp1+0dVwHqlx4
debug3: put_host_port: [127.0.0.1]:10022
debug3: put_host_port: [localhost]:10022
debug3: hostkeys_foreach: reading file "/home/ubuntu/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/ubuntu/.ssh/known_hosts:2
debug3: load_hostkeys: loaded 1 keys from [localhost]:10022
debug1: Host '[localhost]:10022' is known and matches the ECDSA host key.
debug1: Found key in /home/ubuntu/.ssh/known_hosts:2
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: /home/ubuntu/.ssh/id_rsa ((nil))
debug2: key: /home/ubuntu/.ssh/id_dsa ((nil))
debug2: key: /home/ubuntu/.ssh/id_ecdsa ((nil))
debug2: key: /home/ubuntu/.ssh/id_ed25519 (0x56263b49fb50)
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: 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 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: Trying private key: /home/ubuntu/.ssh/id_rsa
debug3: no such identity: /home/ubuntu/.ssh/id_rsa: No such file or directory
debug1: Trying private key: /home/ubuntu/.ssh/id_dsa
debug3: no such identity: /home/ubuntu/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/ubuntu/.ssh/id_ecdsa
debug3: no such identity: /home/ubuntu/.ssh/id_ecdsa: No such file or directory
debug1: Offering public key: ED25519 SHA256:AvsGsfq4sXyTubnuWOgb***********jVBPIyFEQ9/UY /home/ubuntu/.ssh/id_ed25519
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg ssh-ed25519 blen 51
debug2: input_userauth_pk_ok: fp SHA256:AvsGsfq4sXyTubnuWOgbL**********FEQ9/UY
debug3: sign_and_send_pubkey: ED25519 SHA256:AvsGsfq4sXyT************
debug3: no such identity: /home/ubuntu/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
homeserver@localhost: Permission denied (publickey).

Dump from the -vvv during clientcomputer when connecting to the homeserver after loggin into the relayserver 2nd attempt:

OpenSSH_7.6p1 Ubuntu-4, OpenSSL 1.0.2n  7 Dec 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "localhost" port 10022
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to localhost [127.0.0.1] port 10022.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/ubuntu/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/ubuntu/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/ubuntu/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/ubuntu/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/ubuntu/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/ubuntu/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/ubuntu/.ssh/id_ed25519 type 3
debug1: key_load_public: No such file or directory
debug1: identity file /home/ubuntu/.ssh/id_ed25519-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4

I also tried (without success) creating a id_ed25519.pub key on the clientcomputer and adding it to the /home/.ssh/ directory on the relayserver - as you can see in the dumps (above).

Dump from grep 'sshd' /var/log/auth.log on homeserver:

Aug 14 06:04:48 homeserver-host sshd[3364]: /etc/ssh/sshd_config line 38: Deprecated option RSAAuthentication
Aug 14 06:04:49 homeserver-host sshd[3364]: reprocess config line 38: Deprecated option RSAAuthentication
Aug 14 06:04:49 homeserver-host sshd[3364]: Connection closed by authenticating user homeserver ::1 port 43536 [preauth]
Aug 14 06:26:34 homeserver-host sudo: homeserver : TTY=pts/0 ; PWD=/home/homeserver/.ssh ; USER=root ; COMMAND=/bin/grep sshd /var/log/auth.log
Aug 14 06:36:57 homeserver-host sudo: homeserver : TTY=pts/1 ; PWD=/etc/ssh ; USER=root ; COMMAND=/bin/nano sshd_config
Aug 14 06:38:44 homeserver-host sshd[5932]: Server listening on 0.0.0.0 port 22.
Aug 14 06:38:44 homeserver-host sshd[5932]: Server listening on :: port 22.
Aug 14 06:39:56 homeserver-host sshd[5975]: Connection closed by authenticating user homeserver ::1 port 43560 [preauth]
Aug 14 06:54:27 homeserver-host sudo: homeserver : TTY=pts/2 ; PWD=/home/homeserver ; USER=root ; COMMAND=/bin/nano /etc/ssh/sshd_config
Aug 14 10:37:13 homeserver-host sshd[5932]: Received SIGHUP; restarting.
Aug 14 10:37:13 homeserver-host sshd[5932]: Server listening on 0.0.0.0 port 22.
Aug 14 10:37:13 homeserver-host sshd[5932]: Server listening on :: port 22.
Aug 14 10:37:23 homeserver-host sshd[5932]: Received SIGHUP; restarting.
Aug 14 10:37:23 homeserver-host sshd[5932]: Server listening on 0.0.0.0 port 22.
Aug 14 10:37:23 homeserver-host sshd[5932]: Server listening on :: port 22.
Aug 14 13:31:19 homeserver-host sshd[5932]: Received SIGHUP; restarting.
Aug 14 13:31:19 homeserver-host sshd[5932]: Server listening on 0.0.0.0 port 22.
Aug 14 13:31:19 homeserver-host sshd[5932]: Server listening on :: port 22.
Aug 14 13:31:24 homeserver-host sshd[5932]: Received SIGHUP; restarting.
Aug 14 13:31:24 homeserver-host sshd[5932]: Server listening on 0.0.0.0 port 22.
Aug 14 13:31:24 homeserver-host sshd[5932]: Server listening on :: port 22.
Aug 14 13:43:02 homeserver-host sshd[5932]: Received SIGHUP; restarting.
Aug 14 13:43:02 homeserver-host sshd[5932]: Server listening on 0.0.0.0 port 22.
Aug 14 13:43:02 homeserver-host sshd[5932]: Server listening on :: port 22.
Aug 14 13:43:12 homeserver-host sshd[5932]: Received SIGHUP; restarting.
Aug 14 13:43:12 homeserver-host sshd[5932]: Server listening on 0.0.0.0 port 22.
Aug 14 13:43:12 homeserver-host sshd[5932]: Server listening on :: port 22.
Aug 14 16:30:03 homeserver-host sshd[5932]: Received signal 15; terminating.
Aug 14 23:00:27 homeserver-host sshd[3069]: Connection closed by authenticating user homeserver ::1 port 33912 [preauth]
Aug 14 23:45:51 homeserver-host sudo: homeserver : TTY=pts/0 ; PWD=/home/homeserver ; USER=root ; COMMAND=/bin/grep sshd /var/log/auth.log

Hope someone can help!

  • You didn't supply option -i /path/to/private.key in ssh command on client side. Also make sure private key file has 600 permissions. – Alex Aug 15 '18 at 14:07
  • It was my understanding that u should never pass private keys? Do you know why i should have to do this on this occation. Thanks for your help. – Betty Aug 19 '18 at 12:50
  • That's how public key authentication working. Simplified model: cut a dollar to billion parts, mixed it well, then separate pieces in two piles and named one as public and another as private. The only those who has both piles can restore dollar back. The same with your case, you placed public key to a remote machine and use private key to complete authentication puzzle. That why it calls asymmetric cryptography where both keys need to be in use. Your private key never leaving your pc, but used (on your PC only) to encrypt msgs. – Alex Aug 20 '18 at 5:28
  • i understand - thanks. Do you know why i would suddenly have to now start specifying to open-ssh where the private key is. It always seemed to know where the keys are for 'normal' computer to computer (authentication key) connections. Is this just a characteristic of reverse SSH tunnels with pass-wordless SSH login? – Betty Aug 20 '18 at 9:51
  • If you set PasswordAuthentication no in sshd_config then SSH will allow to only using public key authentication, regardless how you using SSH, either for "normal" connection to remote host or for reverse tunnel or even for using scp. The public key authentication is the strongest point of SSH since regular passwords can be brute-forced while with public keys it's practically impossible. If you don't want to use -i option, you can set all SSH's command line option in ~/.ssh/config file that would applied to particular host. – Alex Aug 20 '18 at 15:45

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.