Apparently, RSA is insecure, so some time ago it was deprecated for use
with SSH. It is now actually disabled as of Ubuntu 22.04.

All of which I only discovered after upgrading my rPi to Ubuntu 22.04,
i.e I was left scratching my head, figuring out why my long term
existing SSH RSA key was now being rejected.

The solution was to generate a new key pair using Ed25519 instead of RSA.

If it has already changed for Ubuntu, presumably Pi OS will soon follow.

On 7/14/22 7:22 PM, Pancho wrote:
> Apparently, RSA is insecure, so some time ago it was deprecated for use
> with SSH. It is now actually  disabled as of Ubuntu 22.04.

Is it truly disabled? Or is it just the new default of not using it?

Check out the OpenSSH Legacy Options page. I've been able to re-enable
support for older methods using command line options / config file tweaks.

Link - OpenSSH: Legacy Options
- https://www.openssh.com/legacy.html

--
Grant. . . .
unix || die

Grant Taylor <gtaylor@tnetconsulting.net> wrote:
> On 7/14/22 7:22 PM, Pancho wrote:
>> Apparently, RSA is insecure, so some time ago it was deprecated for use
>> with SSH. It is now actually  disabled as of Ubuntu 22.04.
>
> Is it truly disabled?

It definitely isn't. The SHA1 variant is. If you generate a new pair it
will use SHA2 by default, I believe (can't check now but had no trouble
generating one when setting up 22.04, without specifying the algorithm). If
you want to be explicit, use "ssh-keygen -t rsa-sha2-512 -b 2048" (good
enough, really, and 4096 will take much longer on a Pi).

SHA1 support can be re-enabled in /etc/ssh/ssh_config with
"PubkeyAcceptedKeyTypes +ssh-rsa" and a reboot but it is indeed unsafe.

On 7/14/22 10:44 PM, A. Dumas wrote:
> SHA1 support can be re-enabled in /etc/ssh/ssh_config with
> "PubkeyAcceptedKeyTypes +ssh-rsa" and a reboot but it is indeed unsafe.

You shouldn't need to reboot. You should be able to restart the SSH
daemon independently, without a reboot.

--
Grant. . . .
unix || die

Grant Taylor <gtaylor@tnetconsulting.net> wrote:
> On 7/14/22 10:44 PM, A. Dumas wrote:
>> SHA1 support can be re-enabled in /etc/ssh/ssh_config with
>> "PubkeyAcceptedKeyTypes +ssh-rsa" and a reboot but it is indeed unsafe.
>
> You shouldn't need to reboot. You should be able to restart the SSH
> daemon independently, without a reboot.

Well, of course, but if a user can't even google their problem and a
possible solution, then restarting a service might also be too much to ask.
Reboot is much easier and also works ¯\_(ツ)_/¯

On 7/15/22 4:25 AM, A. Dumas wrote:
> Well, of course, but if a user can't even google their problem and a
> possible solution, then restarting a service might also be too much
> to ask. Reboot is much easier and also works ¯\_(ツ)_/¯

Sometimes I really hate it when people are correct. This is one of
those times. *HEAVYsigh*

--
Grant. . . .
unix || die

A. Dumas <alexandre@dumas.fr.invalid> wrote:
> Grant Taylor <gtaylor@tnetconsulting.net> wrote:
> > On 7/14/22 10:44 PM, A. Dumas wrote:
> >> SHA1 support can be re-enabled in /etc/ssh/ssh_config with
> >> "PubkeyAcceptedKeyTypes +ssh-rsa" and a reboot but it is indeed unsafe.
> >
> > You shouldn't need to reboot. You should be able to restart the SSH
> > daemon independently, without a reboot.
>
> Well, of course, but if a user can't even google their problem and a
> possible solution, then restarting a service might also be too much to ask.
> Reboot is much easier and also works ¯\_(ツ)_/¯

Maybe, although:

sudo service ssh reload

(or 'sudo service ssh restart')

isn't hard. It's more complicated to edit the config file.

Theo

A. Dumas <alexandre@dumas.fr.invalid> writes:
> Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>> On 7/14/22 7:22 PM, Pancho wrote:
>>> Apparently, RSA is insecure, so some time ago it was deprecated for use
>>> with SSH. It is now actually  disabled as of Ubuntu 22.04.
>>
>> Is it truly disabled?
>
> It definitely isn't. The SHA1 variant is. If you generate a new pair it
> will use SHA2 by default, I believe (can't check now but had no trouble
> generating one when setting up 22.04, without specifying the
> algorithm).

RSA keys are not bound to a particular signature algorithm, that is a
separate piece of configuration.

> If you want to be explicit, use "ssh-keygen -t rsa-sha2-512 -b 2048"
> (good enough, really, and 4096 will take much longer on a Pi).

“ssh-keygen -t rsa” is sufficient.

--
https://www.greenend.org.uk/rjk/

Theo <theom+news@chiark.greenend.org.uk> wrote:
> A. Dumas <alexandre@dumas.fr.invalid> wrote:
>> Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>>> On 7/14/22 10:44 PM, A. Dumas wrote:
>>>> SHA1 support can be re-enabled in /etc/ssh/ssh_config with
>>>> "PubkeyAcceptedKeyTypes +ssh-rsa" and a reboot but it is indeed unsafe.
>>>
>>> You shouldn't need to reboot. You should be able to restart the SSH
>>> daemon independently, without a reboot.
>>
>> Well, of course, but if a user can't even google their problem and a
>> possible solution, then restarting a service might also be too much to ask.
>> Reboot is much easier and also works ¯\_(ツ)_/¯
>
> Maybe, although:
>
> sudo service ssh reload
>
> (or 'sudo service ssh restart')
>
> isn't hard. It's more complicated to edit the config file.

You see, I would say force-reload, just to be sure (reloads if possible,
otherwise restarts). But also, I am not sure if any other services depend
on that config change. Probably not, but again, just to be sure... Is every
service completely self-contained under systemd? I'm not an admin so I
don't know. If I were behind the keyboard I would try to reload and test if
it works. Ah well.

On 18.7.22 11.54, Richard Kettlewell wrote:
> A. Dumas <alexandre@dumas.fr.invalid> writes:
>> Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>>> On 7/14/22 7:22 PM, Pancho wrote:
>>>> Apparently, RSA is insecure, so some time ago it was deprecated for use
>>>> with SSH. It is now actually  disabled as of Ubuntu 22.04.
>>>
>>> Is it truly disabled?
>>
>> It definitely isn't. The SHA1 variant is. If you generate a new pair it
>> will use SHA2 by default, I believe (can't check now but had no trouble
>> generating one when setting up 22.04, without specifying the
>> algorithm).
>
> RSA keys are not bound to a particular signature algorithm, that is a
> separate piece of configuration.
>
>> If you want to be explicit, use "ssh-keygen -t rsa-sha2-512 -b 2048"
>> (good enough, really, and 4096 will take much longer on a Pi).
>
> “ssh-keygen -t rsa” is sufficient.

OpenSSH changed recently the private key encoding format, and
many SSH servers or clients are not happy with the new one.

The keys are in text format. Look at ~/.ssh/id_rsa if it exists.
If the file starts with:

-----BEGIN OPENSSH PRIVATE KEY-----

it should be converted:

cd ~/.ssh
cp id_rsa id_rsa.pem
ssh-keygen -p -m PEM -P "" -N "" -f ~/.ssh/id_rsa.pem

The private key in PEM format begins with:

-----BEGIN RSA PRIVATE KEY-----

Try the new key and if it works, replace id_rsa with it.

--

-TV

On Sat, 16 Jul 2022 16:55:52 +0100, Theo wrote:

> A. Dumas <alexandre@dumas.fr.invalid> wrote:
>> Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>> > On 7/14/22 10:44 PM, A. Dumas wrote:
>> >> SHA1 support can be re-enabled in /etc/ssh/ssh_config with
>> >> "PubkeyAcceptedKeyTypes +ssh-rsa" and a reboot but it is indeed unsafe.
>> >
>> > You shouldn't need to reboot. You should be able to restart the SSH
>> > daemon independently, without a reboot.
>>
>> Well, of course, but if a user can't even google their problem and a
>> possible solution, then restarting a service might also be too much to ask.
>> Reboot is much easier and also works ¯\_(ツ)_/¯
>
> Maybe, although:
>
> sudo service ssh reload
>
> (or 'sudo service ssh restart')
>
> isn't hard. It's more complicated to edit the config file.
>

lol
Except that it's "service sshd", not "service ssh", so the user would
get an error and be confused. Or even better, they might have systemd.
That just reinforces that it's simpler for the unknowing to reboot.
The knowing likely don't need the instructions for how to restart the
service, just a reminder to do so.

Joe Beanfish <joebeanfish@nospam.duh> wrote:
> Except that it's "service sshd", not "service ssh",

Nope, not on systemd at least where it should be ssh.

On Mon, 18 Jul 2022 17:49:38 +0000, A. Dumas wrote:

> Joe Beanfish <joebeanfish@nospam.duh> wrote:
>> Except that it's "service sshd", not "service ssh",
>
> Nope, not on systemd at least where it should be ssh.

Depends on distro I guess. On CentOS, it's

# systemctl status ssh
Unit ssh.service could not be found.
# systemctl status sshd
● sshd.service - OpenSSH server daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
Docs: man:sshd(8)
man:sshd_config(5)
Main PID: 974 (sshd)
CGroup: /system.slice/sshd.service
└─974 /usr/sbin/sshd -D

One more reason the reboot is the simpler instruction that always works
for a noob. :)

On 19/07/2022 15:27, Joe Beanfish wrote:
> On Mon, 18 Jul 2022 17:49:38 +0000, A. Dumas wrote:
>
>> Joe Beanfish <joebeanfish@nospam.duh> wrote:
>>> Except that it's "service sshd", not "service ssh",
>>
>> Nope, not on systemd at least where it should be ssh.
>
> Depends on distro I guess. On CentOS, it's
>
> # systemctl status ssh
> Unit ssh.service could not be found.
> # systemctl status sshd
> ● sshd.service - OpenSSH server daemon
> Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
> Docs: man:sshd(8)
> man:sshd_config(5)
> Main PID: 974 (sshd)
> CGroup: /system.slice/sshd.service
> └─974 /usr/sbin/sshd -D
>
> One more reason the reboot is the simpler instruction that always works
> for a noob. :)
>

For a noob wouldn't it just be easier to just bite the bullet, generate
new, more secure keys? Rather than debate how they should thwart the
will of OpenSSL and the complicit distro makers. :-)

But then perhaps a noob wouldn't have keys generated in 2014, although a
quick google suggests ssh-keygen only changed the default of RSA-SHA
from SHA1 to SHA2 in release OpenSSH 8.1/8.1p1 (2019-10-09), with the
warning introduced OpenSSH 7.7/7.7p1 (2018-04-02).

Anyway, thanks everyone for correcting me. I just hoped to save people
the trouble of doing the standard SSH key checks, before discovering the
software change.

Pancho <Pancho.Jones@proton.me> writes:
> But then perhaps a noob wouldn't have keys generated in 2014, although
> a quick google suggests ssh-keygen only changed the default of RSA-SHA
> from SHA1 to SHA2 in release OpenSSH 8.1/8.1p1 (2019-10-09), with the
> warning introduced OpenSSH 7.7/7.7p1 (2018-04-02).

Existing RSA keys will work fine with SHA-2 signatures. Nobody needs to
generate new keys (unless they want to migrate away from RSA
entirely).

--
https://www.greenend.org.uk/rjk/

On 20/07/2022 08:36, Richard Kettlewell wrote:
> Pancho <Pancho.Jones@proton.me> writes:
>> But then perhaps a noob wouldn't have keys generated in 2014, although
>> a quick google suggests ssh-keygen only changed the default of RSA-SHA
>> from SHA1 to SHA2 in release OpenSSH 8.1/8.1p1 (2019-10-09), with the
>> warning introduced OpenSSH 7.7/7.7p1 (2018-04-02).
>
> Existing RSA keys will work fine with SHA-2 signatures. Nobody needs to
> generate new keys (unless they want to migrate away from RSA
> entirely).
>

OK, I think I finally get it! SHA-1 isn't part of the SSH-RSA key.

Whilst changing the key worked, I could also have fixed the problem by
upgrading my SSH client. A new SSH client would then negotiate SHA-2 in
the SSH connection handshake (or whatever it is called).

Sorry, I was somewhat mislead by:

<https://askubuntu.com/questions/1409105/ubuntu-22-04-ssh-the-rsa-key-isnt-working-since-upgrading-from-20-04>

But on second reading, I see the comment at the bottom by pimpo points
this out :-(.

On 20/07/2022 08:36, Richard Kettlewell wrote:
> Pancho <Pancho.Jones@proton.me> writes:
>> But then perhaps a noob wouldn't have keys generated in 2014, although
>> a quick google suggests ssh-keygen only changed the default of RSA-SHA
>> from SHA1 to SHA2 in release OpenSSH 8.1/8.1p1 (2019-10-09), with the
>> warning introduced OpenSSH 7.7/7.7p1 (2018-04-02).
>
> Existing RSA keys will work fine with SHA-2 signatures. Nobody needs to
> generate new keys (unless they want to migrate away from RSA
> entirely).

Thanks for clarifying that Richard.

---druck

On 20/07/2022 21:06, druck wrote:
> On 20/07/2022 08:36, Richard Kettlewell wrote:
>> Pancho <Pancho.Jones@proton.me> writes:
>>> But then perhaps a noob wouldn't have keys generated in 2014, although
>>> a quick google suggests ssh-keygen only changed the default of RSA-SHA
>>> from SHA1 to SHA2 in release OpenSSH 8.1/8.1p1 (2019-10-09), with the
>>> warning introduced OpenSSH 7.7/7.7p1 (2018-04-02).
>>
>> Existing RSA keys will work fine with SHA-2 signatures. Nobody needs to
>> generate new keys (unless they want to migrate away from RSA
>> entirely).
>
> Thanks for clarifying that Richard.
>
> ---druck
>

To be clear... I think it was a correction, rather than a clarification.
I certainly hadn't understood the issue or that SHA-1 and SHA-2 are just
hash functions, like MD5. Functions whose domain is just the data being
hashed. There are even shell commands sha1sum and sha256sum, like the
old md5sum.

On balance, I think I prefer ED25519 to RSA for SSH. Both public and
private keys are smaller and hence easier to use.

Reading a few articles on the issue, it seems some of the people who
write articles on encryption also have some surprising misunderstandings.