AWS's EC2 launch process can inject an SSH key into an image, however, it can only inject RSA keys. It won't accept anything else.
Fedora 33 doesn't allow RSA keys for SSH.
Thus, when I launch an F33 image in EC2 (using the Cloud images, specifically:
Fedora-Cloud-Base-33-1.2.x86_64-hvm-us-east-2-gp2-0 (ami-0c54097900b6afcbe)
I can't ssh into it.
Is there any way to actually use Fedora-Cloud-Base-33 in EC2?
Kevin
On 11/9/20 3:40 PM, Kevin White wrote:
AWS's EC2 launch process can inject an SSH key into an image, however, it can only inject RSA keys. It won't accept anything else.
Fedora 33 doesn't allow RSA keys for SSH.
Thus, when I launch an F33 image in EC2 (using the Cloud images, specifically:
Fedora-Cloud-Base-33-1.2.x86_64-hvm-us-east-2-gp2-0 (ami-0c54097900b6afcbe)
I can't ssh into it.
Is there any way to actually use Fedora-Cloud-Base-33 in EC2?
Fedora recently upgraded it's crypto policies to be more secure including removing some support for weak algorithms. See https://www.openssh.com/txt/release-8.3 for more information.
Try `ssh -oHostKeyAlgorithms=-ssh-rsa fedora@x.x.x.x`
Dusty
I understand that weak algorithms have been removed. I don't think the problem is the host key. The problem is the user key.
In a vanilla F33 instance in EC2, you have no way to connect to it. The EC2 creation process uses cloud-init (I think) to inject a user key into the default user's ~/.ssh/authorized_keys file on first boot. The EC2 process will only inject an RSA key. The SSH daemon on F33 won't accept any RSA keys. Thus, you can't connect.
And since there's no back door, no console, there's no way to get to the instance, at least that I can figure out.
In other words, I can't figure out how anyone can use an of the "Fedora 33 Cloud Base Images for Amazon Public Cloud" listed on:
https://alt.fedoraproject.org/cloud/
I'm not sure how one can connect to an image after creating it.
I just tested the F33 AMI in Sydney region - was able to log in OK using an existing SSH key (Amazon pem).
Fedora-Cloud-Base-33-1.2.x86_64-hvm-ap-southeast-2-gp2-0 ami-06e080dd692099361
On Tue, 10 Nov 2020 at 11:38, Kevin White fedora-kevin@kevbo.org wrote:
I understand that weak algorithms have been removed. I don't think the problem is the host key. The problem is the user key.
In a vanilla F33 instance in EC2, you have no way to connect to it. The EC2 creation process uses cloud-init (I think) to inject a user key into the default user's ~/.ssh/authorized_keys file on first boot. The EC2 process will only inject an RSA key. The SSH daemon on F33 won't accept any RSA keys. Thus, you can't connect.
And since there's no back door, no console, there's no way to get to the instance, at least that I can figure out.
In other words, I can't figure out how anyone can use an of the "Fedora 33 Cloud Base Images for Amazon Public Cloud" listed on:
https://alt.fedoraproject.org/cloud/
I'm not sure how one can connect to an image after creating it. _______________________________________________ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org
Thank you for trying. That's good to know. I must be having some other problem. I will reply when I figure it out.
OK, the problem isn't with the key, it is with Putty.
I use both Windows and Linux to connect to instances. It is just the way I've evolved to work over many years.
When I connect to the instance using a modern Linux (CentOS 7) using my existing key, the connection works (sshd logs on the f33 instance:)
Nov 10 04:15:15 ip-x-x-x-x sshd[7204]: Accepted publickey for fedora from x-x-x-x port 43114 ssh2: RSA SHA256:xxxxxx
When I take the same key, import it into Putty's puttygen, save it in Putty's format, and use it to log into the same server, I get "too many auth failures", and the log file shows this:
Nov 10 04:34:10 ip-x-x-x-x sshd[7402]: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedKeyTypes [preauth]
I had this problem locally too, when I upgraded an f32 box to f33, but I "fixed" it by moving to an ed25519 key. I assumed that the key type was the fix. I was wrong: the hash algorithm is the issue.
I'm not sure what Putty is doing wrong: I don't know if it "imports" the hash from the key. I did this on my actual key (on Centos):
ssh-keygen -l -f id_rsa_jeffs_aws_2018-07-10 2048 SHA256:xxx no comment (RSA)
and the hash provided there matches the hash showed in the successful login log line (obviously). So Putty is somehow taking that key and presenting it "wrong".
Regardless: this isn't a Fedora Cloud problem. It isn't a Fedora problem at all, but a Putty problem.
I'm sorry for the noise. Hopefully this chain will help someone else if they have the same issues that I have had and come to the same wrong conclusion.
Kevin
Don't know if you're aware or not (I wasn't for a long time) but Windows 10 has a CLI ssh client that runs in a CMD shell and works pretty much like the Linux client. It doesn't need PPK keys either from memory.
On Tue, 10 Nov 2020 at 15:40, Kevin White fedora-kevin@kevbo.org wrote:
OK, the problem isn't with the key, it is with Putty.
I use both Windows and Linux to connect to instances. It is just the way I've evolved to work over many years.
When I connect to the instance using a modern Linux (CentOS 7) using my existing key, the connection works (sshd logs on the f33 instance:)
Nov 10 04:15:15 ip-x-x-x-x sshd[7204]: Accepted publickey for fedora from x-x-x-x port 43114 ssh2: RSA SHA256:xxxxxx
When I take the same key, import it into Putty's puttygen, save it in Putty's format, and use it to log into the same server, I get "too many auth failures", and the log file shows this:
Nov 10 04:34:10 ip-x-x-x-x sshd[7402]: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedKeyTypes [preauth]
I had this problem locally too, when I upgraded an f32 box to f33, but I "fixed" it by moving to an ed25519 key. I assumed that the key type was the fix. I was wrong: the hash algorithm is the issue.
I'm not sure what Putty is doing wrong: I don't know if it "imports" the hash from the key. I did this on my actual key (on Centos):
ssh-keygen -l -f id_rsa_jeffs_aws_2018-07-10 2048 SHA256:xxx no comment (RSA)
and the hash provided there matches the hash showed in the successful login log line (obviously). So Putty is somehow taking that key and presenting it "wrong".
Regardless: this isn't a Fedora Cloud problem. It isn't a Fedora problem at all, but a Putty problem.
I'm sorry for the noise. Hopefully this chain will help someone else if they have the same issues that I have had and come to the same wrong conclusion.
Kevin _______________________________________________ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org
On Tue, Nov 10, 2020 at 04:40:46AM -0000, Kevin White wrote:
OK, the problem isn't with the key, it is with Putty.
Ah, good to know!