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

Improve this question
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. Commented Aug 8, 2021 at 14:38
  • Hey @telcoM - thanks for your reply. Please take a look at my most recent edit. :) Commented 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 Commented 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. Commented Aug 9, 2021 at 12:49

1 Answer 1

Reset to default
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.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.