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.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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 ¯\_(ツ)_/¯

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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/

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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. :)

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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/

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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 :-(.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

U1NIIG5vIGxvbmdlciB3b3JrcyB3aXRoIFJTQSBrZXlzLg0K4pyFIOC5gOC4guC5ieC4suC5gOC4 p+C5h+C4muC5hOC4i+C4leC5jA0KaHR0cHM6Ly9iaXQubHkvc2Nyc2I/NzhudGU9ZnJlZQ0KDQri nIUg4Liq4Lih4Lix4LiE4Lij4Liq4Lih4Liy4LiK4Li04LiBDQpodHRwczovL2JpdC5seS9zY3Jy Yj83OG50ZT1mcmVlDQoNCuKchSDguJXguLTguJTguJXguYjguK3guYDguKPguLINCmh0dHBzOi8v Yml0Lmx5L3NjcmxiPzc4bnRlPWZyZWUNCg0K4pyFIOC4o+C4seC4muC5guC4m+C4o+C5guC4oeC4 iuC4seC5iOC4mQ0KaHR0cHM6Ly9iaXQubHkvc2NycGI/NzhudGU9ZnJlZQ0KDQoNCg==

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)