I’m rather well-practiced to installing Fedora cloud images on Amazon EC2.
Today I tried to install Fedora 31 Cloud on a standard x64 HVM.
To be precise, the one for Ireland,
EU West (Ireland) ami-02765e71fe7b1e036
which is indicated at Fedora Cloud under " Fedora 31 Standard Base Cloud HVM AMIs".
Everything went well, but I could not log in via SSH using the usual “fedora” username (I also tried a few other usernames). I always got “permission denied” from the remote SSH server.
Thinking I had messed up somewhere, I tried the whole procedure again, with a new instance and a new public/private keypair. Same result: No login possible.
I then tested with an Fedora Cloud 30 image. This worked perfectly, login was possible.
As anyone observed some problem with Fedora Cloud 31 and SSH login?
Yes there is. When you initially configure your AWS instance, you can choose an “existing keypair” or demand to be given a “new keypair”, upon which you are invited to download the PRIVATE key of part of the SSH keypair. One chance only!
Kindly do the steps below in order to collect more technical data that can help us to solve the issue:
You have to download the public key from AWS to your local machine and save it in a safe place.
I would suggest you use the dedicated directory for keys ~/.ssh in order to avoid extra work with permissions.
chmod 400 ~/.ssh/mycert.pem - give to this read-only permissions to your user only
ls -l mycert.pem - ensure that there is correct permissions, group and user owner. Also, send the output to here. You can hide your cert name.
ssh -i ~/.ssh/mycert.pem -vvv AWS.IP.EXAMPLE.COM - attach all debug output here. You have to specify pubkey with -i option.
Looking through the log and searching some more brings:
Where a participant writes:
In my case, it was due to an old public key file lying around in the .ssh directory:
Moving/deleting the id_rsa.pub from the .ssh directory solved the problem.
From what I understand: when there is a public key present on the client-side, SSH [first] validates the private key against it. If it fails, it won’t try to use the private key to connect remotely.
I had the public key from the previous server lying around:
fedora@(baloo).sshkey.pub
which goes with the private key file
fedora@(baloo).sshkey
which is passed on the command line with the -i option.
I had just filled the private RSA key handed out by Amazon EC2 into
fedora@(baloo).sshkey
without removing or updating the corresponding file with the public key (who would?)
Removing the file with the public key solved the problem!
I would never have guessed.
Here is -vvv output of a failed connection attempt in any case.
The fact that “ED25519” is indicated although AWS EC2 hands out RSA is telling … I used ED25519 in for previous key. The filename indicated is the “stem” filename though, not the name of the public key.
(IP address elided; it’s a dynamically assigned address at EC2 Ireland anyway)
debug1: Will attempt key: /home/user/.ssh/keys/fedora@(baloo).sshkey ED25519 SHA256:JUbTkRpSowiAUj8SwQFliV0VxjAFPsVmMg8tjISRzzs explicit
debug2: pubkey_prepare: done
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,gssapi-keyex,gssapi-with-mic
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available (default cache: KCM:)
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available (default cache: KCM:)
debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/calvin/.ssh/keys/fedora@(baloo).sshkey ED25519 SHA256:JUbTkRpSowiAUj8SwQFliV0VxjAFPsVmMg8tjISRzzs explicit
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
fedora@52.19.XX.XX: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
For a successful login:
debug1: Will attempt key: /home/calvin/.ssh/keys/fedora@(baloo).sshkey explicit
debug2: pubkey_prepare: done
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,gssapi-keyex,gssapi-with-mic
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available (default cache: KCM:)
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available (default cache: KCM:)
debug2: we did not send a packet, disable method
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/calvin/.ssh/keys/fedora@(baloo).sshkey
debug3: sign_and_send_pubkey: RSA SHA256:/6diyu2LU4Qok3OTCQHWIHlGdjuQjTNS3RRlNQB68uE
debug3: sign_and_send_pubkey: signing using rsa-sha2-256
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).
Authenticated to 52.19.XX.XX ([52.19.XX.XX]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 80
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug3: receive packet: type 4
debug1: Remote: /home/fedora/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug3: receive packet: type 91
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 4 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x48
debug2: client_session2_setup: id 0