Putty. Chiave SSH giusta, ma accesso rifiutato da Putty

[Tiger99]

Ho generato una chiave con PuttyGen.
Ho salvato authorized_file sul server (Debian 10.4)
Ho anche salvato la chiave privata .ppk sul PC
Se mi collego da linux con ssh, accedo senza problemi.
Se invece accedo da putty usando la chiave privata continua a darmi errore "Server refused our key" e questo sia usando putty su Linux che Win10.
Non capisco perché.
La chiave sul server è corretta con i giusti diritti, altrimenti non mi collegherei neppure da SSH.
D'altra parte la chiave privata me la salva PuttyGen; io devo solo cliccare su "salva" e dargli un nome.
Dove sbaglio?

[Tasslehoff]

Originariamente inviato da Tiger99

Ho generato una chiave con PuttyGen.
Ho salvato authorized_file sul server (Debian 10.4)
Ho anche salvato la chiave privata .ppk sul PC
Se mi collego da linux con ssh, accedo senza problemi.
Se invece accedo da putty usando la chiave privata continua a darmi errore "Server refused our key" e questo sia usando putty su Linux che Win10.
Non capisco perché.
La chiave sul server è corretta con i giusti diritti, altrimenti non mi collegherei neppure da SSH.
D'altra parte la chiave privata me la salva PuttyGen; io devo solo cliccare su "salva" e dargli un nome.
Dove sbaglio?

Per prima cosa ti segnalo che il file in cui salvare la chiave pubblica per autorizzarla di solito si chiama authorized_keys, non authorized_file.
Probabilmente si tratta di un refuso, dato che collegando in ssh da linux l'autenticazione con certificato funziona, nel caso controlla nel file di configurazione del demone ssh la direttive AuthorizedKeysFile se è specificato in modo diverso.

Per capire cosa sta succedendo devi controllare i file di log /var/log/secure.log (su RedHat e derivate) oppure /var/log/auth.log (su Debian e derivate), rimani in ascolto su quei log con "tail -f" e vedi cosa compare quando cerchi di accedere con Putty.

Una cosa abbastanza comune è l'utilizzo di cypher suites obsolete e magari rifiutate dal demone ssh perchè insicure, molti scaricano l'exe di putty e lo usano per anni e anni senza preoccuparsi di aggiornarlo, mentre il server (e conseguentemente il demone ssh) si aggiornano e bloccando l'accesso di default a client che si presentano con algoritmi non più ritenuti sicuri.

Comunque sia in quei log troverai sicuramente la causa.

[Tiger99]

Originariamente inviato da Tasslehoff

Per prima cosa ti segnalo che il file in cui salvare la chiave pubblica per autorizzarla di solito si chiama authorized_keys, non authorized_file.
Probabilmente si tratta di un refuso,

Sì, infatti. Ho digitato male io il nome nel post,

Originariamente inviato da Tasslehoff

Una cosa abbastanza comune è l'utilizzo di cypher suites obsolete e magari rifiutate dal demone ssh perchè insicure, molti scaricano l'exe di putty e lo usano per anni e anni senza preoccuparsi di aggiornarlo, mentre il server (e conseguentemente il demone ssh) si aggiornano e bloccando l'accesso di default a client che si presentano con algoritmi non più ritenuti sicuri.

È quello di PortableApps, sempre aggiornato. Ed infatti è la 0.73.
In ogni caso ho installato anche la versione Linux, direttamente con apt install.

Originariamente inviato da Tasslehoff

Per capire cosa sta succedendo devi controllare i file di log /var/log/secure.log (su RedHat e derivate) oppure /var/log/auth.log (su Debian e derivate), rimani in ascolto su quei log con "tail -f" e vedi cosa compare quando cerchi di accedere con Putty.
...
Comunque sia in quei log troverai sicuramente la causa.

Ecco, non ci vedo nulla di anomalo.
Ad esempio:
Lancio puTTY e da questo lancio il profilo già configurato con un utente, ma usando la chiave.
A video del terminale win10 compare subito:

Using username "pippo".
Server refused our key
Keyboard-interactive authentication prompts from server:
| Password:
End of keyboard-interactive prompts from server
Linux ls-ulhq-1 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Jun 18 15:54:38 2020 from 192.168.201.201
pippo@ls-ulhq-1:

Mentre nel log appare soltanto:

Jun 18 15:57:47 ls-ulhq-1 sshd[507]: Accepted keyboard-interactive/pam for pippo from 192.168.201.201 port 49907 ssh2
Jun 18 15:57:47 ls-ulhq-1 sshd[507]: pam_unix(sshd:session): session opened for user pippo by (uid=0)
Jun 18 15:57:47 ls-ulhq-1 systemd-logind[354]: New session 4 of user pippo.

Questo è il log della sessione, in puTTY

2020-06-18 15:57:37	Looking up host "192.168.201.11" for SSH connection
2020-06-18 15:57:37	Connecting to 192.168.201.11 port 1022
2020-06-18 15:57:37	We claim version: SSH-2.0-PuTTY_Release_0.73
2020-06-18 15:57:37	Remote version: SSH-2.0-OpenSSH_7.9p1 Debian-10+deb10u2
2020-06-18 15:57:37	Using SSH protocol version 2
2020-06-18 15:57:37	No GSSAPI security context available
2020-06-18 15:57:37	Doing ECDH key exchange with curve Curve25519 and hash SHA-256 (unaccelerated)
2020-06-18 15:57:37	Server also has ecdsa-sha2-nistp256/ssh-rsa host keys, but we don't know any of them
2020-06-18 15:57:37	Host key fingerprint is:
2020-06-18 15:57:37	ssh-ed25519 255 d8:8f:87:27:ca:87:01:86:20:6e:9e:a0:14:b7:d4:21
2020-06-18 15:57:37	Initialised AES-256 SDCTR (unaccelerated) outbound encryption
2020-06-18 15:57:37	Initialised HMAC-SHA-256 (unaccelerated) outbound MAC algorithm
2020-06-18 15:57:37	Initialised AES-256 SDCTR (unaccelerated) inbound encryption
2020-06-18 15:57:37	Initialised HMAC-SHA-256 (unaccelerated) inbound MAC algorithm
2020-06-18 15:57:37	Reading key file "L:\LS-ULHQ-1\LS-ULHQ-1-PuTTY-Private-Key.ppk"
2020-06-18 15:57:37	Offered public key
2020-06-18 15:57:37	Server refused our key
2020-06-18 15:57:37	Attempting keyboard-interactive authentication
2020-06-18 15:57:46	Access granted
2020-06-18 15:57:46	Opening main session channel
2020-06-18 15:57:47	Opened main channel
2020-06-18 15:57:47	Allocated pty
2020-06-18 15:57:47	Started a shell/command

E questo è in fine il file sshd_config
(dove tra l'altro vedo che PasswordAuthentication = no e quindi in teoria neppure dovrebbe chiedermi le credenziali, giusto?)

Port 1022
ListenAddress 0.0.0.0
PermitRootLogin no
PubkeyAuthentication yes
AuthorizedKeysFile   .ssh/authorized_keys .ssh/authorized_keys2
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication yes
UsePAM yes
X11Forwarding yes
PrintMotd no
AcceptEnv LANG LC_*
Subsystem   sftp   /usr/lib/openssh/sftp-server