SSH con accesso senza password

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

Ciao,
Aggiornando il sistema operativo cambia anche il fingerprints che non combacia più con quello contenuto nel file
[[email protected]_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.

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

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).

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: 

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

No, non funziona. Sempre la password mi chiede

Ma hai cancellato anche authorized_keys?

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

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

Non è che i log non ci sono più :slight_smile: 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.

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
:+1:

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

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

Grazie :grin: :point_up:

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

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

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?

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

1 Mi Piace

Ho un altro forum dove gira lo stesso programma e c’è il quadratino.
image
@amministratori? @moderatori? Qui non lo vedo