Ssh-keygen -t rsa in Rocky 8.5 vs Rocky 8.10

I am using Java jsch 0.2.26 for SSH communications between different users within the Rocky 8.5 system. Before I used jsch 0.1.56 on the same platform. To allow for Java to have passwordless SSH I had to run “ssk-keygen -m PEM -t rsa -b 2048”. I learnt that simply running “ssh-keygen -t rsa” in Rocky 8.5 will yield a 3072-bit key by default. My legacy key was not supported by default. Anyway, I upgraded from 0.1.56 to 0.2.26. Then I could remove the old 2048-bit key and install the 3072-bit key.

I then installed Rocky 8.10. After running “ssh-keygen -t rsa” on this new OS, I now get an issue of “invalid private key”. To fix this, I had to change and use “ssh-keygen -m PEM -t rsa”. Then the PEM format was accepted. Is there a new change in Rocky 8.10 OpenSSH that requires the change in format? Will it cause any issues when upgrading from 8.5 to 8.10 in the near future?

You can:

  • Check at the version of package openssh in 8.5 and then look at rpm -q --changelog openssh in 8.10. The log entries since 8.5 (or the ones that cannot be found from the 8.5’s log) could hint something
  • Browse through RHEL Release notes for versions 8.6–8.10 (in Red Hat Enterprise Linux | 8 | Red Hat Documentation )

Not sure I understand your problem. On Rocky 8.10 I just did:

ssh-keygen -t rsa

and it worked fine generating me a 3072 rsa key. Sounds like something strange with your machine configuration. But we would need a lot more detail than what you’ve posted to be able to help.

Thank you @jlehtone. I notice that the openssh on 8.10 first install is a newer version with lots of CVE fixes. I guess this introduces the format change. But if I install 8.5 and run the upgrade to 8.10, the openssh version remains the same.
I will do the upgrade and then upgrade openssh eventually.

Please run rpm -q openssh on three systems:

  • 8.5
  • 8.5 upgraded to latest
  • 8.10

Do you get the exact same strings, or different?

For 8.5 and 8.5 upgraded to latest it is the same (openssh 8.0).

For 8.10, it is openssh 8.7.

So they are different strings.

On Rocky 8’s repo I do see: openssh-8.0p1-25.el8_10.x86_64.rpm
and that is clearly nothing like “8.7”.

The Rocky vault shows that Rocky 8.5 had openssh-8.0p1-10.el8.x86_64.rpm
Therefore, the expectation is:
The 8.5 should show 8.0p1-10.el8
The 8.5 after update: 8.0p1-25.el8_10 (which differs from before update)
The 8.10 (with update): 8.0p1-25.el8_10


Rocky 9 has OpenSSH 8.7p1-45.el9.rocky.0.1 (currently).


In other words, your “8.10” is not a real Rocky 8, but some chimera of who-knows-what.

Oh yes, I now see my mistake. I do not know where I got “8.7” from.

Someone also sent me screenshots of the different environments and they show 8.0p1-10 and 8.0p1-24 (without update). I have asked them to do a ‘dnf list updates | grep openssh’ because there should be a 8.0p1-25.el8_10 update.

Everything is now starting to make sense. More importantly, I will be able to read the changelog correctly.

1 Like

If it is an RPM, then:

# dnf list openssh
Installed Packages
openssh.x86_64                8.0p1-25.el8_10                        @baseos
Available Packages
openssh.x86_64                8.0p1-25.el8_10.alma.1                 baseos

This output is from an AlmaLinux 8 system. It tells (with the @baseos) that the currently installed
package is from repo ‘baseos’ of AlmaLinux and that same repo has an update available (that I should install).

On another system I see:

modeller.x86_64               9.19-1                 @/modeller-9.19-1.x86_64

which tells that I have installed local package file (i.e. not from repo), e.g.

dnf install modeller-9.19-1.x86_64.rpm

Also, dnf has history. For the above-mentioned “modeller”:

# yum history list modeller
Loaded plugins: changelog, fastestmirror, langpacks, list-data, nvidia, priorities, show-leaves, verify
ID     | Command line             | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------
   344 | install /home/jlehtone/D | 2017-09-08 13:34 | Install        |    1 EE

I have also rather long bash history, so I could check that too:
history | grep install.*modeller
(Alas, the history was not that long. Reality: it got wiped at some point.)

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.