XPost: uk.comp.os.linux   
   From: java@evij.com.invalid   
      
   On 24/08/2024 09:51, Richard Kettlewell wrote:   
   >   
   > Java Jive 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:> 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:> 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   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   
|