Newsgroup: it.comp.os.linux.sys
Titolo: strano comportamento ssh root@<host>

Ho due server, chiamiamoli AAA e BBB, il primo in LAN interna, il 
secondo in DMZ con un firewall di mezzo. Hanno installata la stessa 
versione di Linux (SUSE SLES8), AAA è un po' più aggiornato come 
pacchetti, ma per quanto riguarda i pacchetti che credo siano coinvolti 
nella cosa (openssh, openssl) le versioni sono identiche (le ultime 
disponibili sul sito di SUSE). Stesso sshd_config, che è quello di 
default con la sola modifica da parte mia di PermitRootLogin da "yes" a 
"no".
Se faccio ssh root@AAA dalla mia macchina si comporta come se sbagliassi 
la password, che è il comportamento che avevo sempre visto anche sulle 
altre macchine.
Se faccio ssh root@BBB dalla mia macchina e azzecco la password mi fa:
me@mypc:~> ssh root@BBB
root@BBB's password:
Connection closed by 123.456.789.012
me@mypc:~>
(naturalmente con ssh <utente normale>@BBB entra)
Da cosa pensate che possa dipendere? C'entra qualcosa il fatto che BBB 
sia in DMZ?
Saluti,
-- 
Cris Carampa (
spamto:cri...@operamail.com
)
The World is Case Sensitive.
Only the Evil Empire is cAsE inSenSitivE.

 Da cosa pensate che possa dipendere?
Guarda nei log.
Davide
-- 
Q:  How many Oregonians does it take to screw in a light bulb?
A:  Three.  One to screw in the lightbulb and two to fend off all those
    Californians trying to share the experience.

 Guarda nei log.
Scusate, ho riprovato e ho visto che, dopo l'allineamento dei pacchetti 
openssh e openssl all'ultima versione disponibile su entrambi i server, 
il comportamento è quello riportato sopra per entrambi.
Entrambi i log dicono che:
Sep 23 12:10:46 XXX sshd[31519]: ROOT LOGIN REFUSED FROM 
::ffff:123.456.789.012
Sep 23 12:10:46 XXX sshd[31519]: Failed password for root from 
::ffff:123.456.789.012 port 33478
Sep 23 12:10:46 XXX sshd[31519]: fatal: monitor_read: unsupported 
request: 32
Puo' essere un baco di SuSE?


 Puo' essere un baco di SuSE?
1) cine ti hanno detto guarda i log
2) al limite prova a controllare il file di configurazione di sshd, lo
leggi, capisci cosa c'è scritto, quindi capisci come deve comportarsi ed
eventualmente lo correggi
3) se on sai dove sono i log, icoli
4) se non sai cosa significano le voci del file di configurazione, usa man
e la documentazione
5) se proprio non risolvi, la prossima volta incolla:
 a) il file di configurazione
 b) il log di quanto succede
Max

 Sep 23 12:10:46 XXX sshd[31519]: ROOT LOGIN REFUSED FROM 
...lo sai vero che per poter fare login da remoto, con ssh o con
quelchee devi avere il pts nell'elenco delle console 'sicure'?
Davide
-- 
Democracy is the recurrent suspicion that more than half of the people
are right more than half of the time.
	-- E. B. White

 quelchee devi avere il pts nell'elenco delle console 'sicure'?
Intendi /etc/securetty? Nelle SuSE non c'è n'è mai stato bisogno, 
comunque ho provato ad aggiungervi i pts ma il risultato non cambia.
Grazie. Ciao,


  b) il log di quanto succede
Il pezzetto di log l'ho già postato, incollo qui di seguito il file di 
configurazione:
#       $OpenBSD: sshd_config,v 1.56 2002/06/20 23:37:12 markus 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 change a
# default value.
#Port 22
#Protocol 2,1
#ListenAddress 0.0.0.0
#ListenAddress ::
# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 3600
#ServerKeyBits 768
# Logging
#obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO
# Authentication:
#LoginGraceTime 600
###PermitRootLogin yes
PermitRootLogin no
#StrictModes yes
#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile     .ssh/authorized_keys
# rhosts authentication should not be used
#RhostsAuthentication no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# 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
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
# Change to no to disable s/key passwords
ChallengeResponseAuthentication no
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#AFSTokenPassing no
# Kerberos TGT Passing only works with the AFS kaserver
#KerberosTgtPassing no
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPIKeyExchange no
#GSSAPIUseSessionCredCache yes
#GSSAPICleanupCreds yes
# Set this to 'yes' to enable PAM keyboard-interactive authentication
# Warning: enabling this may bypass the setting of 'PasswordAuthentication'
#PAMAuthenticationViaKbdInt yes
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#KeepAlive yes
#UseLogin no
#UsePrivilegeSeparation no
#Compression yes
#MaxStartups 10
# no default banner path
#Banner /some/path
#VerifyReverseMapping no
# override default of no subsystems
Subsystem       sftp    /usr/lib/ssh/sftp-server
Grazie. Ciao,


 comunque ho provato ad aggiungervi i pts ma il risultato non cambia.
Hummm... da quello che si vede dai tuoi log pare che tu abbia IPV6
abilitato, magari (dato che lo 'strict' e' di default) lui cerca di
fare un reverse-dns dell'IP e gli va' buca...
Davide
-- 
Immortality -- a fate worse than death.
		-- Edgar A. Shoaff

 Cosa non e' chiaro, esattamente? <g>
Forse mi sono spiegato male. Sulle macchine più vecchie questa opzione 
faceva sì che chi tentava di loggarsi direttamente con root via ssh si 
beccasse continuamente dei "Permission denied, please try again." anche 
se azzeccava la password.
Su queste due macchine nuove a chi azzecca la password di root viene 
troncata la connessione sui denti. Lo so che l'utente non entra 
comunque, ma in questo modo impara di avere azzeccato la password di 
root, e la cosa non mi piace.
O forse volevi dirmi che questo è il funzionamento normale di quella 
versione di sshd? Sulle vecchie SuSE c'è openssh 2.91p1, sulle nuove c'è 
la versione 3.4p1.


 Hummm... da quello che si vede dai tuoi log pare che tu abbia IPV6
Altra cosa: io mi ritrovo con DUE sshd_config: uno in /etc/ssh e
l'altro in /usr/local/etc... non chiedere il perche' che non lo so
neanche io. Ma quello "buono" e' in /etc/ssh.
Davide
-- 
"You should, without hesitation, pound your typewriter into a
plowshare, your paper into fertilizer, and enter agriculture"
		-- Business Professor, University of Georgia

 
Mi sbagliero', ma mi ricorda una cosa uscita su Bugtraq un anno e mezzo fa.
Riguardava l'accoppiata ssh - PAM.
Io l'ho ricevuto in ml, ma dovresti trovare il tutto al link
http://www.securityfocus.com/archive/1/320031/2003-04-29/2003-05-05/0
Vedi se fa al caso tuo.
Ciao
C.
P.S. mi scuso se ho combinato pasticci con quote etc.
Non ho il mio solito newsreader sotto mano...