Errore Permission denied (publickey)

Sicurezza del sistema: firewall, antispam, antivirus, ssh, patch, bug, eccetera.
WhiteTiger
Scoppiettante Seguace
Scoppiettante Seguace
Messaggi: 436
Iscrizione: sabato 6 marzo 2010, 17:48

Errore Permission denied (publickey)

Messaggio da WhiteTiger » venerdì 24 maggio 2019, 20:51

Ho creato un utente pippo perché abbia l'accesso con SSH Key.

Questi i passaggi:
mkdir /home/pippo/.ssh
Copio qui dentro la chiave pubblica con nome authorized_keys

chown pippo:pippo /home/pippo/.ssh
chmod a-rwx,u=rw /home/pippo/.ssh/authorized_keys

nano /etc/ssh/sshd_config e cambio:
PasswordAuthentication no
UsePAM no
ChallengeResponseAuthentication no
PermitRootLogin no

sudo systemctl restart sshd

Mi aspetto così che root non possa fare il login ed invece pippo possa farlo con la sua SSH Key privata.
Invece per entrambi ho Permission denied (publickey).

Dove accidenti sbaglio?

Pike
Imperturbabile Insigne
Imperturbabile Insigne
Messaggi: 4043
Iscrizione: domenica 20 gennaio 2008, 1:13
Desktop: xubuntu
Distribuzione: Bionic Beaver i686 (18.04)
Contatto:

Re: Errore Permission denied (publickey)

Messaggio da Pike » venerdì 24 maggio 2019, 23:13

Hai letto nei log?
Adoro il Secondo Principio di Dilbert, di Scott Adams. "Si parte dalla certezza che siamo tutti idioti". Io almeno me ne sono reso conto
Come certificato dalla moderazione, incivile e maleducato. You have been warned.
Se il tuo tempo è più importante del mio, allora non hai bisogno del mio tempo.

WhiteTiger
Scoppiettante Seguace
Scoppiettante Seguace
Messaggi: 436
Iscrizione: sabato 6 marzo 2010, 17:48

Re: Errore Permission denied (publickey)

Messaggio da WhiteTiger » sabato 25 maggio 2019, 11:58

Francamente auth.log non mi sta aiutando.
Il server di test (un VPS) stava funzionando, l'ho reinstallato e forse ora mi sono dimenticato qualcosa.

Questa l'attuale situazione.

SSH Key (la stessa) installata sia per root che per l'utente.
file .ssh/config nella mia cartella utente

Codice: Seleziona tutto

Host Server-R
	HostName NOME-SERVER
	User root
	Port NUM-PORTA
	IdentityFile /home/myuser/.ssh/Chiavi/NOME-CHIAVE

Host Server-NU
	HostName NOME-SERVER
	User NOME-UTENTE
	Port NUM-PORTA
	IdentityFile /home/myuser/.ssh/Chiavi/NOME-CHIAVE
Per fare il login uso:
  1. ssh Server-R per accedere come root
  2. ssh Server-NU per accedere con l'utente
Sul server, il file /etc/ssh/sshd_config è modificato con:
  • Port NUM-PORTA
  • UsePAM no
  • PermitRootLogin no
  • PasswordAuthentication no
  • ChallengeResponseAuthentication no
Io mi aspetto che non si possa fare il login con root e si possa fare invece con il nome dell'utente.
Anzi, io mi aspetto che non venga neppure richiesta la password e l'utente sia già di per sé autenticato dalla chiave stessa.

In realtà sia nel fare login come root che come NOME-UTENTE, prima mi chiede la password della Chiave e poi mi restituisce Permission denied (publickey)

Per potermi collegare devo cambiare le impostazioni con
  • Port NUM-PORTA
  • UsePAM yes
  • PermitRootLogin no
  • PasswordAuthentication no
  • ChallengeResponseAuthentication yes
Così però mi chiede la password della chiave e poi la password degli utenti; solo che quella di root non viene mai accettata.

Questo il log, prima e dopo la variazione.
In mezzo c'è un accesso via console KVM per poter fare la variazione.
Il che è già anche questa una cosa che non capisco perché se blocco l'accesso root, in teoria non potrei accedere neppure da KVM.
Dopo la variazione ho fatto un reboot da console.

Nel secondo tentativo ci sono due accessi come root, rifiutati, l'accesso come NOME-UTENTE e poi un su -

Codice: Seleziona tutto

May 25 11:42:15 NOME-SERVER sshd[752]: Server listening on 0.0.0.0 port NUM-PORTA.
May 25 11:42:15 NOME-SERVER sshd[752]: Server listening on :: port NUM-PORTA.
May 25 11:44:20 NOME-SERVER sshd[822]: Connection closed by authenticating user root IP_ADDRESS port 43316 [preauth]
May 25 11:44:46 NOME-SERVER sshd[824]: Connection closed by authenticating user NOME-UTENTE IP_ADDRESS port 43318 [preauth]
May 25 11:45:31 NOME-SERVER login[760]: pam_unix(login:session): session opened for user root by LOGIN(uid=0)
May 25 11:45:31 NOME-SERVER systemd-logind[741]: New session 1 of user root.
May 25 11:45:31 NOME-SERVER systemd: pam_unix(systemd-user:session): session opened for user root by (uid=0)
May 25 11:45:31 NOME-SERVER login[860]: ROOT LOGIN  on '/dev/tty1'
May 25 11:47:15 NOME-SERVER systemd-logind[738]: New seat seat0.
May 25 11:47:15 NOME-SERVER systemd-logind[738]: Watching system buttons on /dev/input/event0 (Power Button)
May 25 11:47:15 NOME-SERVER systemd-logind[738]: Watching system buttons on /dev/input/event1 (AT Translated Set 2 keyboard)
May 25 11:47:15 NOME-SERVER sshd[761]: Server listening on 0.0.0.0 port NUM-PORTA.
May 25 11:47:15 NOME-SERVER sshd[761]: Server listening on :: port NUM-PORTA.
May 25 11:47:19 NOME-SERVER sshd[761]: Received SIGHUP; restarting.
May 25 11:47:19 NOME-SERVER sshd[761]: Server listening on 0.0.0.0 port NUM-PORTA.
May 25 11:47:19 NOME-SERVER sshd[761]: Server listening on :: port NUM-PORTA.
May 25 11:49:55 NOME-SERVER sshd[824]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=IP_ADDRESS  user=root
May 25 11:49:57 NOME-SERVER sshd[822]: error: PAM: Authentication failure for root from IP_ADDRESS
May 25 11:50:06 NOME-SERVER sshd[825]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=IP_ADDRESS  user=root
May 25 11:50:08 NOME-SERVER sshd[822]: error: PAM: Authentication failure for root from IP_ADDRESS
May 25 11:50:08 NOME-SERVER sshd[822]: Postponed keyboard-interactive for root from IP_ADDRESS port 43354 ssh2 [preauth]
May 25 11:50:11 NOME-SERVER sshd[822]: Connection closed by authenticating user root IP_ADDRESS port 43354 [preauth]
May 25 11:50:43 NOME-SERVER sshd[827]: Accepted keyboard-interactive/pam for NOME-UTENTE from IP_ADDRESS port 43356 ssh2
May 25 11:50:43 NOME-SERVER sshd[827]: pam_unix(sshd:session): session opened for user NOME-UTENTE by (uid=0)
May 25 11:50:43 NOME-SERVER systemd-logind[738]: New session 1 of user NOME-UTENTE.
May 25 11:50:43 NOME-SERVER systemd: pam_unix(systemd-user:session): session opened for user NOME-UTENTE by (uid=0)
May 25 11:50:58 NOME-SERVER su[880]: Successful su for root by NOME-UTENTE
May 25 11:50:58 NOME-SERVER su[880]: + /dev/pts/0 NOME-UTENTE:root
May 25 11:50:58 NOME-SERVER su[880]: pam_unix(su:session): session opened for user root by NOME-UTENTE(uid=1000)
May 25 11:50:58 NOME-SERVER su[880]: pam_systemd(su:session): Cannot create session: Already running in a session

WhiteTiger
Scoppiettante Seguace
Scoppiettante Seguace
Messaggi: 436
Iscrizione: sabato 6 marzo 2010, 17:48

Re: Errore Permission denied (publickey)

Messaggio da WhiteTiger » domenica 26 maggio 2019, 9:54

Ci deve essere qualche altra impostazione altrove perché su un secondo server invece mi collego direttamente con il nome utente utilizzando soltanto la chiave, non viene richiesta la password dell'utente.
Eppure il file sshd_config è esattamente lo stesso.

Pike
Imperturbabile Insigne
Imperturbabile Insigne
Messaggi: 4043
Iscrizione: domenica 20 gennaio 2008, 1:13
Desktop: xubuntu
Distribuzione: Bionic Beaver i686 (18.04)
Contatto:

Re: Errore Permission denied (publickey)

Messaggio da Pike » mercoledì 29 maggio 2019, 0:58

Confronta i log. Messages incluso.
Adoro il Secondo Principio di Dilbert, di Scott Adams. "Si parte dalla certezza che siamo tutti idioti". Io almeno me ne sono reso conto
Come certificato dalla moderazione, incivile e maleducato. You have been warned.
Se il tuo tempo è più importante del mio, allora non hai bisogno del mio tempo.

Avatar utente
DoctorStrange
Entusiasta Emergente
Entusiasta Emergente
Messaggi: 1762
Iscrizione: mercoledì 14 ottobre 2015, 9:33
Desktop: Gnome3
Distribuzione: Ubuntu 18.04 Bionic Beaver
Sesso: Maschile
Località: Roma, Italia

Re: Errore Permission denied (publickey)

Messaggio da DoctorStrange » mercoledì 29 maggio 2019, 8:54

Controlla se, in /home/$USER/.ssh c'è un file che si chiama "known_hosts". Qui potrebbe esserci traccia di qualche precedente chiave o connessione. azzera questo file con un

Codice: Seleziona tutto

sudo tee known_hosts /dev/zero
che poi interrompi con ctrl+c, e poi ritenta l'accesso.

WhiteTiger
Scoppiettante Seguace
Scoppiettante Seguace
Messaggi: 436
Iscrizione: sabato 6 marzo 2010, 17:48

Re: Errore Permission denied (publickey)

Messaggio da WhiteTiger » mercoledì 29 maggio 2019, 20:01

DoctorStrange [url=https://forum.ubuntu-it.org/viewtopic.php?p=5136302#p5136302][img]https://forum.ubuntu-it.org/images/icons/icona-cita.gif[/img][/url] ha scritto:Controlla se, in /home/$USER/.ssh c'è un file che si chiama "known_hosts". Qui potrebbe esserci traccia di qualche precedente chiave o connessione. azzera questo file con un

Codice: Seleziona tutto

sudo tee known_hosts /dev/zero
che poi interrompi con ctrl+c, e poi ritenta l'accesso.
No, non c'è.

WhiteTiger
Scoppiettante Seguace
Scoppiettante Seguace
Messaggi: 436
Iscrizione: sabato 6 marzo 2010, 17:48

Re: Errore Permission denied (publickey)

Messaggio da WhiteTiger » venerdì 7 giugno 2019, 7:47

Cribbio, ho riportato la stessa configurazione di sshd_config su un altro VPS, vergine, sempre con Ubuntu 18.04, ed è un comportamento tutto differente.
Evidentemente ognuno genera un server con una qualche configurazione non propriamente standard.

Questo non mi chiede neppure la chiave SSH.
Nel dubbio, ho provato a rinominare la chiave privata sul mio PC ed ora anche sul primo VPS, mi compare sì un errore, ma poi il login lo fa ugualmente.
In altre parole, che ci sia o meno la chiave privata ai server gli fa un baffo!

Questo è il file ssh_config sul nuovo server

Codice: Seleziona tutto

#	$OpenBSD: sshd_config,v 1.101 2017/03/14 07:19:07 djm Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

Port 9022
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:

LoginGraceTime 1m
PermitRootLogin no
StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

PubkeyAuthentication yes

# Expect .ssh/authorized_keys2 to be disregarded by default in future.
AuthorizedKeysFile .ssh/authorized_keys

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none
Banner /etc/ssh/banner-pre-login.txt

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

# override default of no subsystems
Subsystem	sftp	/usr/lib/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#	X11Forwarding no
#	AllowTcpForwarding no
#	PermitTTY no
#	ForceCommand cvs server

RSAAuthentication yes
Come dicevo in precedenza, l'obiettivo è quello di collegarsi soltanto con la coppia di chiavi SSH generata.
Non dovrebbe apparire la richiesta di login.
Invece il login compare, a quanto pare senza verificare la presenza o meno della chiave.
Poi se si autentica root, si continua a ripetere la richiesta di password (senza errore).

Scrivi risposta

Torna a “Sicurezza”

Chi c’è in linea

Visualizzano questa sezione: 0 utenti iscritti e 5 ospiti