• SSH no longer works with RSA keys.

    From Pancho@3:770/3 to All on Fri Jul 15 02:22:07 2022
    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)
  • From Grant Taylor@3:770/3 to Pancho on Thu Jul 14 20:12:48 2022
    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)
  • From A. Dumas@3:770/3 to Grant Taylor on Fri Jul 15 04:44:14 2022
    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)
  • From Grant Taylor@3:770/3 to A. Dumas on Thu Jul 14 23:12:28 2022
    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)
  • From A. Dumas@3:770/3 to Grant Taylor on Fri Jul 15 10:25:25 2022
    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)
  • From Grant Taylor@3:770/3 to A. Dumas on Fri Jul 15 11:04:34 2022
    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)
  • From Theo@3:770/3 to A. Dumas on Sat Jul 16 16:55:52 2022
    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)
  • From Richard Kettlewell@3:770/3 to A. Dumas on Mon Jul 18 09:54:51 2022
    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)
  • From A. Dumas@3:770/3 to Theo on Mon Jul 18 15:22:19 2022
    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)
  • From Tauno Voipio@3:770/3 to Richard Kettlewell on Mon Jul 18 20:02:34 2022
    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)
  • From Joe Beanfish@3:770/3 to Theo on Mon Jul 18 17:22:27 2022
    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)
  • From A. Dumas@3:770/3 to Joe Beanfish on Mon Jul 18 17:49:38 2022
    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)
  • From Pancho@3:770/3 to Joe Beanfish on Tue Jul 19 15:53:00 2022
    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)
  • From Joe Beanfish@3:770/3 to A. Dumas on Tue Jul 19 14:27:30 2022
    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)
  • From Richard Kettlewell@3:770/3 to Pancho on Wed Jul 20 08:36:36 2022
    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)
  • From Pancho@3:770/3 to Richard Kettlewell on Wed Jul 20 13:27:59 2022
    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)
  • From druck@3:770/3 to Richard Kettlewell on Wed Jul 20 21:06:49 2022
    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)
  • From Pancho@3:770/3 to druck on Thu Jul 21 19:56:55 2022
    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)
  • From =?UTF-8?B?4LiZ4LmJ4Lit4LiH4LmD4Lir4@3:770/3 to All on Mon Oct 9 06:48:07 2023
    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)