0

there are several questions like this on the website but I have not been able to find one that resolves my issue.

I am performing some experiments regarding adaptive bitrate video streaming, and need one (server) node, which I can SSH into using FIP, to be able to access several (client) nodes, which do not have an FIP, but were made with the same private key that I have passed into my server using FTP.

So, all of my nodes were created using the key my_chameleon_key.pem. I have a remote connection established between myself and the server. Now, when I try and do an ssh from the server to the client, using ssh -i ~/.ssh/my_chameleon_key.pem -vT cc@<client_ip> where server_ip is an arbitrary selection from my list of client IP addresses, I get the following output:

OpenSSH_7.2p2 Ubuntu-4ubuntu2.10, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to <server_ip> [<server_ip>] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/cc/.ssh/my_chameleon_key.pem type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/cc/.ssh/my_chameleon_key.pem-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.10
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.10
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.10 pat OpenSSH* compat 0x04000000
debug1: Authenticating to <server_ip>:22 as 'cc'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:QaA4NOIFUybFLYXHcbg8iHuGUw1Komvn+o4Mx5bdf14
debug1: Host '<server_ip>' is known and matches the ECDSA host key.
debug1: Found key in /home/cc/.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: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/cc/.ssh/my_chameleon_key.pem
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

Again, server_ip is a client IP.

ls ~/.ssh outputs authorized_keys known_hosts my_chameleon_key.pem and I have verified that my_chameleon_key.pem was not modified during transfer.

I'm sure part of this is that I do not know how to navigate the -vT trace, but I am totally stumped here. What should I do to resolve this?

All servers are CC-Ubuntu16.04 and running with sudo didn't help if this is useful info. Let me know if I can provide anything else.

EDIT: By this point I have already ran several commands, so /var/log/auth.log is already pretty clogged. Here are the most recent things, which should (theoretically) be my SSH... however, it does not update when I try and SSH again, so I'm not sure.

Aug  8 15:47:16 mwhicks2abvsserver sshd[46351]: Accepted publickey for cc from 24.211.146.9 port 52223 ssh2: RSA SHA256:a6N6S9PllSObVyDZXJdG1GWUOkKhFTpIJ3Rae4sW8uQ
Aug  8 15:47:16 mwhicks2abvsserver sshd[46351]: pam_unix(sshd:session): session opened for user cc by (uid=0)
Aug  8 15:47:16 mwhicks2abvsserver systemd-logind[2861]: New session 8 of user cc.

Also, here is a link to my full auth.log file. It was too long for me to consider putting it here. https://pastebin.com/vsyXD7bM

4
  • Read /var/log/auth.log on the destination system. It will have the reason why the key was denied by its local sshd in plain language.
    – telcoM
    Aug 8, 2021 at 14:38
  • Hey @telcoM - thanks for your reply. Please take a look at my most recent edit. :) Aug 8, 2021 at 15:58
  • you could check the timestamps to see the relevant lines, or run something like tail -f /var/log/auth.log to see new lines as the appear in the file. The dump you have there only seems to say "Accepted publickey for cc...", so it doesn't really indicate any issue even existing
    – ilkkachu
    Aug 8, 2021 at 16:05
  • Something weird is going on and I can access them now... even though I didn't change anything since yesterday. I will keep this question up for now as this happens every once in a while. Aug 9, 2021 at 12:49

1 Answer 1

0

in the first place check if you have correct permissions of your private and public key files. SSH doesn't like too open permissions. I usually set chmod 700 for my .ssh directory containing the public key, for the public and private key i set chmod 600.

In my case this problem was caused because i have renamed the user and group and changed name of the home directory but forgot to change the home directory for user itself. So in /etc/passwd home was still pointing to old directory.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .