Score:0

Cannot ssh into newly created VM (with key used in creation)

cn flag

So my cloud provider has you cut/paste or drag/drop the id_rsa.pub key when creating the instance. The provisioning process sticks that key in the appropriate place as part of the process.

This works fine for my cow-orkers who are all on Linux/Windows. I am on a Mac (Monterey 12.3). It fails from either my mac native or a linux VM running on my Mac. Symptoms (names/IPs changed to protect the guilty):

bozo$ ssh -v user@new_ip

ssh -v [email protected]
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips  26 Jan 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 58: Applying options for *
debug1: Connecting to 10.333.80.223 [10.333.380.223] port 22.
debug1: Connection established.
debug1: identity file /home/me/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/me/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/me/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/me/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/me/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/me/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/me/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/me/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 10.333.380.223:22 as 'me'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
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: kex: curve25519-sha256 need=64 dh_need=64
debug1: kex: curve25519-sha256 need=64 dh_need=64
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:P95KW1jM38eMCM172VHOjR5DY58Oo0qbgs1ZnZHwY+U
debug1: Host '10.333.380.223' is known and matches the ECDSA host key.
debug1: Found key in /home/me/.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,gssapi-keyex,gssapi-with-mic
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available (default cache: KEYRING:persistent:1001)

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available (default cache: KEYRING:persistent:1001)

debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/me/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Trying private key: /home/me/.ssh/id_dsa
debug1: Trying private key: /home/me/.ssh/id_ecdsa
debug1: Trying private key: /home/me/.ssh/id_ed25519
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Note that the permissions on my .ssh, id_rsa.pub, id_rsa,and .. are all correct.

[jump_me@localhost .ssh]$ ls -ld id_rsa id_rsa.pub . ..
drwx------. 2 me me   73 Mar 21 22:25 .
drwx------. 4 me me 4096 Mar 21 22:24 ..
-rw-------. 1 me me 1675 Feb 19  2019 id_rsa
-rw-r--r--. 1 me me  400 Feb 19  2019 id_rsa.pub

further note that the only way to get in is through the pre-built ssh keys. No username/pwd is available, so you cannot log in to change anything on the VM.

Ideas?

dave_thompson_085 avatar
jp flag
Your client is offering the key but the server is not accepting it. Try `diff <(ssh-keygen -yf .ssh/id_rsa) <(awk NF=2 .ssh/id_rsa.pub)` to make sure your pub-file matches the actual key. Also are you sure you are using the correct (i.e. provisioned) username?
cn flag
Thanks Dave. The diff comes back clean (return code 0), and yes, using the correct provisioned user. The username in the key, of course, does not match the provisioned username, but that's because it matches the username on the client.
dave_thompson_085 avatar
jp flag
Then I'm at a loss. See if somebody can look at the server logs for any indication why it dislikes your key -- although sshd normally doesn't log much :-(
Score:0
ci flag

disable seLinux

sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/sysconfig/selinux sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config

And restart de SO

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.