Newsgroup: it.comp.sicurezza.unix
Titolo: ssh + public key

ho postato lo stesso msg anche su i.c.o.l.sys, ma non ho ancora avuto
risposta.
dai doc che ho su ssh non sono riuscito ad avere info utili...
sto iniziando a usare l'autenticazione tramite public key ma ho trovato
una cosa che mi sembra abbastanza strana.
tramite il software x win32, ho generato una coppia di chiavi con
relativa frase di protezione
ho copiato la chiave pubblica nel file "authorized_keys" su so debian
per l'utente root e ho provato a loggarmi da pc con so redhat dando come
input il file con la CHIAVE PUBBLICA (si, proprio la chiave pubblica,
non quella privata) et volià!
accedo senza nessun intoppo!
e intendo proprio nessuno, nemmeno una richiesta di password o frase o
chessò io...
ecco il comando che uso (come utente root):
ssh -i key.txt 192.168.0.50
o anche
ssh -l root -i key.txt 192.168.0.50
è normale?
--
+-----
| Paolo opg
|
| janickg ( at ) hotmail ( dot ) com
+-----

ssh -i key.txt 192.168.0.50
Boh, io uso ssh -l root 192.168.0.50 (non con lo stesso Ip, ma si fa
per dire).
Non mi sono mai nemmeno posto il problema di inviare chiavi. Succede
tutto in automatico al primo collquio tra due macchine nuove.

 è normale?
Direi di si. e mi pare che nella manpage sia anche spiegato.
-- 
HappyCactus - Linux User #209744 - LFS User #6046 - >>> SMSPM950 <<<
 
Ci sono 10 categorie di persone al mondo: quelle che capiscono
il sistema binario e quelle che non lo capiscono.

Direi di si. e mi pare che nella manpage sia anche spiegato.
nella manpage ho trovato riferimento all'autenticazione tramite chieve
privata sul client e pubblica sul server, ma chiave pubblica con
chiave pubblica non l'ho proprio visto...
a quanto pare o le idee un pò confuse...
:-)


 E' normale?
No.
Fabio

 wrote in message
news:MPG.17f3b78cb...@powernews.libero.it...

infatti mi pizzava un pò che non mi chiedesse nessuna password...
e poi ho controllato sulla man page: si parla di login tramite chiave
pubblica seul server e privata sul client, qui invece uso solo la chiave
pubblica...
ecco l'uotput dei due comandi:
sshd -d
(dalla console del server, ovviamente)
debug1: sshd version OpenSSH_3.4p1 Debian 1:3.4p1-1
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
ssh -v
(sul pc client)
OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
altri dettagli
ecco il comando che uso (come utente root):
ssh -i unix2.txt 192.168.0.50
ssh -l root -i unix2.txt 192.168.0.50
il tentativo di connessione viene fatto da root su rh73 verso root su
debian
la chiave privata ha una frase di protezione non nulla (17 caratteri)
la chiave è stata generata su sistema win 32 (win2k) con openssh per
win32
se provo da utonto redhat a root su debian la frase mi viene richiesta e
la connessione (ovviamente) viene rifiutata, dato che uso come input la
CHIAVE PUBBLICA.
idem da utonto a utonto.
se uso come client debian e server redhat, la connessione tramite chiave
non funzica.
l'autenticazione tramite password funziona regolarmente in entrambe le
direzioni.
se provo a connettermi tramite client win32, mi viene richiesta la frase
e respinta, dato che come sempre in input ho messo la CHIAVE PUBBLICA.
linux è installato su due virtual machines vmware
redhat7.3
kernel 2.4.18-3 standard, non ricompilato
openssh-3.1p1-3
openssh-server-3.1p1-3
openssh-clients-3.1p1-3
debian3r0.0
kernel 2.4.18-bf2.4 standard non ricompilato
ssh1:3.4p1-1
(non ho trovato sshd tra i pacchetti, ma il server c'è, quindi penso la
versione sia sempre la stessa)
il sistema win32 con cui ho generato le password, è win2k sp3 con tute
le patch post sp3
client software openssh x win32
OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
ogni info è gradita!
:-))

 wrote in message
news:3d88f430...@news.telvia.it...

non so parlando delle chiavi del server, ma di quelle dell'utente.
con l'opzione "-i", dico al programma di autenticare l'utente non
tramite password, ma di usare la chiave privata (bada, privata)
dell'utente.
io invece riesco a loggarmi usando solo la chiave pubblica!
boh!

 openssh-clients-3.1p1-3
Ti conviene aggiornare alla 3.4p1, quando puoi.
Prova a configurare sshd_config con:
IgnoreRhosts yes
IgnoreUserKnownHosts yes
RhostsAuthentication no
RhostsRSAAuthentication no
PasswordAuthentication no
ChallengeResponseAuthentication no
KerberosAuthentication no
e poi prova a vedere se ti accetta ancora le connessioni con la chiave
sbagliata (in realta', come avrai capito, la chiave viene rifiutata e
ssh passa al sistema di autenticazione successivo che viene accettato).
Fabio

 openssh-clients-3.1p1-3
ho provato
per la precisione openssh-3.1p1-6 su red-hat
ssh su debian 1:3.4p1-1, su win32 OpenSSH_3.4p1
ho fatto una coppia di chiavo y0 e y0.pub e fa tutto quello che deve fare.
verso utente normale e verso root.
(perche` nomini unix2.txt? non dovrebbe essere finire per .pub, sicuro di aver 
preso la chiave giusta?)
hai cancellato le altre chiavi?
nota che la passkey si applica alla chiave privata, non alla chiave pubblica.
Quando come chiave privata gli applichi una chiave pubblica ti chiede una 
passkey perche` non capisce il formato.
Ti e` venuto fuori il warning
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
quando esegui l'ssh? hai modificato i diritti del file unix2.txt?
sai che sono curioso?


anche io
:-)
spero d aver sbagliato qualche conf...

 
Aspettiamo che ci posti l'output "ssh -v" da redhat verso debian (verbose)
ti dico un'altra cosa che mi capito` un po' (abbastanza) di tempo fa. facevo 
ssh su una macchina e riuscivo a entrare non accorgendomi che in realta` per 
un errore di configurazione della route table stavo entrando sulla macchina da 
dove ero partito!

ho reinstallato causa hd fritto e il problema non c'è più...
probabilmente facevo io qualche cazzata...
:-(
scusate il disturbo

 :-(
Ecco una possibile spiegazione.
Il client ha generato le due chiavi, pubblica e privata.
Il client copia la propria chiave pubblica sul server, e le aggiunge tra 
le ~/.ssh/authorized_keys.
ssh server
e come per magia entri senza alcuna autenticazione (in realta', password. 
l'autenticazione viene fatta criptando con la chiave privata del client 
la chiave pubblica del client stesso, e confrontandola con le chiavi 
pubbliche autorizzate. L'autenticazione viene garantita dalla firma 
digitale della chiave pubblica stessa)
Non e' che hai fatto questa cosa qui per il client root?



il prob č che la chiave veniva generata su una machcina win32,
completamente diversa quindi sia dal client che dal server.
probabilmente ho fatto qualche casino con il copia e incolla e lo
scaricamento dei files...
a forza di passa, copia, scarica e rilogga, magari ho incasinato il
tutto e il sistema se l'č presa a male :-)
cmq adesso sembra tutto regolare.
meglio cosě...
se fosse stato un buco di quella portata, sarebbe stata veramente
grossa!!!
;-P