Non accetta più le authorized_keys per ssh
pac
scusate ma non mi pareva neppure una richiesta OT.
Improvvisamente questo server non accetta più le chiavi per la
connessione e conseguentemente richiede la password.
Le chiavi risultano integre, così come i file di configurazione.
Pazienza, rigenero le chiavi. Il problema non si risolve. Cosa può
esser successo e cosa si può fare ?
--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-ital...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listm...@lists.debian.org
To UNSUBSCRIBE, email to debian-ital...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Luigi di Lazzaro
Ciao,
> Premetto che stiamo parlando di un server Fedora 3 e non debian,
> scusate ma non mi pareva neppure una richiesta OT.
> Improvvisamente questo server non accetta più le chiavi per la
> connessione e conseguentemente richiede la password.
> Le chiavi risultano integre, così come i file di configurazione.
> Pazienza, rigenero le chiavi. Il problema non si risolve.
Riavviato ssh? (Quasi certamente)
Nel log non trovi nulla?
Luigi
pac
> On Monday 06 July 2009 18:50:38 pac wrote:
> Ciao,
>
>> Premetto che stiamo parlando di un server Fedora 3 e non debian,
>> scusate ma non mi pareva neppure una richiesta OT.
>> Improvvisamente questo server non accetta più le chiavi per la
>> connessione e conseguentemente richiede la password.
>> Le chiavi risultano integre, così come i file di configurazione.
>> Pazienza, rigenero le chiavi. Il problema non si risolve.
>
> Riavviato ssh? (Quasi certamente)
> Nel log non trovi nulla?
debug: Connecting to 10.33.0.99, port 22...
debug: Ssh2/ssh2.c:1956/main: Entering event loop.
debug: Ssh2Client/sshclient.c:1328/ssh_client_wrap: Creating transport protocol.
debug: SshAuthMethodClient/sshauthmethodc.c:137/ssh_client_authentication_initialize:
Added "publickey" to usable methods.
debug: SshAuthMethodClient/sshauthmethodc.c:137/ssh_client_authentication_initialize:
Added "password" to usable methods.
debug: Ssh2Client/sshclient.c:1360/ssh_client_wrap: Creating userauth protocol.
debug: client supports 2 auth methods: 'publickey,password'
debug: Ssh2Common/sshcommon.c:496/ssh_common_wrap: local ip =
10.33.0.100, local port = 32822
debug: Ssh2Common/sshcommon.c:498/ssh_common_wrap: remote ip =
10.33.0.99, remote port = 22
debug: SshConnection/sshconn.c:1889/ssh_conn_wrap: Wrapping...
debug: Remote version: SSH-1.99-OpenSSH_3.9p1
debug: Ssh2Transport/trcommon.c:1373/ssh_tr_input_version: Remote
version has rekey incompatibility bug.
debug: Ssh2Transport/trcommon.c:1376/ssh_tr_input_version: Remote
version is OpenSSH, KEX guesses disabled.
debug: Ssh2Transport/trcommon.c:1717/ssh_tr_negotiate: lang s to c:
`', lang c to s: `'
debug: Ssh2Transport/trcommon.c:1783/ssh_tr_negotiate: c_to_s: cipher
aes128-cbc, mac hmac-sha1, compression none
debug: Ssh2Transport/trcommon.c:1786/ssh_tr_negotiate: s_to_c: cipher
aes128-cbc, mac hmac-sha1, compression none
debug: Remote host key found from database.
debug: Ssh2Common/sshcommon.c:291/ssh_common_special: Received
SSH_CROSS_STARTUP packet from connection protocol.
debug: Ssh2Common/sshcommon.c:341/ssh_common_special: Received
SSH_CROSS_ALGORITHMS packet from connection protocol.
debug: server offers auth methods 'publickey,gssapi-with-mic,password'.
debug: SshConfig/sshconfig.c:2184/ssh2_parse_config: Unable to open
/home/roberta/.ssh2/identification
debug: Ssh2AuthClient/sshauthc.c:316/ssh_authc_completion_proc: Method
'publickey' disabled.
debug: server offers auth methods 'publickey,gssapi-with-mic,password'.
debug: Ssh2AuthPasswdClient/authc-passwd.c:98/ssh_client_auth_passwd:
Starting password query...
Di cui ho provato ad abilitare Method publickey e pure a creare ssh2
poi riavviato ma non è cambiato nulla e comunque prima funzionava
benissimo senza queste "opzioni" modificate
Intanto grazie
Luigi di Lazzaro
Ciao,
> > Nel log non trovi nulla?
>
> Con ssh -v trovo
> SshConfig/sshconfig.c:2184/ssh2_parse_config: Unable to open
> /home/roberta/.ssh2/identification
Questo mi sembra strano.
La chiave non dovrebbe essere in /.ssh/authorized_keys?
Hai cambiato la posizione della chiave nel file di configurazione?
> debug: Ssh2AuthClient/sshauthc.c:316/ssh_authc_completion_proc:
> Method 'publickey' disabled.
Lo capisco cosi':
siccome non riesce ad aprire il file /home/roberta/.ssh2/identification
disabilta il metodo publickey.
Tu che ne pensi?
Luigi
pac
qualche misterioso motivo nell'utente è stata creata la directory
.ssh2 con la directory hostkeys e il file random_seed
Così come alla stessa data trovo in /etc/ssh2
Il tutto come se fosse stato installato ssh 2 tieni presente che il
client di cui stiamo parlando è una vecchia distro RH 8 e quindi ....
OK comunque nulla è stato installato, però in quei giorni si sono
collegati client che utilizzavano ssh2 esattamente debian lenny.
Non capisco cosa sia successo e come sistemare il tutto.
Se cancello .ssh2 mi chiede
Host key not found from database.
Key fingerprint:
xitad-tutiv-kypuz-kalam-bobok-cigam-kylev-degiz-borup-lyzob-daxyx
You can get a public key's fingerprint by running
% ssh-keygen -F publickey.pub
on the keyfile.
A parte che ssh-keygen -F mi restituisce parametro inesistente, ssh2
sul server non c'è proprio e non c'è mai stata
Ora dovrei scoprire come fare a sistemare il tutto
Luigi di Lazzaro
[ssh no publickey]
> ho provato a cercare e ho scoperto che il giorno 02.07.09 per
> qualche misterioso motivo nell'utente è stata creata la directory
> .ssh2 con la directory hostkeys e il file random_seed
> Così come alla stessa data trovo in /etc/ssh2
> Il tutto come se fosse stato installato ssh 2 tieni presente che il
> client di cui stiamo parlando è una vecchia distro RH 8 e quindi ....
> OK comunque nulla è stato installato, però in quei giorni si sono
> collegati client che utilizzavano ssh2 esattamente debian lenny.
> Non capisco cosa sia successo e come sistemare il tutto.
> Se cancello .ssh2 mi chiede
>
> Host key not found from database.
> Key fingerprint:
> xitad-tutiv-kypuz-kalam-bobok-cigam-kylev-degiz-borup-lyzob-daxyx
> You can get a public key's fingerprint by running
> % ssh-keygen -F publickey.pub
> on the keyfile.
> A parte che ssh-keygen -F mi restituisce parametro inesistente, ssh2
> sul server non c'è proprio e non c'è mai stata
>
> Ora dovrei scoprire come fare a sistemare il tutto
Non sono sicuro di aver capito bene:
sul client e' installata la RH 8
sul server probabilmente debian (etch?)
Hai provato a collegarti al server con un altro client?
Luigi
pac
Client che non riesce a collegarsi più con la key RH 8
Su questo client non è mai esistito ssh2 ora troviamo /etc/ssh2 e pure ~/.ssh2
Ho una vecchia copia infatti in cui queste directory non esistevano
Questa improvvisa nascita di directory ssh2 e contemporaneamente la
impossibilità di utilizzare le autorized_keys mi fa pensare (non so in
che modo) che sia coinvolto il fatto che proprio in questi tempi due
pc (uno da remoto ed uno in rete locale) hanno iniziato a collegarsi
al RH8 con PC su cui è installata Debian Lenny 5.0
Altro non mi viene in mente
bod...@mail.dm.unipi.it
> ho provato a cercare e ho scoperto che il giorno 02.07.09 per
> qualche misterioso motivo nell'utente � stata creata la directory .ssh2
con la directory hostkeys e il file random_seed
A proposito di misteriosi motivi... non ho ben capito se ritieni che il
problema sia il server o il client.
Se pero` di colpo il client ha cominciato a non usare piu'
l'autenticazione con le chiavi e a richiederti _sempre_ di inserire le
password, c'e` un'altra possibilita` da investigare: che sia stato messo
un cavallo di Troia (troyan) al posto dell'ssh.
Dico questo perche' alcuni anni or sono era un metodo direi abbastanza
diffuso per carpire password agli utenti, modificare ssh in modo che
salvasse/spedisse le password digitate; ovviamente la versione modificata
di ssh richiedeva _sempre_ di inserire la password, anche se
l'autenticazione con modalita` diverse era disponibile.
Un controllino in piu', non guasta.
Ciau,
m
pac
> Ciao a tutti,
>
>> ho provato a cercare e ho scoperto che il giorno 02.07.09 per
> con la directory hostkeys e il file random_seed
>
> A proposito di misteriosi motivi... non ho ben capito se ritieni che il
> problema sia il server o il client.
>
> Se pero` di colpo il client ha cominciato a non usare piu'
> l'autenticazione con le chiavi e a richiederti _sempre_ di inserire le
> password, c'e` un'altra possibilita` da investigare: che sia stato messo
> un cavallo di Troia (troyan) al posto dell'ssh.
> Dico questo perche' alcuni anni or sono era un metodo direi abbastanza
> diffuso per carpire password agli utenti, modificare ssh in modo che
> salvasse/spedisse le password digitate; ovviamente la versione modificata
> di ssh richiedeva _sempre_ di inserire la password, anche se
> l'autenticazione con modalita` diverse era disponibile.
>
> Un controllino in piu', non guasta.
>
> Ciau,
> m
>
> --
riportano tutt'ora stesso timestamp, capisco che potrebbe non
significare nulla, ma direi di esser sicuro al 99%
pac
>
>> Client che non riesce a collegarsi più con la key RH 8
>> Su questo client non è mai esistito ssh2 ora troviamo /etc/ssh2 e pure
>> ~/.ssh2
>> Ho una vecchia copia infatti in cui queste directory non esistevano
>>
>> Questa improvvisa nascita di directory ssh2 e contemporaneamente la
>> impossibilità di utilizzare le autorized_keys mi fa pensare (non so in
>
> nell'invio... a me questa improvvisa nascita di directory mi fa pensare a
> un troyan, un ssh fasullo infilato "ad hoc", che chiede sempre le
> password... perche' sono proprio le password che quell'ssh fasullo vuole
> raccogliere.
>
> Ciau,
> m
>
> --
> http://bodrato.it/papers/
>
>
> --
Come faresti per fare un controllo certo ?
bod...@mail.dm.unipi.it
> Client che non riesce a collegarsi pi� con la key RH 8
> Su questo client non � mai esistito ssh2 ora troviamo /etc/ssh2 e pure
> ~/.ssh2
> Ho una vecchia copia infatti in cui queste directory non esistevano
>
> Questa improvvisa nascita di directory ssh2 e contemporaneamente la
Lo ridico perche' mi sa che nella mail di prima ho fatto qualche pasticcio
nell'invio... a me questa improvvisa nascita di directory mi fa pensare a
un troyan, un ssh fasullo infilato "ad hoc", che chiede sempre le
password... perche' sono proprio le password che quell'ssh fasullo vuole
raccogliere.
Ciau,
m
pac
> Il giorno 07 Luglio 2009 14.31, <bod...@mail.dm.unipi.it> ha scritto:
>>
>>> Client che non riesce a collegarsi più con la key RH 8
>>> Su questo client non è mai esistito ssh2 ora troviamo /etc/ssh2 e pure
>>> ~/.ssh2
>>> Ho una vecchia copia infatti in cui queste directory non esistevano
>>>
>>> Questa improvvisa nascita di directory ssh2 e contemporaneamente la
>>> impossibilità di utilizzare le autorized_keys mi fa pensare (non so in
>>
>> Lo ridico perche' mi sa che nella mail di prima ho fatto qualche pasticcio
>> nell'invio... a me questa improvvisa nascita di directory mi fa pensare a
>> un troyan, un ssh fasullo infilato "ad hoc", che chiede sempre le
>> password... perche' sono proprio le password che quell'ssh fasullo vuole
>> raccogliere.
>>
>> Ciau,
>> m
>>
>> --
>> http://bodrato.it/papers/
>>
>>
>> --
>
copie ed anche a sshd di un vecchio pc anch'esso con RH8 che si trova
invece a casa mia. Direi che siamo tranquilli
bod...@mail.dm.unipi.it
> Con md5sum di sshd su init.d ho un risultato identico alle vecchie
> copie ed anche a sshd di un vecchio pc anch'esso con RH8 che si trova
> invece a casa mia. Direi che siamo tranquilli
Ottimi indizi, ma io controllerei /usr/bin/ssh sul client. Ed
eventualmente proverei a copiare sullo stesso client un eseguibile in
~/bin/altro_ssh, provando poi a lanciare quello.
Se non e` un cavallo di Troia, tanto meglio, ma in ogni caso mi sembra
davvero bizzarro che se c'e` un server A e sue client B e C, un qualunque
comportamento di B possa creare directory _di_sistema_ come /etc/ssh2 sul
client C.
Facci sapere,
m
--
http://bodrato.it/software/
pac
> Ciau,
>
>> Con md5sum di sshd su init.d ho un risultato identico alle vecchie
>> copie ed anche a sshd di un vecchio pc anch'esso con RH8 che si trova
>> invece a casa mia. Direi che siamo tranquilli
>
> Ottimi indizi, ma io controllerei /usr/bin/ssh sul client. Ed
> eventualmente proverei a copiare sullo stesso client un eseguibile in
> ~/bin/altro_ssh, provando poi a lanciare quello.
> Se non e` un cavallo di Troia, tanto meglio, ma in ogni caso mi sembra
> davvero bizzarro che se c'e` un server A e sue client B e C, un qualunque
> comportamento di B possa creare directory _di_sistema_ come /etc/ssh2 sul
> client C.
>
> Facci sapere,
> m
>
> --
> http://bodrato.it/software/
Il problema ora è il seguente, ho avuto la brillante idea di
cancellare /etc/ssh2 questo mi impedisce in pratica di restartare ssh
ho copiato tutti i file ssh ssh-add ssh-keygen etc al posto dei
vecchi, ho cambiato la porta di ssh, ma purtroppo mi dà sempre questo
assurdo errore :
Interruzione di sshd: [FALLITO]
Avvio di sshd:sshd: WARNING: Default configuration file
"/etc/ssh2/sshd2_config" does not exist.
: OpenSSH_3.4p1 on i686-pc-linux-gnu
: WARNING: ssh_privkey_read from /etc/ssh2/hostkey failed.
: FATAL: Unable to load any hostkeys
[FALLITO]
Perché cerca la ss2 che io ho cancellato.
Perché ho fatto sta c...ta ?
Perché visto quello che tu dici anche se non sembra avevo pensato di
dare per scontata un'intrusione
Comunque come posso fare ?
pac
Allora per non saper ne legger ne scrivere ho reinstallato i vari
openssh e a questo punto riesco a restartartare sshd
il problema mi rimane su ssh-keygen il quale nonostante lo abbia
sostituito e reinstallato mi crea nella home una .ssh2
che dici apro un nuovo thread ?
Luigi di Lazzaro
Ciao,
> Allora per non saper ne legger ne scrivere ho reinstallato i vari
> openssh e a questo punto riesco a restartartare sshd
> il problema mi rimane su ssh-keygen il quale nonostante lo abbia
> sostituito e reinstallato mi crea nella home una .ssh2
> che dici apro un nuovo thread ?
Non direi, la soluzione interessa sicuramente molti lettori.
Forse per venirne a capo converrebbe fare qualche prova con un altro
client, tanto per capire con certezza se l'inghippo sta sul client o sul
server. Hai questa possibilita'?
Luigi
pac
> On Tuesday 07 July 2009 17:07:23 pac wrote:
> Ciao,
>
>
>> Allora per non saper ne legger ne scrivere ho reinstallato i vari
>> openssh e a questo punto riesco a restartartare sshd
>> il problema mi rimane su ssh-keygen il quale nonostante lo abbia
>> sostituito e reinstallato mi crea nella home una .ssh2
>> che dici apro un nuovo thread ?
> Non direi, la soluzione interessa sicuramente molti lettori.
> Forse per venirne a capo converrebbe fare qualche prova con un altro
> client, tanto per capire con certezza se l'inghippo sta sul client o sul
> server. Hai questa possibilita'?
> Luigi
>
>
Sono stati installati una serie di file in /usr/local/bin quali
ssh-keygen ed affini e questi venivano utilizzati al posto di quelli
ufficiali.
Ora il discorso è il seguente.
Ho reinstallato, cancellato questi file, sostituiti i file di
configurazione di /etc/ssh e cancellato le varie directory ssh2 (sto
comunque cercando ancora residui)
Quello che mi domando è dove diceva al sistema di usare /usr/local/bin
anzichè /usr/bin ?
Come posso fare per difendere un indirizzo pubblico che ha un accesso
ssh oltre a cambiare porta ?
Cosa posso controllare ancora ?
pac
Luigi di Lazzaro
Ciao,
> Posso dire con sicurezza che il sistema è stato violato.
> Sono stati installati una serie di file in /usr/local/bin quali
> ssh-keygen ed affini e questi venivano utilizzati al posto di quelli
> ufficiali.
Grrr...
> Ora il discorso è il seguente.
> Ho reinstallato, cancellato questi file, sostituiti i file di
> configurazione di /etc/ssh e cancellato le varie directory ssh2 (sto
> comunque cercando ancora residui)
Sei sicuro di aver trovato tutto?
> Quello che mi domando è dove diceva al sistema di usare
> /usr/local/bin anzichè /usr/bin ?
Qui ti deve rispondere uno piu' bravo di me.
> Come posso fare per difendere un indirizzo pubblico che ha un accesso
> ssh oltre a cambiare porta ?
Mi riferisco alla versione di ssh su lenny:
Disattivando l'accesso interattivo.
Per quanto ne so, l'accesso con la chiave non disabilita automaticamente
l'accesso interattivo con username/password.
Di default quello e' attivo e occorre disattivarlo con l'opzione
ChallengeResponseAuthentication no
Sempre con riferimento a debian, puoi proteggere anche con fail2ban.
Questo software esclude per un tempo prestabilito e dopo un certo numero
di tentativi l'indirizzo ip che sta tentando l'intrusione.
Dovrebbe esserci anche qualcosa per i port scan, ma al momento non mi
viene in mente,
Cambiare la porta di accesso, come proponevi, e' anche un opzione.
Ciao
Luigi
Walter Valenti
>
> > Quello che mi domando è dove diceva al sistema di usare
> > /usr/local/bin anzichè /usr/bin ?
Credo semplicemente nel $PATH.
Walter
mauro
Il giorno 07/lug/09, alle ore 19:19, pac ha scritto:
> Come posso fare per difendere un indirizzo pubblico che ha un accesso
> ssh oltre a cambiare porta ?
il problema non e' tanto cambiare la porta. O meglio, il cambio di
porta evita che gli script automatizzati tentino di accedere e quindi
e' cosa buona per tenere almeno i log un po' piu' puliti.
> Cosa posso controllare ancora ?
come hanno fatto ad entrare, p.es. SSH e' un ottimo prodotto, a meno
di pwd scarse, funziona perfettamente ed e' sicuro. Cerca di capire
come sono entrati guardando i logo di tutti i servizi attivi e
pubblici, soprattutto quelli dove intrinsecamente e' possibile
caricare qualcosa (web).
nel mio caso una webmail fallata e non correttamente aggiornata dai
colleghi addetti (si trattava di roundcube) per essere esatti.
se si tratta di una macchina pubblica, controlla a fondo i log,
qualche rimasuglio di solito resta.
se sono passati per codice errato in un server web controlla tutti i
log di apache (usi apache?).
in ultimo, verifica che non siano stati sostituiti altri binari (oltre
alla roba che ti sei trovato installato).