SSH con accesso senza password

[sergio59]

Salve,
ho la necessità di trasferire dati da un computer ad un altro tramite script bash.

Avevo fatto un programma che in pratica tramite la copia delle chiavi, riusciva a trasferire da un computer ad un altro senza dover digitare la password.
Dopo upgrade del SO, non riesco più.
Ho denerato la chiave con

 ssh-keygen

trasferito la chiave con

ssh-copy-id -i ~/.ssh/id_rsa.pub [email protected]

ma quando voglio accedere mi richiede la password
La copia viene scritta nella cartella .ssh dell’utente user nel file authorized_keys, lo stesso file della direttiva di /etc/ssh/sshd_config

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile	.ssh/authorized_keys

ma niente, continua a non farmi connettere.
Ho pensato a selinux dando questo comando

getsebool -a |grep ssh

e questo è il risultato

fenced_can_ssh --> off
selinuxuser_use_ssh_chroot --> off
ssh_chroot_rw_homedirs --> off
ssh_keysign --> off
ssh_sysadm_login --> off

Può essere uno di questi gli incriminati?

Grazie e saluti
Sergio

[rmx]

Ciao,
Aggiornando il sistema operativo cambia anche il fingerprints che non combacia più con quello contenuto nel file
[utente@host_name ~] $ ls ~/.ssh/known_hosts
pertanto nel file dovresti cancellare le voci relative all’host che hai aggiornato (o eventualmente cancellare il file) e riprovare successivamente il comando ssh-copy-id

Saluti.

[sergio59]

Già fatto, ma non funziona. Ho cancellato tutti i files che erano dentro .SSH, ma niente

[alciregi]

I log. Guarda se nei log vedi qualcosa di interessante. Eventualmente aumenta la verbosità di sshd sul server e/o del comando ssh sul client (ssh -v).

[sergio59]

ssh -v [email protected]

OpenSSH_7.2p2, OpenSSL 1.0.2k-fips  26 Jan 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 58: Applying options for *
debug1: Connecting to 192.168.1.1 [192.168.1.1] port 22.
debug1: Connection established.
debug1: identity file /home/sysop/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sysop/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sysop/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sysop/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sysop/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sysop/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sysop/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sysop/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2
debug1: match: OpenSSH_7.2 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.1.1:22 as 's.tardioli'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: [email protected] need=64 dh_need=64
debug1: kex: [email protected] need=64 dh_need=64
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:5Cc81Npzzn7KsYcmdtGOwExaNmNdvcPV7JIJKLcO5NQ
debug1: Host '192.168.1.1' is known and matches the ECDSA host key.
debug1: Found key in /home/sysop/.ssh/known_hosts:2
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available (default cache: KEYRING:persistent:1001)

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available (default cache: KEYRING:persistent:1001)

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available (default cache: KEYRING:persistent:1001)

debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/sysop/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/sysop/.ssh/id_dsa
debug1: Trying private key: /home/sysop/.ssh/id_ecdsa
debug1: Trying private key: /home/sysop/.ssh/id_ed25519
debug1: Next authentication method: password
[email protected]'s password: 

[alciregi]

Prova ad aggiungere -o IdentitiesOnly=yes quando lanci ssh.
ssh -o IdentitiesOnly=yes [email protected]

[sergio59]

No, non funziona. Sempre la password mi chiede

[alciregi]

@sergio59

Ho cancellato tutti i files che erano dentro .SSH

Ma hai cancellato anche authorized_keys?

[alciregi]

Guarda i log sul server, mentre fai ssh dal client.
Dicono qualcosa di interessante?

[sergio59]

I log non ci sono più, non esiste /var/log/nome prog, ma con journalctl e non ci capisco molto…
Puoi dirmi come fare?

[alciregi]

Non è che i log non ci sono più c’è appunto journald.

Per saperne di più, https://fedoramagazine.org/systemd-using-journal/ e https://docs.fedoraproject.org/en-US/quick-docs/viewing-logs/

Insomma, sul server lancia journalctl -f (che è tipo tail -f nomediunfile) e prova a collegarti con ssh.

[sergio59]

Ecco cosa succede:

mag 12 15:59:48 bina.agr.unipg.it python3[19935]: SELinux is preventing sshd from read access on the file authorized_keys.

Selinux

Grazie del suggerimento con journalctl, molto interessante
Dando sul server setenforce permissive, è entrato immediatamente

[alciregi]

Così hai disabilitato selinux. No buono.

Qual è il risultato di questo comando?
ls -Z ~/.ssh/authorized_keys

Se non è così (vedi il security context ssh_home_t)
unconfined_u:object_r:ssh_home_t:s0 .ssh/authorized_keys

Allora dai questo comando:
restorecon ~/.ssh/authorized_keys

[sergio59]

Ora l’ho cambiato con

chcon -R unconfined_u:object_r:user_home_t:s0 /home/user/.ssh

ls -Z ~/.ssh/authorized_keys
unconfined_u:object_r:user_home_t:s0 /home/user/.ssh/authorized_keys

[sergio59]

Grazie

[alciregi]

Scusa, guarda la mia risposta precedente. L’ho modificata mentre stavi scrivendo.

[sergio59]

Grazie tante. In questa nuova veste, deve essere messo RISOLTO in alto?
Come dobbiamo comportarci?

[alciregi]

Discourse avrebbe un quadratino da spuntare sotto ogni risposta al topic. Ovviamente andrebbe spuntata la risposta che si valuta come quella risolutrice.
Solo che qui non vedo quadratini.

@amministratori? @moderatori? Non è abilitata questa funzione?

[frafra]

Plugin abilitato. Ora @sergio59 dovrebbe poter spuntare la discussione per segnalare che il problema è stato risolto

[sergio59]

Ho un altro forum dove gira lo stesso programma e c’è il quadratino.

@amministratori? @moderatori? Qui non lo vedo