From Newsgroup: alt.os.linux

As per subject, I have a number of Windows 7 PCs which are running an
old-ish 32-bit version of ssh via CygWin and PuTTy. Several of these
machines dual-boot between Windows and Ubuntu22. I also have a number
of servers and network media players, 4 pretty old, 2 much newer.

The machines running under Windows can log into the old servers via the old-ish 32-bit ssh and Cygwin using a public key file, no password is required, but to log into the newer servers, I have to use PuTTy.

However, when booted into Ubuntu 22 none of the machines, even though
they're using the *SAME* key files, can login in using just these public
keys, a password is requested for both old and new servers. I never had
this problem with Ubuntu 18.

I've checked all the usual suspects:

+ The id_rsa* copied into ~/.ssh are identical to those used by the Windows builds.

+ The ~/.ssh directory (700) and the files within it (600) all have
the correct ownership and permissions.

Suitably anonymised, trying to force using a key file with the following command ...

ssh -i /user/.ssh/id_rsa.pub -v -E ssh.log -o 'PubkeyAuthentication yes'
-o 'PasswordAuthentication no' user@server

... results in the output appended. Can anyone help explain what is
going wrong and help fix the problem? My first suspicion is that a
newer version of ssh in the Ubuntu 22 builds is not accepting the older
keys accepted by Ubuntu 18, so, if this is true, I need to know what configuration changes to make in /etc/ssh_config to get backward compatibility. Nothing leaps out at me from reading the online manual
and so far searches have produced the usual advice about how to set up
public key use, and the standard advice to try when it goes wrong, all
of which I've done. I've not yet found anything covering this exact situation.

Debug output:

debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include
/etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to server [IP Address] port 22.
debug1: Connection established.
debug1: identity file /user/.ssh/id_rsa.pub type 0
debug1: identity file /user/.ssh/id_rsa.pub-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.10
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9 debug1: compat_banner: match: OpenSSH_5.9 pat OpenSSH_5* compat 0x0c000002 debug1: Authenticating to server:22 as 'user'
debug1: load_hostkeys: fopen /user/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: ecdh-sha2-nistp256
debug1: kex: host key algorithm: ecdsa-sha2-nistp521
debug1: kex: server->client cipher: aes128-ctr MAC: umac-64@openssh.com compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: umac-64@openssh.com compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: <anonymised> SHA256:<anonymised>
debug1: load_hostkeys: fopen /user/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host 'server' is known and matches the ECDSA host key.
debug1: Found key in /user/.ssh/known_hosts:7
debug1: rekey out after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 4294967296 blocks
debug1: get_agent_identities: bound agent to hostkey
debug1: get_agent_identities: ssh_fetch_identitylist: agent contains no identities
debug1: Will attempt key: /user/.ssh/id_rsa.pub RSA SHA256:<an unknown
key, not the one in id_rsa or id_rsa.pub> explicit
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /user/.ssh/id_rsa.pub RSA SHA256:<same
unknown key, not the one in id_rsa or id_rsa.pub> explicit
debug1: send_pubkey_test: no mutual signature algorithm
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: No more authentication methods to try.
user@server: Permission denied (publickey,password,keyboard-interactive).



However, the same key file
--

Fake news kills!

I may be contacted via the contact address given on my website: www.macfh.co.uk
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: alt.os.linux

Java Jive <java@evij.com.invalid> wrote:

... results in the output appended. Can anyone help explain what is
going wrong and help fix the problem? My first suspicion is that a
newer version of ssh in the Ubuntu 22 builds is not accepting the older
keys accepted by Ubuntu 18, so, if this is true, I need to know what configuration changes to make in /etc/ssh_config to get backward compatibility. Nothing leaps out at me from reading the online manual
and so far searches have produced the usual advice about how to set up public key use, and the standard advice to try when it goes wrong, all
of which I've done. I've not yet found anything covering this exact situation.

If it is a mismatch in what key types are accepted you'll need
something like this (this is a section from my ~/.ssh/config):-

#
#
# D-Link NAS, not in use at the moment but the configuration for an old ssh
# version is good to know
#
Host dlink dlink-5CA453
HostName dlink-5CA453.zbmc.eu
HostKeyAlgorithms=+ssh-dss
--
Chris Green
·
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: alt.os.linux

Java Jive <java@evij.com.invalid> writes:

As per subject, I have a number of Windows 7 PCs which are running an
old-ish 32-bit version of ssh via CygWin and PuTTy. Several of these machines dual-boot between Windows and Ubuntu22. I also have a number
of servers and network media players, 4 pretty old, 2 much newer.

The machines running under Windows can log into the old servers via
the old-ish 32-bit ssh and Cygwin using a public key file, no password
is required, but to log into the newer servers, I have to use PuTTy.

However, when booted into Ubuntu 22 none of the machines, even though
they're using the *SAME* key files, can login in using just these
public keys, a password is requested for both old and new servers. I
never had this problem with Ubuntu 18.

I've checked all the usual suspects:

+ The id_rsa* copied into ~/.ssh are identical to those used by the
Windows builds.

What size is the key? To find out:
ssh-keygen -l -f .ssh/id_rsa.pub

... results in the output appended. Can anyone help explain what is
going wrong and help fix the problem? My first suspicion is that a
newer version of ssh in the Ubuntu 22 builds is not accepting the
older keys accepted by Ubuntu 18, so, if this is true,

That is quite likely.

Debug output:

debug1: Will attempt key: /user/.ssh/id_rsa.pub RSA SHA256:<an unknown
key, not the one in id_rsa or id_rsa.pub> explicit

How are you determining that it’s not the same key? My guess is that
you’ve tried to compare the SHA256 hash to the public key material. You
need to compare hashes with hashes, or public keys with public keys.

debug1: Offering public key: /user/.ssh/id_rsa.pub RSA SHA256:<same
unknown key, not the one in id_rsa or id_rsa.pub> explicit
debug1: send_pubkey_test: no mutual signature algorithm

The server did not accept your key.

However, the same key file

Your message seems to be truncated.


There’s not enough information here to be sure (server debug output
might help) but my guess is that you’re trying to use an RSA-1024 key
with a modern SSH server, which rejects it as too weak. If you are still
using RSA-1024 then it’s time for new keys.
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: alt.os.linux

On 24-08-2024 01:18, Java Jive wrote:

As per subject, I have a number of Windows 7 PCs which are running an
old-ish 32-bit version of ssh via CygWin and PuTTy.  Several of these machines dual-boot between Windows and Ubuntu22.  I also have a number
of servers and network media players, 4 pretty old, 2 much newer.

The machines running under Windows can log into the old servers via the> old-ish 32-bit ssh and Cygwin using a public key file, no password is
required, but to log into the newer servers, I have to use PuTTy.

However, when booted into Ubuntu 22 none of the machines, even though
they're using the *SAME* key files, can login in using just these public keys, a password is requested for both old and new servers.  I never had this problem with Ubuntu 18.

<snip complicated stuff>
I'm not sure if manually copying key files is even supposed to work.
I normally use ssh-copy-id: run "ssh-copy-id server" on the client.
You'll be prompted for your password once and that's it.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: alt.os.linux

On 24/08/2024 08:42, Chris Green wrote:

Java Jive <java@evij.com.invalid> wrote:

... results in the output appended. Can anyone help explain what is
going wrong and help fix the problem? My first suspicion is that a
newer version of ssh in the Ubuntu 22 builds is not accepting the older
keys accepted by Ubuntu 18, so, if this is true, I need to know what
configuration changes to make in /etc/ssh_config to get backward
compatibility. Nothing leaps out at me from reading the online manual
and so far searches have produced the usual advice about how to set up
public key use, and the standard advice to try when it goes wrong, all
of which I've done. I've not yet found anything covering this exact
situation.

If it is a mismatch in what key types are accepted you'll need
something like this (this is a section from my ~/.ssh/config):-

#
#
# D-Link NAS, not in use at the moment but the configuration for an old ssh
# version is good to know
#
Host dlink dlink-5CA453
HostName dlink-5CA453.zbmc.eu
HostKeyAlgorithms=+ssh-dss

Thanks, but doesn't seem to work, even after a reboot. I tried
inserting the following (anonymised) into ssh_config (see longer and
more detailed reply to Richard Kettlewell which I will write immediately
after this):

Include /etc/ssh/ssh_config.d/*.conf

Host anon1* anon2*
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
HostKeyAlgorithms=+ssh-dss

Host *
(etc ...)
--

Fake news kills!

I may be contacted via the contact address given on my website: www.macfh.co.uk

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: alt.os.linux

Java Jive wrote:

I have to use PuTTy.

You say that as though it's a bad thing?

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: alt.os.linux

On 24/08/2024 09:51, Richard Kettlewell wrote:

Java Jive <java@evij.com.invalid> writes:

As per subject, I have a number of Windows 7 PCs which are running an
old-ish 32-bit version of ssh via CygWin and PuTTy. Several of these
machines dual-boot between Windows and Ubuntu22. I also have a number
of servers and network media players, 4 pretty old, 2 much newer.

The machines running under Windows can log into the old servers via
the old-ish 32-bit ssh and Cygwin using a public key file, no password
is required, but to log into the newer servers, I have to use PuTTy.

However, when booted into Ubuntu 22 none of the machines, even though
they're using the *SAME* key files, can login in using just these
public keys, a password is requested for both old and new servers. I
never had this problem with Ubuntu 18.

I've checked all the usual suspects:

+ The id_rsa* copied into ~/.ssh are identical to those used by the
Windows builds.

What size is the key? To find out:
ssh-keygen -l -f .ssh/id_rsa.pub

2048, see log appended.

debug1: Will attempt key: /user/.ssh/id_rsa.pub RSA SHA256:<an unknown
key, not the one in id_rsa or id_rsa.pub> explicit

How are you determining that it’s not the same key?

Mark 1 eyeball, but in fact it seems to be the correct *.pub key hashed,
see log appended.

debug1: Offering public key: /user/.ssh/id_rsa.pub RSA SHA256:<same
unknown key, not the one in id_rsa or id_rsa.pub> explicit
debug1: send_pubkey_test: no mutual signature algorithm

The server did not accept your key.

Really odd, seeing it accepts exactly the same key from Windows 7 and
formerly Ubuntu 18.

However, the same key file

Your message seems to be truncated.

No, that was spurious. I think that was how I began to write one of the
paras above, but went back up to correct something, and instead of
returning to that point to continue the para, rewrote it differently
from scratch, forgetting that there was still the fragmentary beginning dangling below; then, after inserting the message log, I couldn't even
see that it was there. Sorry for any confusion caused.

There’s not enough information here to be sure (server debug output
might help) but my guess is that you’re trying to use an RSA-1024 key
with a modern SSH server, which rejects it as too weak. If you are still using RSA-1024 then it’s time for new keys.

From what is appended below it seems to be a 2048 key. Here's a full
log, anonymised, of the latest interactions as seen from the client
side, after adapting ssh_config as suggested by Chris Green - first
the modified config file ('server' matches 'anon1*'), second the attempt
to log on, third the ssh_keygen command you suggested. Next I'll try to
find out what it looks like from the server side:

cat /etc/ssh/ssh_config

# This is the ssh client system-wide configuration file. See
# ssh_config(5) for more information. This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
# 1. command line options
# 2. user-specific file
# 3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for some commonly used options. For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

Include /etc/ssh/ssh_config.d/*.conf

Host anon1* anon2*
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
HostKeyAlgorithms=+ssh-dss

Host *
# ForwardAgent no
# ForwardX11 no
# ForwardX11Trusted yes
# PasswordAuthentication yes
# HostbasedAuthentication no
# GSSAPIAuthentication no
# GSSAPIDelegateCredentials no
# GSSAPIKeyExchange no
# GSSAPITrustDNS no
# BatchMode no
# CheckHostIP yes
# AddressFamily any
# ConnectTimeout 0
# StrictHostKeyChecking ask
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
# IdentityFile ~/.ssh/id_ecdsa
# IdentityFile ~/.ssh/id_ed25519
# Port 22
# Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
# MACs hmac-md5,hmac-sha1,umac-64@openssh.com
# EscapeChar ~
# Tunnel no
# TunnelDevice any:any
# PermitLocalCommand no
# VisualHostKey no
# ProxyCommand ssh -q -W %h:%p gateway.example.com
# RekeyLimit 1G 1h
# UserKnownHostsFile ~/.ssh/known_hosts.d/%k
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes


ssh -v -E ssh.log user@server -o 'PasswordAuthentication no'

OpenSSH_8.9p1 Ubuntu-3ubuntu0.10, OpenSSL 3.0.2 15 Mar 2022
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include
/etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for NAS*
debug1: /etc/ssh/ssh_config line 27: Applying options for *
debug1: Connecting to server [IP4_ADDRESS] port 22.
debug1: Connection established.
debug1: identity file /user/.ssh/id_rsa type 0
debug1: identity file /user/.ssh/id_rsa-cert type -1
debug1: identity file /user/.ssh/id_ecdsa type -1
debug1: identity file /user/.ssh/id_ecdsa-cert type -1
debug1: identity file /user/.ssh/id_ecdsa_sk type -1
debug1: identity file /user/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /user/.ssh/id_ed25519 type -1
debug1: identity file /user/.ssh/id_ed25519-cert type -1
debug1: identity file /user/.ssh/id_ed25519_sk type -1
debug1: identity file /user/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /user/.ssh/id_xmss type -1
debug1: identity file /user/.ssh/id_xmss-cert type -1
debug1: identity file /user/.ssh/id_dsa type -1
debug1: identity file /user/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.10
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9 debug1: compat_banner: match: OpenSSH_5.9 pat OpenSSH_5* compat 0x0c000002 debug1: Authenticating to server:22 as 'user'
debug1: load_hostkeys: fopen /user/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: ecdh-sha2-nistp256
debug1: kex: host key algorithm: ecdsa-sha2-nistp521
debug1: kex: server->client cipher: aes128-ctr MAC: umac-64@openssh.com compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: umac-64@openssh.com compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ecdsa-sha2-nistp521 SHA256:jZvJMiYgYYHYydBZ7bpITJExGXPOIx7NEpjmO7lQKHU
debug1: load_hostkeys: fopen /user/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host 'server' is known and matches the ECDSA host key.
debug1: Found key in /user/.ssh/known_hosts:7
debug1: rekey out after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 4294967296 blocks
debug1: get_agent_identities: bound agent to hostkey
debug1: get_agent_identities: ssh_fetch_identitylist: agent contains no identities
debug1: Will attempt key: /user/.ssh/id_rsa RSA SHA256:HASHED
debug1: Will attempt key: /user/.ssh/id_ecdsa
debug1: Will attempt key: /user/.ssh/id_ecdsa_sk
debug1: Will attempt key: /user/.ssh/id_ed25519
debug1: Will attempt key: /user/.ssh/id_ed25519_sk
debug1: Will attempt key: /user/.ssh/id_xmss
debug1: Will attempt key: /user/.ssh/id_dsa
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /user/.ssh/id_rsa RSA SHA256:HASHED
debug1: send_pubkey_test: no mutual signature algorithm
debug1: Trying private key: /user/.ssh/id_ecdsa
debug1: Trying private key: /user/.ssh/id_ecdsa_sk
debug1: Trying private key: /user/.ssh/id_ed25519
debug1: Trying private key: /user/.ssh/id_ed25519_sk
debug1: Trying private key: /user/.ssh/id_xmss
debug1: Trying private key: /user/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: No more authentication methods to try.
user@server: Permission denied (publickey,password,keyboard-interactive).


ssh-keygen -l -f .ssh/id_rsa.pub
2048 SHA256:HASHED user@pc (RSA)
--

Fake news kills!

I may be contacted via the contact address given on my website: www.macfh.co.uk

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: alt.os.linux

Java Jive <java@evij.com.invalid> writes:

On 24/08/2024 09:51, Richard Kettlewell wrote:

Java Jive <java@evij.com.invalid> writes:

As per subject, I have a number of Windows 7 PCs which are running an
old-ish 32-bit version of ssh via CygWin and PuTTy. Several of these

^^^^^^^

What version exactly?

debug1: Offering public key: /user/.ssh/id_rsa.pub RSA SHA256:<same
unknown key, not the one in id_rsa or id_rsa.pub> explicit
debug1: send_pubkey_test: no mutual signature algorithm

The server did not accept your key.

Really odd, seeing it accepts exactly the same key from Windows 7 and formerly Ubuntu 18.

If the client is attempted SHA1-based signature that would probably also
be rejected by a modern server. I’m not convinced that’s a likely explanation since based on the debug trace it is using SHA256 key hashes
and understands SHA2 ECDSA signatures.

At this point I’d be reaching for server-side debug logging to shed some light on why the server doesn’t like your key (or at least the signature
it makes).
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: alt.os.linux

On 2024-08-24 at 01:18 Java Jive wrote:

debug1: Will attempt key: /user/.ssh/id_rsa.pub RSA SHA256:<an unknown key, not the one in id_rsa or id_rsa.pub> explicit
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /user/.ssh/id_rsa.pub RSA SHA256:<same unknown key, not the one in id_rsa or id_rsa.pub> explicit
debug1: send_pubkey_test: no mutual signature algorithm
[…]

Try running your ssh client on Ubuntu 22 with this option:

PubkeyAcceptedKeyTypes +ssh-rsa


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: alt.os.linux

On 24/08/2024 15:29, Richard Kettlewell wrote:

Java Jive <java@evij.com.invalid> writes:

On 24/08/2024 09:51, Richard Kettlewell wrote:

Java Jive <java@evij.com.invalid> writes:

As per subject, I have a number of Windows 7 PCs which are running an
old-ish 32-bit version of ssh via CygWin and PuTTy. Several of these

^^^^^^^

What version exactly?

ssh -v

OpenSSH_5.1p1, OpenSSL 0.9.8i 15 Sep 2008
usage: ssh [-1246AaCfgKkMNnqsTtVvXxY] [-b bind_address] [-c cipher_spec]
[-D [bind_address:]port] [-e escape_char] [-F configfile]
[-i identity_file] [-L [bind_address:]port:host:hostport]
[-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
[-R [bind_address:]port:host:hostport] [-S ctl_path]
[-w local_tun[:remote_tun]] [user@]hostname [command]

debug1: Offering public key: /user/.ssh/id_rsa.pub RSA SHA256:<same
unknown key, not the one in id_rsa or id_rsa.pub> explicit
debug1: send_pubkey_test: no mutual signature algorithm

The server did not accept your key.

Really odd, seeing it accepts exactly the same key from Windows 7 and
formerly Ubuntu 18.

If the client is attempted SHA1-based signature that would probably also
be rejected by a modern server. I’m not convinced that’s a likely explanation since based on the debug trace it is using SHA256 key hashes
and understands SHA2 ECDSA signatures.

At this point I’d be reaching for server-side debug logging to shed some light on why the server doesn’t like your key (or at least the signature
it makes).

This is what the failure looks like from the server with maximum
debugging options:

~ # /opt/sbin/sshd -D -d -d -d
debug2: load_server_config: filename /opt/etc/openssh/sshd_config
debug2: load_server_config: done config len = 200
debug2: parse_server_config: config /opt/etc/openssh/sshd_config len 200 debug3: /opt/etc/openssh/sshd_config:50 setting AuthorizedKeysFile .ssh/authorized_keys
debug3: /opt/etc/openssh/sshd_config:115 setting Subsystem sftp /opt/libexec/sftp-server
debug3: RNG is ready, skipping seeding
debug1: sshd version OpenSSH_5.9p1
debug3: Incorrect RSA1 identifier
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug3: Incorrect RSA1 identifier
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug3: Incorrect RSA1 identifier
debug1: read PEM private key done: type ECDSA
debug1: private host key: #2 type 3 ECDSA
debug1: rexec_argv[0]='/opt/sbin/sshd'
debug1: rexec_argv[1]='-D'
debug1: rexec_argv[2]='-d'
debug1: rexec_argv[3]='-d'
debug1: rexec_argv[4]='-d'
debug3: oom_adjust_setup
Set /proc/self/oom_adj from 0 to -17
debug2: fd 3 setting O_NONBLOCK
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
socket: Address family not supported by protocol
debug3: fd 4 is not O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug3: send_rexec_state: entering fd = 7 config len 200
debug3: ssh_msg_send: type 0
debug3: send_rexec_state: done
debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7
debug1: inetd sockets after dupping: 3, 3
Connection from [IP_Address] port 40078
debug1: Client protocol version 2.0; client software version
OpenSSH_8.9p1 Ubuntu-3ubuntu0.10
debug1: match: OpenSSH_8.9p1 Ubuntu-3ubuntu0.10 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug2: fd 3 setting O_NONBLOCK
debug2: Network child is on pid 5749
debug3: preauth child monitor started
debug3: privsep user:group 99:99 [preauth]
debug1: permanently_set_uid: 99/99 [preauth]
debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp521 [preauth] debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
[preauth]
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp521 [preauth] debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
[preauth]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
[preauth]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
[preauth]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
[preauth]
debug2: kex_parse_kexinit: none,zlib@openssh.com [preauth]
debug2: kex_parse_kexinit: none,zlib@openssh.com [preauth]
debug2: kex_parse_kexinit: [preauth]
debug2: kex_parse_kexinit: [preauth]
debug2: kex_parse_kexinit: first_kex_follows 0 [preauth]
debug2: kex_parse_kexinit: reserved 0 [preauth]
debug2: kex_parse_kexinit: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,sntrup761x25519-sha512@openssh.com,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c,kex-strict-c-v00@openssh.com
[preauth]
debug2: kex_parse_kexinit: ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,rsa-sha2-512,rsa-sha2-256
[preauth]
debug2: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
[preauth]
debug2: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
[preauth]
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
[preauth]
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
[preauth]
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib [preauth]
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib [preauth]
debug2: kex_parse_kexinit: [preauth]
debug2: kex_parse_kexinit: [preauth]
debug2: kex_parse_kexinit: first_kex_follows 0 [preauth]
debug2: kex_parse_kexinit: reserved 0 [preauth]
debug2: mac_setup: found umac-64@openssh.com [preauth]
debug1: kex: client->server aes128-ctr umac-64@openssh.com none [preauth] debug2: mac_setup: found umac-64@openssh.com [preauth]
debug1: kex: server->client aes128-ctr umac-64@openssh.com none [preauth] debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
debug3: mm_key_sign entering [preauth]
debug3: mm_request_send entering: type 4 [preauth]
debug3: mm_request_receive entering
debug3: monitor_read: checking request 4
debug3: mm_answer_sign
debug3: mm_answer_sign: signature 0x81a00(166)
debug3: mm_request_send entering: type 5
debug2: monitor_read: 4 used once, disabling now
debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN [preauth]
debug3: mm_request_receive_expect entering: type 5 [preauth]
debug3: mm_request_receive entering [preauth]
debug2: kex_derive_keys [preauth]
debug2: set_newkeys: mode 1 [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug2: set_newkeys: mode 0 [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user root service ssh-connection method
none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug3: mm_getpwnamallow entering [preauth]
debug3: mm_request_send entering: type 6 [preauth]
debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM [preauth]
debug3: mm_request_receive_expect entering: type 7 [preauth]
debug3: mm_request_receive entering [preauth]
debug3: mm_request_receive entering
debug3: monitor_read: checking request 6
debug3: mm_answer_pwnamallow
debug3: Trying to reverse map address [IP_Address].
debug2: parse_server_config: config reprocess config len 200
debug3: auth_shadow_acctexpired: today 19960 sp_expire -1 days left -19961 debug3: account expiration disabled
debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1
debug3: mm_request_send entering: type 7
debug2: monitor_read: 6 used once, disabling now
debug2: input_userauth_request: setting up authctxt for root [preauth]
debug3: mm_inform_authserv entering [preauth]
debug3: mm_request_send entering: type 3 [preauth]
debug2: input_userauth_request: try method none [preauth]
debug1: userauth-request for user root service ssh-connection method keyboard-interactive [preauth]
debug1: attempt 1 failures 0 [preauth]
debug2: input_userauth_request: try method keyboard-interactive [preauth] debug1: keyboard-interactive devs [preauth]
debug1: auth2_challenge: user=root devs= [preauth]
debug1: kbdint_alloc: devices '' [preauth]
debug2: auth2_challenge_start: devices [preauth]
Connection closed by [IP_Address] [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed
debug3: mm_request_receive entering
debug3: monitor_read: checking request 3
debug3: mm_answer_authserv: service=ssh-connection, style=
debug2: monitor_read: 3 used once, disabling now
debug3: mm_request_receive entering
debug1: do_cleanup
--

Fake news kills!

I may be contacted via the contact address given on my website: www.macfh.co.uk

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: alt.os.linux

Java Jive <java@evij.com.invalid> writes:

This is what the failure looks like from the server with maximum
debugging options:

[...]

Server is OpenSSH 5.9p1:

debug1: sshd version OpenSSH_5.9p1
debug3: Incorrect RSA1 identifier

Server has (among others) an ECDSA host key.

Client is OpenSSH 8.9p1:

debug1: Client protocol version 2.0; client software version OpenSSH_8.9p1 Ubuntu-3ubuntu0.10

Server’s supported host key mechanisms:

debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp521 [preauth]

Client’s supported host key mechanisms:

debug2: kex_parse_kexinit: ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,rsa-sha2-512,rsa-sha2-256

ecdsa-sha2-nistp521 appears in both and the server has an ECDSA host
key, so host key verification is possible.

The public key authentication mechanism aren’t logged but there is no
shared RSA mechanism - the server only has ssh-rsa (i.e. RSA with SHA-1)
while the client only has rsa-sha2-512 and rsa-sha2-256 (i.e. RSA with
SHA-512 or SHA-256).

Looking at the OpenSSH release notes:

* ssh-rsa was disabled in OpenSSH 8.7 because it’s broken;
your OpenSSH 8.9p1 client therefore has it disabled by default.
* rsa-sha2-256 and rsa-sha2-512 were added in OpenSSH 7.2;
your OpenSSH 5.9p1 client therefore cannot use them.

So my guess was basically right, although I’d got client and server the
wrong way round.

I think your options are:
* Upgrade the server to something from this decade; it should start
using one of the SHA2 mechanisms with your existing RSA keys.
* Create an ECDSA key on the client(s) and use that to authenticate to
the server.
* Re-enable ssh-rsa in the OpenSSH 8.9p1 client, if you don’t care about
security.
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: alt.os.linux

On 26/08/2024 08:47, Richard Kettlewell wrote:

Java Jive <java@evij.com.invalid> writes:

This is what the failure looks like from the server with maximum
debugging options:

[...]

Server is OpenSSH 5.9p1:

debug1: sshd version OpenSSH_5.9p1
debug3: Incorrect RSA1 identifier

Server has (among others) an ECDSA host key.

Client is OpenSSH 8.9p1:

debug1: Client protocol version 2.0; client software version OpenSSH_8.9p1 Ubuntu-3ubuntu0.10

Server’s supported host key mechanisms:

debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp521 [preauth]

Client’s supported host key mechanisms:

debug2: kex_parse_kexinit:
ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,rsa-sha2-512,rsa-sha2-256

ecdsa-sha2-nistp521 appears in both and the server has an ECDSA host
key, so host key verification is possible.

The public key authentication mechanism aren’t logged but there is no shared RSA mechanism - the server only has ssh-rsa (i.e. RSA with SHA-1) while the client only has rsa-sha2-512 and rsa-sha2-256 (i.e. RSA with SHA-512 or SHA-256).

Looking at the OpenSSH release notes:

* ssh-rsa was disabled in OpenSSH 8.7 because it’s broken;
your OpenSSH 8.9p1 client therefore has it disabled by default.
* rsa-sha2-256 and rsa-sha2-512 were added in OpenSSH 7.2;
your OpenSSH 5.9p1 client therefore cannot use them.

So my guess was basically right, although I’d got client and server the wrong way round.

I think your options are:

* Upgrade the server to something from this decade; it should start
using one of the SHA2 mechanisms with your existing RSA keys.

Not possible without considerable work, more than those 2 boxes are
worth (actually possibly 4, of 2 different models; after the failure
with these 2, I didn't bother to test the 2 NMPs)

* Create an ECDSA key on the client(s) and use that to authenticate to
the server.

I'll investigate that.

* Re-enable ssh-rsa in the OpenSSH 8.9p1 client, if you don’t care about
security.

I'll investigate that too.

I do care about security, hence my using ssh in the first place, but
only so far, because this is a private LAN at my home and the chances of strangers getting to be in a position to try to hack it are quite low in
the first place.

Thanks for your comprehensive analysis. I did try examining the debug
log for myself, but I couldn't find a way in to understanding what was happening, so your help has been invaluable. Tx again.
--

Fake news kills!

I may be contacted via the contact address given on my website: www.macfh.co.uk

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: alt.os.linux

On 26/08/2024 12:20, Java Jive wrote:

* Create an ECDSA key on the client(s) and use that to authenticate to
   the server.

I'll investigate that.

Solved, I can log into all the servers with an ECDSA key.

Many thanks for your help.
--

Fake news kills!

I may be contacted via the contact address given on my website: www.macfh.co.uk

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: alt.os.linux

On 2024-08-23, Java Jive <java@evij.com.invalid> wrote:

The machines running under Windows can log into the old servers via the old-ish 32-bit ssh and Cygwin using a public key file, no password is required, but to log into the newer servers, I have to use PuTTy.

However, when booted into Ubuntu 22 none of the machines, even though they're using the *SAME* key files, can login in using just these public keys, a password is requested for both old and new servers. I never had this problem with Ubuntu 18.

try adding this to your ssh command:
-o PubkeyAcceptedAlgorithms=+ssh-rsa

I encountewred s similar problem a few months back and that was the
work-around
--
Jasen.
🇺🇦 Слава Україні
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: alt.os.linux

Jasen Betts <usenet@revmaps.no-ip.org> writes:

On 2024-08-23, Java Jive <java@evij.com.invalid> wrote:

The machines running under Windows can log into the old servers via the
old-ish 32-bit ssh and Cygwin using a public key file, no password is
required, but to log into the newer servers, I have to use PuTTy.

However, when booted into Ubuntu 22 none of the machines, even though
they're using the *SAME* key files, can login in using just these public
keys, a password is requested for both old and new servers. I never had
this problem with Ubuntu 18.

try adding this to your ssh command:
-o PubkeyAcceptedAlgorithms=+ssh-rsa

I encountewred s similar problem a few months back and that was the work-around

No, don’t do that. ssh-rsa is disabled because it is broken. In this
case a much more sensible workaround is possible (and the OP has used
it).
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.20a-Linux NewsLink 1.114