Discussione:OpenSSH: Windows: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
(Risposta a Balubeto)
m (ha spostato Discussione:OpenSSH: windows a Discussione:OpenSSH: Windows: windows→Windows nel titolo)
 
(2 versioni intermedie di 2 utenti non mostrate)
Riga 1: Riga 1:
==Introduzione==
Ciao. Leggendo l'introduzione ho notato delle imprecisioni. Io non insisterei sul fatto se la chiave pubblica può essere ricavata da quella privata, non so se esistiono algoritimi a chiave pubblica in cui sia possibile, ma comunque non è questo il punto. Il punto è semplicemente che si usano due chiavi diverse: la pubblica per criptare e quella privata per decriptare, basta. La chiave pubblica di ogni macchina deve essere, appunto "pubblica" e "certificata" (ovvero devi essere sicuro che appartenga ad una data macchina).  
Il [[repository]] � a tutti gli effetti un archivio ordinato dove sono raccolti i pacchetti Debian (siano essi pacchetti binari o sorgenti) in modo ben organizzato e costantemente aggiornato. In ogni sistema debian i repository utilizzati vengono indicati nel file <tt>/etc/apt/sources.list</tt>. Vedi anche [[Faq#Repository|FAQ: Cos'� un '''repository'''?]].


=== Lista repository ufficiali debian ===
Ciao e buon lavoro ;-).
Di seguito troverete l'elenco repository ufficiali da inserire nel <tt>sources.list</tt> per le varie [[La struttura della Distribuzione|versioni di debian]]. Il mirror � quello italiano. I repository dei pacchetti sorgente sono commentati. per ulteriori informazioni leggere la sezione: [[I repository ed il loro utilizzo#Sources.list|Sources.list]].


==== Debian Sarge ====
: [[Utente:TheNoise|~ The Noise]] 06:40, 26 Mag 2006 (EDT)


  ## Debian Stable (sarge)
== Per The Noise ==
  deb http://ftp.it.debian.org/debian/ testing main contrib non-free
  #deb-src http://ftp.it.debian.org/debian/ testing main contrib non-free
  ## Aggiornamenti della sicurezza
  deb http://security.debian.org/ sarge/updates main contrib
  #deb-src http://security.debian.org/ sarge/updates main contrib


Per l'uso di sarge in ambito desktop (ma non solo) sono molto utili i [[backports]]:
Grazie per avermi fatto rilevare gli sbagli che ho scritto (ho gia` proveduto a correggerli, almeno spero). In verita`, volevo far capire ai nuovi utenti che, quando una persona A viene in possesso di una chiave privata di un'altra persona B, la persona A e` in grado anche di mettere nei guai seri la persona B. Quindi, la chiave privata va custodita in un luogo sicuro come o piu` di una password.


* [http://backports.org/ Debian Backports]
GRAZIE


==== Debian Etch ====
CIAO


  ## Debian Testing (etch)
----
  deb http://ftp.it.debian.org/debian/ testing main contrib non-free
  #deb-src http://ftp.it.debian.org/debian/ testing main contrib non-free
  ## Aggiornamenti della sicurezza
  deb http://security.debian.org/ etch/updates main contrib
  #deb-src http://security.debian.org/ etch/updates main contrib


==== Debian Sid ====
: [[Utente:Balubeto|Balubeto]] 12:18, 26 Mag 2006 (EDT)


  ## Debian Unstable (sid)
== Per Balubeto ==
  deb http://ftp.it.debian.org/debian/ unstable main contrib non-free
  #deb-src http://ftp.it.debian.org/debian/ unstable main contrib non-free


Per '''Sid''' non c'� il repository per la sicurezza dato che eventuali falle vengono corrette semplicemente con l'aggiornamento del pacchetto incriminato.
Comunque, è falso dire che la chiave pubblica si può ricavare dalla chiave privata, come hai scritto nell'articolo: nessuna delle due chiavi si può ricavare dall'altra!


===La Struttura dei repository===
: [[Utente:TheNoise|~ The Noise]] 11:58, 30 Mag 2006 (EDT)
Un repository � suddivisibile, grossomodo, in due sezioni:
* '''dists''' in questo ramo sono contenuti i file di controllo, che permettono il funzionamento del sistema di pacchettizzazione. Infatti sono presenti i file che descrivono i pacchetti presenti nell'archivio (divisi per la release di appartenenza);
* '''doc''' raccoglie la documentazione di base per Debian (segnalazioni di Bug, Faq, il Contratto Sociale ed altro)
* '''indices''' contiene l'indice di tutti i file contenuti in tutti i pacchetti. Queste informazioni sono usate da [[Apt-file: ricerca all'interno dei pacchetti|<tt>apt-file</tt>]].
* '''non-US''' a causa di problemi legali dovuti al divieto di esportazione di matariale per la difesa (tra cui materiale crittografici, utilizzati anche in PGP e SSH). Per ovviare a questi problemi, i pacchetti sono stati posti in una sezione a parte, la cui distribuzione � legata a server non Statunitensi.
* '''pool''' questo � l'archivio vero e proprio, dove sono contenuti i pacchetti, raggruppati per lettera iniziale;
* '''project''' contiene materiale per sviluppatori. Degne di nota la direcotory experimetal, che contiene i pacchetti in fase di sviluppo e perfezionamento;<br/>
* '''tools''' contiene degli strumenti Dos per la creazione di dischetti di boot, partizionamento e lancio di Linux.


===La Suddivisione del repository===
== Per The_Noise ==
Navigando un po' tra gli archivi Debian, si nota subito una particolare suddivisione: i repository, infatti, sono divisi in '''main''', '''contrib''' e '''non-free''', nel modo seguente:
* '''main''' � la sezione principale, che contiene il 90% dei pacchetti presenti in Debian
* '''contrib''' raccoglie i pacchetti coerenti con la DFSG5.6, ma che dipendono da pacchetti che non la rispettano
* '''non-free''' contiene dei pacchetti che possiedono delle limitazioni nella distribuzione (ad esempio perch� non utilizzabili in ambito commerciale o perch� dipendenti da applicazioni o pacchetti che non rispettano la Debian Free Software Guideline)


==Sources.list==
[quote]
===Il ruolo fondamentale===
Comunque, è falso dire che la chiave pubblica si può ricavare dalla chiave privata, come hai scritto nell'articolo: nessuna delle due chiavi si può ricavare dall'altra!
Il file '''/etc/apt/sources.list''' � forse il pi� importante file di configurazione del sistema di gestione dei pacchetti Debian. Esso, infatti, contiene l'elenco e gli indirizzi dei repository a cui apt accede.
[/quote]


===Ordine di Inserimento===
Prova a leggere [http://it.wikipedia.org/wiki/Crittografia_asimmetrica#Utilizzo_della_crittografia_asimmetrica qui] che afferma che "In realtà esiste una relazione tra le due chiavi, in modo tale che dalla chiave segreta (la prima ad essere generata) si possa facilmente (e automaticamente) generare la chiave pubblica. L'operazione inversa è invece computazionalmente impossibile: è quindi molto difficile risalire alla chiave segreta conoscendo unicamente quella pubblica, a meno che non si conoscano i parametri utilizzati per la generazione di quest'ultima"
� importante inserire i repository con un giusto ordine: i primi in elenco, infatti, sono i pi� importanti (o favoriti). Per migliorare le performance, � consigliabile ordinarli per velocit� (Es. prima il cdrom, poi la rete locale, poi internet, ...).


===Sintassi===
In effetti, con l'utility [http://the.earth.li/~sgtatham/putty/latest/alpha/puttygen.exe PuTTYgen] per Windows ho proprio verificato cio`: Ho preso una chiave privata generata da OpenSSH Server per Linux e l'ho messa in una directory di Windows senza mettere la rispettiva chiave pubblica . ho caricato il programma PuTTYgen e ho dato in pasto la mia chiave privata e mi e` apparso il codice della mia chiave pubblica . a questo punto ho verificato che fosse propriola mia chiave pubblica e a quanto pare lo e`.
Ogni riga che descrive un repository ha una ben determinata sintassi:
<pre>
deb uri distribution [component..]
</pre>


Analizziamo i singoli componenti:
quindi vorrei il tuo parere in merito a cio` .
* '''deb o deb-src''' serve ad indicare se il repository indicato contiene pacchetti binari o pacchetti sorgenti (se li contiene entrambi, � necessario specificarlo usando due righe diverse).
* '''uri''' indica l'indirizzo a cui � possibile trovare il repository; � possibile scegliere tra i seguenti metodi di accesso ai pacchetti:
** '''file''' permette di inserire un repository presente sull'Hard Disk del computer;
** '''cdrom''' permette di inserire un repository presente su un cd-rom;
** '''http''' permette di accedere ad un repository tramite il protocollo http (se � impostata una variabile di ambiente '''http_proxy''' col formato '''http://server:port/''' verranno usate queste opzioni per accedere al repository; in caso di necessit� di autenticazione, � possibile specificare l'inidirizzo del proxy, nella variabile d'ambiente '''http_proxy''', nel seguente modo: '''http://user:pass@server:port/''', anche se risulta non essere un modo sicuro di autenticazione);
** '''ftp''' permette di accedere ad un repository tramite il protocollo ftp; � possibile specificare un proxy nell stesso modo indicato per http al punto precedente, sostituendo alla variabile '''http_proxy''' '''ftp_proxy''';
** '''copy''' � idendico a file, ma i file utilizzati vengono salvati nella cache di apt; utile nel caso di supporti removibili quali Usb-drive, Floppy, Zip, ...;
** '''rsh, ssh''' permette di accedere ad un repository tramite il protocollo ssh. Non � possibile, per�, effettuare alcuna autenticazione interativa, ma solo tramite lo scambio di chiavi RSA.
* '''distribution''' indica la [[La struttura della Distribuzione|distribuzione (o release)]] utilizzata... � possibile usare il nome in codice (sarge, etch, sid) o il nome generico (stable, testing, unstable);
*'''component''' indica la sezione (non-free, main, contrib...) del repository da inserire; sono possibili scelte multiple.


===Alcuni esempi===
grazie
Non c'� niente di meglio, per capire la sintassi del file sources.list, si un po' di esempi:
<pre>
deb http://ftp.it.debian.org/debian/ stable main non-free contrib
deb-src http://ftp.it.debian.org/debian/ stable main non-free contrib
</pre>
I repository ufficiali (binari e sorgenti) presi da un mirror italiano.


<pre>
ciao
deb file:/var/cache/apt-build/repository apt-build main
</pre>
Il repository di apt-build (Rif. 7.1 Pag. [*])


<pre>
== Risposta a Balubeto ==
deb http://non-us.debian.org/debian-non-US sid/non-US main contrib non-free
deb-src http://non-us.debian.org/debian-non-US sid/non-US main contrib non-free
</pre>
I repository ufficiali del repository non-US; interessante l'indicazione della directory non-US presente nella directory dists/sid/


<pre>
Premetto che non sono un esperto di crittografia, ma secondo me quella affermazione di wikipedia che citi è questionabile, anche perchè si parla genericamente di crittografia asimmetrica in quell'articolo. Ecco perchè:
deb http://repos.debianizzati.org ./
</pre>
Un repository 'artigianale' accessibile tramite un webserver


<pre>
# Ho sempre letto che una coppia di chiavi una volta generata è assolutamente "simmetrica" nel senso che '''in linea teorica''' puoi scegliere una come chiave privata e l'altra come chiave pubblica, o viceversa. Queste informazioni le puoi trovare probabilmente nella documentazione di gnupg.
deb file:/home/maxer/repos ./
# Anche pensando al caso ultra semplificato della fattorizzazione di numeri primi è evidente che non puoi ricavarne uno automaticamente dall'altro, senza conoscerne il prodotto.
</pre>
# Leggendo l'algortmo RSA su wikipedia (en) si capisce che spesso assieme alla chiave privata vengono incluse anche altre informazioni, come i numeri p e q dai quali si è generata la coppia di chiavi. Evidentemente conoscendo p e q è possibile ricavare nuovamente la chiave pubblica. Quindi se la chiave privata viene salvata assieme a questi altri paramteri (chiamati paramtri CRT) la chiave pubblica si può ricavare. Quindi dipende dal particolare programma e da come questo implementa l'algoritmo. Ne l'algoritmo RSA ne tanto meno gli algoritmi a chiave pubblica si basano sul concetto che la chiave pubblica si possa ricavare dalla privata (cosa che si deduce dalle tue parole)! Questa è semmai una possibilità che dipende dal fatto se assieme alla chiave privata si sono salvate delle informazioni aggiuntive o meno.
Un repository situato nella home dell'utente maxer, creato con dpkg-scanpackages.
# Perchè ti stai perdendo in questo ginepraio? Mi pare che c'entri poco con la guida... dal titolo questa dovrebbe descrivere i passaggi necessari per effettuare la connessione, non certo spiegare il funzionamento interno degli algoritmi asimmetrici!


: [[Utente:TheNoise|~ The Noise]] 14:50, 30 Mag 2006 (EDT)


---- [[User:MaXeR|MaXeR]]
== Info sull'autenticazione GSSAPI in una connessione SSH ==
[[Categoria:Apt]]
 
[[Categoria:Repository]]
CIAO
 
Se qualcuno mi volesse dare una mano nella descrizione molto concisa ma significativa sulla definizione e su come si utilizza l'autentificazione GSSAPI in una connessione SSH ne sarei molto grato in quanto ho paura che la definizione data nella mia guida sia sbagliata.
 
GRAZIE
 
CIAO
 
--[[Utente:Balubeto|Balubeto]] 03:02, 3 Giu 2006 (EDT)

Versione attuale delle 11:22, 27 nov 2015

Ciao. Leggendo l'introduzione ho notato delle imprecisioni. Io non insisterei sul fatto se la chiave pubblica può essere ricavata da quella privata, non so se esistiono algoritimi a chiave pubblica in cui sia possibile, ma comunque non è questo il punto. Il punto è semplicemente che si usano due chiavi diverse: la pubblica per criptare e quella privata per decriptare, basta. La chiave pubblica di ogni macchina deve essere, appunto "pubblica" e "certificata" (ovvero devi essere sicuro che appartenga ad una data macchina).

Ciao e buon lavoro ;-).

~ The Noise 06:40, 26 Mag 2006 (EDT)

Per The Noise

Grazie per avermi fatto rilevare gli sbagli che ho scritto (ho gia` proveduto a correggerli, almeno spero). In verita`, volevo far capire ai nuovi utenti che, quando una persona A viene in possesso di una chiave privata di un'altra persona B, la persona A e` in grado anche di mettere nei guai seri la persona B. Quindi, la chiave privata va custodita in un luogo sicuro come o piu` di una password.

GRAZIE

CIAO


Balubeto 12:18, 26 Mag 2006 (EDT)

Per Balubeto

Comunque, è falso dire che la chiave pubblica si può ricavare dalla chiave privata, come hai scritto nell'articolo: nessuna delle due chiavi si può ricavare dall'altra!

~ The Noise 11:58, 30 Mag 2006 (EDT)

Per The_Noise

[quote] Comunque, è falso dire che la chiave pubblica si può ricavare dalla chiave privata, come hai scritto nell'articolo: nessuna delle due chiavi si può ricavare dall'altra! [/quote]

Prova a leggere qui che afferma che "In realtà esiste una relazione tra le due chiavi, in modo tale che dalla chiave segreta (la prima ad essere generata) si possa facilmente (e automaticamente) generare la chiave pubblica. L'operazione inversa è invece computazionalmente impossibile: è quindi molto difficile risalire alla chiave segreta conoscendo unicamente quella pubblica, a meno che non si conoscano i parametri utilizzati per la generazione di quest'ultima"

In effetti, con l'utility PuTTYgen per Windows ho proprio verificato cio`: Ho preso una chiave privata generata da OpenSSH Server per Linux e l'ho messa in una directory di Windows senza mettere la rispettiva chiave pubblica . ho caricato il programma PuTTYgen e ho dato in pasto la mia chiave privata e mi e` apparso il codice della mia chiave pubblica . a questo punto ho verificato che fosse propriola mia chiave pubblica e a quanto pare lo e`.

quindi vorrei il tuo parere in merito a cio` .

grazie

ciao

Risposta a Balubeto

Premetto che non sono un esperto di crittografia, ma secondo me quella affermazione di wikipedia che citi è questionabile, anche perchè si parla genericamente di crittografia asimmetrica in quell'articolo. Ecco perchè:

  1. Ho sempre letto che una coppia di chiavi una volta generata è assolutamente "simmetrica" nel senso che in linea teorica puoi scegliere una come chiave privata e l'altra come chiave pubblica, o viceversa. Queste informazioni le puoi trovare probabilmente nella documentazione di gnupg.
  2. Anche pensando al caso ultra semplificato della fattorizzazione di numeri primi è evidente che non puoi ricavarne uno automaticamente dall'altro, senza conoscerne il prodotto.
  3. Leggendo l'algortmo RSA su wikipedia (en) si capisce che spesso assieme alla chiave privata vengono incluse anche altre informazioni, come i numeri p e q dai quali si è generata la coppia di chiavi. Evidentemente conoscendo p e q è possibile ricavare nuovamente la chiave pubblica. Quindi se la chiave privata viene salvata assieme a questi altri paramteri (chiamati paramtri CRT) la chiave pubblica si può ricavare. Quindi dipende dal particolare programma e da come questo implementa l'algoritmo. Ne l'algoritmo RSA ne tanto meno gli algoritmi a chiave pubblica si basano sul concetto che la chiave pubblica si possa ricavare dalla privata (cosa che si deduce dalle tue parole)! Questa è semmai una possibilità che dipende dal fatto se assieme alla chiave privata si sono salvate delle informazioni aggiuntive o meno.
  4. Perchè ti stai perdendo in questo ginepraio? Mi pare che c'entri poco con la guida... dal titolo questa dovrebbe descrivere i passaggi necessari per effettuare la connessione, non certo spiegare il funzionamento interno degli algoritmi asimmetrici!
~ The Noise 14:50, 30 Mag 2006 (EDT)

Info sull'autenticazione GSSAPI in una connessione SSH

CIAO

Se qualcuno mi volesse dare una mano nella descrizione molto concisa ma significativa sulla definizione e su come si utilizza l'autentificazione GSSAPI in una connessione SSH ne sarei molto grato in quanto ho paura che la definizione data nella mia guida sia sbagliata.

GRAZIE

CIAO

--Balubeto 03:02, 3 Giu 2006 (EDT)