[Risolto] SSH: non è più possibile accedere da remoto

Fedora Linux Internet, Reti e Sicurezza
#1

Ciao a tutti ragazzi…

non riesco a venirne a capo. Sono anni che uso l’autenticazione ssh da remoto per accedere al mio server (FC12) e ora non riesco più a farlo.
Accedo alla macchina regolarmente, ma da remoto nisba.
La configurazione è in modo tale da accedere solo con chiave e MAI come root. Qui il file di configurazione:

[code]#MaxSessions 10

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys

For this to work you will also need host keys in /etc/ssh/ssh_known_hosts

#RhostsRSAAuthentication no

similar for protocol version 2

#HostbasedAuthentication no

Change to yes if you don’t trust ~/.ssh/known_hosts for

RhostsRSAAuthentication and 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!

PermitEmptyPasswords no
PasswordAuthentication no

Change to no to disable s/key passwords

#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no

Kerberos options

#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

GSSAPI options

GSSAPIAuthentication no
#GSSAPIAuthentication yes
#GSSAPICleanupCredentials no
#GSSAPICleanupCredentials yes

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 no
UsePAM yes

Accept locale-related environment variables

AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS

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

no default banner path

#Banner none

override default of no subsystems

Subsystem sftp /usr/libexec/openssh/sftp-server

Example of overriding settings on a per-user basis

#Match User anoncvs

X11Forwarding no

AllowTcpForwarding no

ForceCommand cvs server

[/code]

Giorni fa, nel tentare di entrare come al solito, ricevo un avviso di “POSSIBLE BREAK-IN ATTEMPT!” senza riuscire a entrare. Vabbè, talvolta succede, poi si risistema.
Stavolta invece nulla. Vado a casa e accedo fisicamente alla macchina per impostare PasswordAuthentication yes (e riavvio il servizio sshd) in modo tale da ripetere la procedura di creazione chiavi (neanche con chiave si accede più) eccetera. Invece niente, quando dal computer che uso per accedere da remoto digito:

$ ssh [email protected]
[email protected]’s password:
Permission denied, please try again.

Cioè pur avendo ripristinato l’accesso con password non riesco ad accedere. Non riesco a capire perché non funziona più PasswordAuthentication yes!!!
La password che uso è la stessa da anni, posso sbagliare a digitarla 2 o 3 volte su 100… ma di tentativi ne ho fatti parecchi. Non mi era mai successo in 5 anni…

Cosa mi consigliate? Ho fatto un giro per i vari log ma non ho trovato niente di utile, almeno per me… ma non so esattamente cosa devo verificare. Che da qualche parte sia stato attivato qualche “blocco”? Ho provato anche senza firewall, niente…

Aggiungo anche che l’accesso con chiave funziona perfettamente se uso la rete interna, cioè se provo l’accesso dall’interno della mia rete domestica (peraltro wi-fi).
Inoltre, se provo temporaneamente a disabilitare l’accesso con chiave ponendo “PubkeyAuthentication no”, allora anche da rete interna mi viene richiesta la password, ma stavolta funziona! Quindi riepilogando:

**- da rete LAN o WLAN accesso OK sia con chiave che con password

  • da INTERNET, nisba**

Grazie,
Fabio.

#2

[quote=twsfedora]
Giorni fa, nel tentare di entrare come al solito, ricevo un avviso di “POSSIBLE BREAK-IN ATTEMPT!” senza riuscire a entrare.[/quote]
Di solito succede quando una delle macchine viene formattata (e, quindi, risulta diversa). In questo caso io cancello, nella macchina da cui tenti l’accesso, il file ~/.ssh/known_hosts (o, meglio ancora, lo apro con gedit e cancello solo la riga relativa alla macchina a cui tento di accedere). Il successivo tentativo di accesso mi avverte che la macchina non è conosciuta, io la inserisco tra quelle note, e va. Edit: rileggendo bene la parte finale del tuo messaggio, non credo che sia il tuo caso (altrimenti non riusciresti a collegarti neanche dalla rete interna).

Ma prima, ovviamente, bisognerebbe essere sicuri che accedi alla macchina giusta (IP fisso? dinamico? mnemonici stile dyndns? router che se ne occupa?). E, rileggendo bene la parte finale del tuo messaggio, andrei ad investigare proprio lì. Come ti connetti dall’esterno? Non con l’IP, immagino. Che ruolo ha il router in tutto ciò?

#3

Ciao! Grazie per la risposta.

Nel frattempo ho capito il (solito) bicchiere d’acqua in cui mi sono perso (o meglio: affogato!)

Ero convinto di usare l’IP giusto, pur sapendo che è dinamico e quindi ogni tanto cambia… ma poiché mi chiedeva la password pensavo fosse il computer che appunto mi rispondeva! A “regime” uso il servizio noip per ovviare al problema, che però non era aggiornato perché nel frattempo avevo cambiato le credenziali per una email che non uso più… Insomma una serie di circostanza che mi hanno totalmente fuorviato.

Il mio post quindi è tecnicamente “inutile” ma spero serva da “monito” a chi, come me, a volte è un po’ distratto…!

#4

Mai trascurare l’ovvio… grazie per averci aggiornato :slight_smile: