Newsgroup: it.comp.os.linux.sys
Titolo: ssh e authorized_keys ignorato

Un saluto a tutti.
Ho un problema abbastanza strano che non sono ancora riuscito a risolvere.
Ho messo in pista un server Debian armato di una Etch.
Questo server ha (tra gli altri servizi) un server openssh configurato per 
rifiutare connessioni dirette come utente root, e lavorare con le chiavi per 
autorizzare me e un altro paio di colleghi.
Questo server è stato messo in pista come clone di un altro server, quindi 
presentava le stesse chiavi private per ssh.
Fino a questo punto funzionava tutto. L'accesso al mio utente sul server 
avveniva senza nessun problema utilizzando la mia chiave privata invece che 
chiedere password.
Ho deciso di cambiare la chiave del server (quelle in /etc/ssh, i vari 
ssh_host_xxxxxxx), sicuramente non l'ho fatto nella maniera corretta (di questo 
ne sono sicuro) poiché da allora l'autorizzazione mediante chiavi non va più.
Piccola nota: il server non andava in sostituzione di un altro, ma è stato 
clonato per avere un altro server con la stessa dotazione di applicativi 
(esigenze di sviluppo). Infatti password, hostname e indirizzi di rete sono 
state le prime cose che sono state cambiate dopo la clonazione.
Ho provato anche a disinstallare (con il purge) il pacchetto di ssh sul server e 
ad installarlo ex novo, ma la situazione non cambia.
Le mie chiavi privata e pubblica del portatile non hanno problemi (le uso anche 
sul pc di casa e funzionano bene), il problema è localizzato solo sul server.
Più che un problema è un mezzo fastidio, poiché utilizzando questo server come 
archivio per repository git e accedendo via ssh/sftp bisogna ogni volta scrivere 
la password (14 caratteri tra numeri lettere e simboli. Robusta ma dopo la 30ma 
volta, 2 palle :-) ).
Ho anche verificato i file di configurazione di ssh (il demone) con quello di un 
paio di altri sistemi debian Etch e non ci sono differenze (a meno della porta o 
dell'autorizzazione dell'utente root al login).
Qualcuno di voi ha qualche suggerimento su cosa cercare per riattivare il 
controllo delle chiavi? o a qualcuno è già capitato qualcosa di simile?
Una cosa l'ho imparata: generare manualmente le chiavi host del server non è la 
procedura giusta ;-)
Mi piacerebbe risolvere senza dover adottare il metodo M$: brasare e rifare. 
Visto che è sicuramente evitabile preferirei evitare.
Rigrazio anticipatamente chiunque mi possa dare una mano.
Luca

 non va più.
ti dico una delle possibilita' (una cosa che e' successa a me): permessi 
sbagliati sulla home directory.
se metti un 777 o sballi la ownership, con la chiave non funziona piu' e 
funziona solo con l'autenticazione tramite password! 
seconda cosa, sia in ubuntu, sia in gentoo (quindi credo faccia ormai 
parte di openssh) viene fornito uno script che si chiama 'ssh-copy-id'
Usa quello. E' molto piu' pratico da usare.
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

 
Questo me lo segno. tnx
PSK

 sapere cosa non piace al server?
usa "ssh -v" quando ti connetti dal client, aggiungi piu' "v" se vuoi 
piu' debug, magari capisci dove si inceppa e perchè non ti accetta la 
chiave.
-- 
Gabriele "moebius" Armao
Undergraduate student in Computer Science @ University of Bologna
ICQ#: 12132670  JabberID: 
n...@jabber.students.cs.unibo.it
Linux Registered User # 343306

 Visto che è sicuramente evitabile preferirei evitare.
C'e' nulla nei log del server? In ogni caso:
1) sul server:
   $ /usr/sbin/sshd -d -p <quel che vuoi>
2) sul client:
   $ ssh -v -p <quella sopra> <server>
3) analizzare i log, cercare con google e chiedere in caso di 
   dubbi residui :-)
Fabio

 Fabio
Grazie mille.
Luca

 un'altra soluzione sulla condivisione (ma questa è di tipo organizzativo).
StrictModes no ;-)
Fabio

 tipo organizzativo).
ehm_e_ehm_ehem... non avevi detto di aver controllato tutto e confrontato 
con altro server dove funzionava?
In effetti, ho controllato e ha proprio ragione bio:
 StrictModes
         Specifies whether sshd(8) should check file modes and ownership
         of the user's files and home directory before accepting login.
         This is normally desirable because novices sometimes accidentally
         leave their directory or files world-writable.  The default is
         ``yes''.


 
Adesso provo anche questo.
Grazie a tutti per le info.
Luca

 C'e' nulla nei log del server? In ogni caso:
vi sottopongo anche il mio problema, simile a quello indicato anche se non 
identico
ho impostato ssh sul pc server per permettermi l'accesso unicamente 
tramite chiave rsa
portata la chiave pubblica che ho generato sul server inizialmente(per un 
mesetto) nessun problema
poi un giorno ha smesso di funzionare
ho pensato che fosse in qualche modo scaduta, ne ho generata un altra, 
portata sempre sul server, ma ancora rifiuta la connessione
ssh -vl user -p 2000 indirizzoIp
OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to indirizzoIp [indirizzoIp] port 2000.
debug1: Connection established.
debug1: identity file /home/bladela/.ssh/id_rsa type 1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3p2 
Debian-9
debug1: match: OpenSSH_4.3p2 Debian-9 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '87.28.236.113' is known and matches the RSA host key.
debug1: Found key in /home/bladela/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: password
debug1: No more authentication methods to try.
Permission denied (password).
stranamente come vedete tenta unicamente l'accesso tramite password, ma 
in .ssh esiste la chiave privata
 ls -l .ssh
totale 16
-rw------- 1 bladela bladela 1743 24 mag 22:36 id_rsa
-rw------- 1 bladela bladela  276 25 mag 18:53 known_hosts
e ssh sul client(fedora core 6) è impostato come segue
<config ssh>
# Host *
#   ForwardAgent no
#   ForwardX11 no
   RhostsRSAAuthentication yes
   RSAAuthentication yes
   PasswordAuthentication no
#   HostbasedAuthentication no
#   BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking no
#   IdentityFile ~/.ssh/identity
   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   Port 22
#   Protocol 2,1
#   Cipher 3des
#   Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-
cbc,aes256-cbc
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
Host *
        GSSAPIAuthentication yes
# If this option is set to yes then remote X11 clients will have full 
access
# to the original X11 display. As virtually no X11 client supports the 
untrusted
# mode correctly we set this to yes.
        ForwardX11Trusted yes
# Send locale-related environment variables
        SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY 
LC_MESSAGES 
        SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT 
        SendEnv LC_IDENTIFICATION LC_ALL
</config ssh>
ho provato da un'altra macchina della rete a fare la stessa procedura ed 
ha funzionato benissimo, quindi sono portato a pensare che il problema 
stia su ssh di fedora
vedete qualcosa di strano? io purtroppo no :(
chiaramente da prima ad adesso non ho modificato nulla
ho provato anche a impostare i diritti come da voi detto nei post 
precedenti senza risultato
grazie per ogni suggerimento
ciao
BLADELA
-- 
"...to bodly go where Chuck Norris already kicked some asses before"

 BLADELA
Per trovare il mio problema, ho lanciato il debug sul demone.
Senza fermare il demone in esecuzione (ero a casa e il server in ufficio) ho 
lanciato
sshd -d -p 7682
e sul pc
ssh mioutente@mioserver -p 7682
Guardando sul server ho visto che ignorava bellamente il file authorized_keys 
per via dei permessi.
Prova a lanciare il server in debug e a guardare cosa ti dice.
Luca

 
anche se lanci "/etc/init.d/sshd restart" non ti butta mai fuori.
Provato mille volte (sempre con un po' di patema d'animo) ma mi ha sempre 
lasciato loggato.
E' sufficiente aggiungere la riga: 
LogLevel DEBUG3 (o DEBUG2, DEBUG1, DEBUG)
e riavviare il demone.


 LogLevel DEBUG3 (o DEBUG2, DEBUG1, DEBUG) e riavviare il demone.
attivo subito il backup, ma essendo fedora sul pc di casa non potrò 
provare che stasera, quindi tra stasera e domani vi dirò cosa mi 
visualizza
ciao
BLADELA
-- 
"Resistance is Chuck Norris"

 LogLevel DEBUG3 (o DEBUG2, DEBUG1, DEBUG) e riavviare il demone.
ho ritestato dall'interno della rete e la connessione va come detto a 
buon fine
posto i log della connessione :
<log>
Jun 14 14:57:25 AthlonXP sshd[3562]: Connection from 192.168.1.5 port 
49567
Jun 14 14:57:25 AthlonXP sshd[3562]: debug1: Client protocol version 2.0; 
client software version OpenSSH_4.3p2 Debian-9
Jun 14 14:57:25 AthlonXP sshd[3562]: debug1: match: OpenSSH_4.3p2 
Debian-9 pat OpenSSH*
Jun 14 14:57:25 AthlonXP sshd[3562]: debug1: Enabling compatibility mode 
for protocol 2.0
Jun 14 14:57:25 AthlonXP sshd[3562]: debug1: Local version string SSH-2.0-
OpenSSH_4.3p2 Debian-9
Jun 14 14:57:25 AthlonXP sshd[3562]: debug2: fd 3 setting O_NONBLOCK
Jun 14 14:57:25 AthlonXP sshd[3562]: debug2: Network child is on pid 3563
Jun 14 14:57:25 AthlonXP sshd[3562]: debug3: preauth child monitor started
Jun 14 14:57:25 AthlonXP sshd[3562]: debug3: mm_request_receive entering
Jun 14 14:57:25 AthlonXP sshd[3562]: debug3: monitor_read: checking 
request 0
Jun 14 14:57:25 AthlonXP sshd[3562]: debug3: mm_answer_moduli: got 
parameters: 1024 1024 8192
Jun 14 14:57:25 AthlonXP sshd[3562]: debug3: mm_request_send entering: 
type 1
Jun 14 14:57:25 AthlonXP sshd[3562]: debug2: monitor_read: 0 used once, 
disabling now
Jun 14 14:57:25 AthlonXP sshd[3562]: debug3: mm_request_receive entering
Jun 14 14:57:25 AthlonXP sshd[3562]: debug3: monitor_read: checking 
request 5
Jun 14 14:57:25 AthlonXP sshd[3562]: debug3: mm_answer_sign
Jun 14 14:57:25 AthlonXP sshd[3562]: debug3: mm_answer_sign: signature 
0x80a70d8(271)
Jun 14 14:57:25 AthlonXP sshd[3562]: debug3: mm_request_send entering: 
type 6
Jun 14 14:57:25 AthlonXP sshd[3562]: debug2: monitor_read: 5 used once, 
disabling now
Jun 14 14:57:25 AthlonXP sshd[3562]: debug3: mm_request_receive entering
Jun 14 14:57:25 AthlonXP sshd[3562]: debug3: monitor_read: checking 
request 7
Jun 14 14:57:25 AthlonXP sshd[3562]: debug3: mm_answer_pwnamallow
Jun 14 14:57:25 AthlonXP sshd[3562]: debug3: auth_shadow_acctexpired: 
today 13678 sp_expire -1 days left -13679
Jun 14 14:57:25 AthlonXP sshd[3562]: debug3: account expiration disabled
Jun 14 14:57:25 AthlonXP sshd[3562]: debug3: mm_answer_pwnamallow: 
sending MONITOR_ANS_PWNAM: 1
Jun 14 14:57:25 AthlonXP sshd[3562]: debug3: mm_request_send entering: 
type 8
Jun 14 14:57:25 AthlonXP sshd[3562]: debug2: monitor_read: 7 used once, 
disabling now
Jun 14 14:57:25 AthlonXP sshd[3562]: debug3: mm_request_receive entering
Jun 14 14:57:25 AthlonXP sshd[3562]: debug3: monitor_read: checking 
request 3
Jun 14 14:57:25 AthlonXP sshd[3562]: debug3: mm_answer_authserv: 
service=ssh-connection, style=, role=
Jun 14 14:57:25 AthlonXP sshd[3562]: debug2: monitor_read: 3 used once, 
disabling now
Jun 14 14:57:25 AthlonXP sshd[3562]: debug3: mm_request_receive entering
Jun 14 14:57:25 AthlonXP sshd[3562]: debug3: monitor_read: checking 
request 9
Jun 14 14:57:25 AthlonXP sshd[3562]: debug3: mm_request_send entering: 
type 10
Jun 14 14:57:25 AthlonXP sshd[3562]: debug2: monitor_read: 9 used once, 
disabling now
Jun 14 14:57:25 AthlonXP sshd[3562]: debug3: mm_request_receive entering
Jun 14 14:57:25 AthlonXP sshd[3562]: debug3: monitor_read: checking 
request 21
Jun 14 14:57:25 AthlonXP sshd[3562]: debug3: mm_answer_keyallowed entering
Jun 14 14:57:25 AthlonXP sshd[3562]: debug3: mm_answer_keyallowed: 
key_from_blob: 0x80a7208
Jun 14 14:57:25 AthlonXP sshd[3562]: debug1: temporarily_use_uid: 
1000/1000 (e=0/0)
Jun 14 14:57:25 AthlonXP sshd[3562]: debug1: trying public key file /home/
operatore/.ssh/authorized_keys
Jun 14 14:57:25 AthlonXP sshd[3562]: debug1: matching key found: file /
home/operatore/.ssh/authorized_keys, line 2
Jun 14 14:57:25 AthlonXP sshd[3562]: Found matching RSA key: 
15:0b:cf:bc:2c:3f:3e:ab:56:44:c1:45:df:b1:59:f0
Jun 14 14:57:25 AthlonXP sshd[3562]: debug1: restore_uid: 0/0
Jun 14 14:57:25 AthlonXP sshd[3562]: debug3: mm_answer_keyallowed: key 
0x80a7208 is allowed
Jun 14 14:57:25 AthlonXP sshd[3562]: debug3: mm_request_send entering: 
type 22
Jun 14 14:57:25 AthlonXP sshd[3562]: debug3: mm_request_receive entering
Jun 14 14:57:27 AthlonXP sshd[3562]: debug3: monitor_read: checking 
request 21
Jun 14 14:57:27 AthlonXP sshd[3562]: debug3: mm_answer_keyallowed entering
Jun 14 14:57:27 AthlonXP sshd[3562]: debug3: mm_answer_keyallowed: 
key_from_blob: 0x80a7228
Jun 14 14:57:27 AthlonXP sshd[3562]: debug1: temporarily_use_uid: 
1000/1000 (e=0/0)
Jun 14 14:57:27 AthlonXP sshd[3562]: debug1: trying public key file /home/
operatore/.ssh/authorized_keys
Jun 14 14:57:27 AthlonXP sshd[3562]: debug1: matching key found: file /
home/operatore/.ssh/authorized_keys, line 2
Jun 14 14:57:27 AthlonXP sshd[3562]: Found matching RSA key: 
15:0b:cf:bc:2c:3f:3e:ab:56:44:c1:45:df:b1:59:f0
Jun 14 14:57:27 AthlonXP sshd[3562]: debug1: restore_uid: 0/0
Jun 14 14:57:27 AthlonXP sshd[3562]: debug3: mm_answer_keyallowed: key 
0x80a7228 is allowed
Jun 14 14:57:27 AthlonXP sshd[3562]: debug3: mm_request_send entering: 
type 22
Jun 14 14:57:27 AthlonXP sshd[3562]: debug3: mm_request_receive entering
Jun 14 14:57:27 AthlonXP sshd[3562]: debug3: monitor_read: checking 
request 23
Jun 14 14:57:27 AthlonXP sshd[3562]: debug1: ssh_rsa_verify: signature 
correct
Jun 14 14:57:27 AthlonXP sshd[3562]: debug3: mm_answer_keyverify: key 
0x80a7218 signature verified
Jun 14 14:57:27 AthlonXP sshd[3562]: debug3: mm_request_send entering: 
type 24
Jun 14 14:57:27 AthlonXP sshd[3562]: debug3: Normalising mapped IPv4 in 
IPv6 address
Jun 14 14:57:27 AthlonXP sshd[3562]: Accepted publickey for operatore 
from 192.168.1.5 port 49567 ssh2
Jun 14 14:57:27 AthlonXP sshd[3562]: debug1: monitor_child_preauth: 
operatore has been authenticated by privileged process
Jun 14 14:57:27 AthlonXP sshd[3562]: debug3: mm_get_keystate: Waiting for 
new keys
Jun 14 14:57:27 AthlonXP sshd[3562]: debug3: mm_request_receive_expect 
entering: type 25
Jun 14 14:57:27 AthlonXP sshd[3562]: debug3: mm_request_receive entering
Jun 14 14:57:27 AthlonXP sshd[3562]: debug3: mm_newkeys_from_blob: 
0x80a8408(118)
Jun 14 14:57:27 AthlonXP sshd[3562]: debug2: mac_init: found hmac-md5
Jun 14 14:57:27 AthlonXP sshd[3562]: debug3: mm_get_keystate: Waiting for 
second key
Jun 14 14:57:27 AthlonXP sshd[3562]: debug3: mm_newkeys_from_blob: 
0x80a8408(118)
Jun 14 14:57:27 AthlonXP sshd[3562]: debug2: mac_init: found hmac-md5
Jun 14 14:57:27 AthlonXP sshd[3562]: debug3: mm_get_keystate: Getting 
compression state
Jun 14 14:57:27 AthlonXP sshd[3562]: debug3: mm_get_keystate: Getting 
Network I/O buffers
Jun 14 14:57:27 AthlonXP sshd[3562]: debug3: mm_share_sync: Share sync
Jun 14 14:57:27 AthlonXP sshd[3562]: debug3: mm_share_sync: Share sync end
Jun 14 14:57:27 AthlonXP sshd[3564]: debug1: permanently_set_uid: 
1000/1000
Jun 14 14:57:27 AthlonXP sshd[3562]: debug2: User child is on pid 3564
Jun 14 14:57:27 AthlonXP sshd[3562]: debug3: mm_request_receive entering
Jun 14 14:57:27 AthlonXP sshd[3564]: debug2: set_newkeys: mode 0
Jun 14 14:57:27 AthlonXP sshd[3564]: debug2: set_newkeys: mode 1
Jun 14 14:57:27 AthlonXP sshd[3564]: debug1: Entering interactive session 
for SSH2.
Jun 14 14:57:27 AthlonXP sshd[3564]: debug2: fd 5 setting O_NONBLOCK
Jun 14 14:57:27 AthlonXP sshd[3564]: debug2: fd 6 setting O_NONBLOCK
Jun 14 14:57:27 AthlonXP sshd[3564]: debug1: server_init_dispatch_20
Jun 14 14:57:27 AthlonXP sshd[3564]: debug1: server_input_channel_open: 
ctype session rchan 0 win 65536 max 16384
Jun 14 14:57:27 AthlonXP sshd[3564]: debug1: input_session_request
Jun 14 14:57:27 AthlonXP sshd[3564]: debug1: channel 0: new [server-
session]
Jun 14 14:57:27 AthlonXP sshd[3564]: debug1: session_new: init
Jun 14 14:57:27 AthlonXP sshd[3564]: debug1: session_new: session 0
Jun 14 14:57:27 AthlonXP sshd[3564]: debug1: session_open: channel 0
Jun 14 14:57:27 AthlonXP sshd[3564]: debug1: session_open: session 0: 
link with channel 0
Jun 14 14:57:27 AthlonXP sshd[3564]: debug1: server_input_channel_open: 
confirm session
Jun 14 14:57:27 AthlonXP sshd[3564]: debug1: server_input_channel_req: 
channel 0 request pty-req reply 0
Jun 14 14:57:27 AthlonXP sshd[3564]: debug1: session_by_channel: session 
0 channel 0
Jun 14 14:57:27 AthlonXP sshd[3564]: debug1: session_input_channel_req: 
session 0 req pty-req
Jun 14 14:57:27 AthlonXP sshd[3564]: debug1: Allocating pty.
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: mm_request_send entering: 
type 26
Jun 14 14:57:27 AthlonXP sshd[3562]: debug3: monitor_read: checking 
request 26
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: mm_pty_allocate: waiting for 
MONITOR_ANS_PTY
Jun 14 14:57:27 AthlonXP sshd[3562]: debug3: mm_answer_pty entering
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: mm_request_receive_expect 
entering: type 27
Jun 14 14:57:27 AthlonXP sshd[3562]: debug1: session_new: init
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: mm_request_receive entering
Jun 14 14:57:27 AthlonXP sshd[3562]: debug1: session_new: session 0
Jun 14 14:57:27 AthlonXP sshd[3562]: debug3: Normalising mapped IPv4 in 
IPv6 address
Jun 14 14:57:27 AthlonXP sshd[3562]: debug3: Trying to reverse map 
address 192.168.1.5.
Jun 14 14:57:27 AthlonXP sshd[3562]: debug3: mm_request_send entering: 
type 27
Jun 14 14:57:27 AthlonXP sshd[3562]: debug3: mm_answer_pty: tty /dev/
pts/2 ptyfd 4
Jun 14 14:57:27 AthlonXP sshd[3562]: debug3: mm_request_receive entering
Jun 14 14:57:27 AthlonXP sshd[3564]: debug1: session_pty_req: session 0 
alloc /dev/pts/2
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: SSH2 
n_bytes 256
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: ospeed 38400
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: ispeed 38400
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 1 3
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 2 28
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 3 127
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 4 21
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 5 4
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 6 0
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 7 0
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 8 17
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 9 19
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 10 26
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 12 18
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 13 23
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 14 22
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 18 15
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 30 0
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 31 0
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 32 0
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 33 0
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 34 0
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 35 0
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 36 1
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 37 0
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 38 1
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 39 1
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 40 0
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 41 1
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 50 1
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 51 1
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 52 0
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 53 1
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 54 1
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 55 1
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 56 0
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 57 0
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 58 0
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 59 1
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 60 1
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 61 1
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 62 0
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 70 1
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 71 0
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 72 1
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 73 0
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 74 0
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 75 0
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 90 1
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 91 1
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 92 0
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: tty_parse_modes: 93 0
Jun 14 14:57:27 AthlonXP sshd[3564]: debug1: server_input_channel_req: 
channel 0 request env reply 0
Jun 14 14:57:27 AthlonXP sshd[3564]: debug1: session_by_channel: session 
0 channel 0
Jun 14 14:57:27 AthlonXP sshd[3564]: debug1: session_input_channel_req: 
session 0 req env
Jun 14 14:57:27 AthlonXP sshd[3564]: debug2: Setting env 0: 
LANG=it_IT@euro
Jun 14 14:57:27 AthlonXP sshd[3564]: debug1: server_input_channel_req: 
channel 0 request shell reply 0
Jun 14 14:57:27 AthlonXP sshd[3564]: debug1: session_by_channel: session 
0 channel 0
Jun 14 14:57:27 AthlonXP sshd[3564]: debug1: session_input_channel_req: 
session 0 req shell
Jun 14 14:57:27 AthlonXP sshd[3565]: debug1: Setting controlling tty 
using TIOCSCTTY.
Jun 14 14:57:27 AthlonXP sshd[3564]: debug2: fd 3 setting TCP_NODELAY
Jun 14 14:57:27 AthlonXP sshd[3564]: debug2: channel 0: rfd 8 isatty
Jun 14 14:57:27 AthlonXP sshd[3564]: debug2: fd 8 setting O_NONBLOCK
Jun 14 14:57:27 AthlonXP sshd[3564]: debug3: fd 7 is O_NONBLOCK
Jun 14 14:57:27 AthlonXP sshd[3565]: debug3: Normalising mapped IPv4 in 
IPv6 address
Jun 14 14:57:27 AthlonXP sshd[3565]: debug3: channel 0: close_fds r -1 w 
-1 e -1 c -1


 LogLevel DEBUG3 (o DEBUG2, DEBUG1, DEBUG) e riavviare il demone.
questa è bella...tentando da fedora...il server non logga alcun tentativo 
di accesso...
ho fatto il tentativo alle 19:59 ma in auth.log ho questo :
<auth.log>
Jun 13 19:17:01 AthlonXP CRON[16628]: (pam_unix) session opened for user 
root by (uid=0)
Jun 13 19:17:01 AthlonXP CRON[16628]: (pam_unix) session closed for user 
root
Jun 13 20:02:01 AthlonXP CRON[16631]: (pam_unix) session opened for user 
root by (uid=0)
Jun 13 20:02:01 AthlonXP CRON[16631]: (pam_unix) session closed for user 
root
Jun 13 20:17:01 AthlonXP CRON[16633]: (pam_unix) session opened for user 
root by (uid=0)
</auth.log>
ora ho anche a disposizione(in precedenza...mel'ero spedita via mail...ma 
all'indirizzo sbagliato ^_^) la configurazione del server sshd
<sshd_config>
# Package generated configuration file
# See the sshd(8) manpage for details
# What ports, IPs and protocols we listen for
Port 2000
# Use these options to restrict which interfaces/protocols sshd will bind 
to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes
# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768
# Logging
SyslogFacility AUTH
LogLevel INFO
# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes no
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile	%h/.ssh/authorized_keys
# 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_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for 
RhostsRSAAuthentication
#IgnoreUserKnownHosts yes
# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no
# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
X11Forwarding no
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
#MaxStartups 10:30:60
Banner /etc/
issue.net
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
#UsePAM no
<sshd_config>
premetto che a parte l'impostazione dei log, la configurazione come ho 
detto non è cambiata
non so che pesci pigliare...


 non so che pesci pigliare...
ok, lasciate pure perdere...si era incrocchiato il router telecom...
segno sull'agenda : CAMBIARE ROUTER!!!
dovevo controllarlo prima(ma internet nella rete locale funzionava 
regolarmente...così come l'smtp...)
scusate per il "rumore" generato nel NG(alla fine era roba da ICOLI ^_^)
