Visualizzazione risultati 1 fino 8 di 8

Discussione: SSH su mandrake

  1. #1
    L'avatar di CoD
    CoD
    CoD non è connesso Utente storico
    Data registrazione
    21-04-2003
    Messaggi
    2,451

    Predefinito SSH su mandrake

    La mia universita' usa SSH per trasferire i file dei siti sul server.

    Offrono scaricabile sia il client per windows sia il pacchetto rpm per linux, ma nonostante questo non riesco proprio ad installarlo.

    So che SSH esiste gia' su linux da linea di comando. La cosa mi basterebbe visto che anche ftp io lo uso da shell.

    Il problema e' che non capisco come fare a far trovare a SSH i file delle chiavi che l'universita' mi ha dato.

    Visto che e' appena nata questa nuova sezione ne approfitto subito

    Qualcuno puo' aiutarmi?

    Io direi di partire da zero: spiegatemi TUTTO, perche' di SSH so proprio pochino.
    Collaboratore 332 della Free Software Foundation Europe
    Linux Registered User 354705
    Credo che moriro' il giorno che smettero' di imparare. Di sicuro smettero' di imparare il giorno che moriro'.

  2. #2
    L'avatar di Serverplus
    Serverplus non è connesso Utente attivo
    Data registrazione
    07-04-2004
    Messaggi
    475

    Post

    Ssh è un protocollo di comunicazione nato per rimpiazzare i comandi Berkeley r* (rsh, rlogin, rcp) e a differenza di questi fornisce una infrastruttura per connessioni crittografate nonchè autenticazione forte tra host e host e tra utente e host. Chiude inoltre alcuni noti problemi di sicurezza dei protocolli TCP/IP come l'IP spoofing (falsificazione dell'indirizzo IP del mittente), il DNS spoofing (falsificazione delle informazioni contenute nel DNS) e il routing spoofing (falsificazione delle rotte intraprese dai pacchetti e instradamento su percorsi diversi).

    I comandi r* possono essere addirittura rimpiazzati dalle rispettive versioni sicure (ssh, slogin, scp) in maniera trasparente per l'utente.

    Esistono due versioni del protocollo ssh: la versione 1, più vecchia, che da questo momento in poi chiameremo ssh1, e la versione 2, che chiameremo ssh2, chè è una completa riscrittura della vecchia versione ed è più sicura.

    Ogni host su cui è installato ssh possiede una coppia di chiavi RSA (un algoritmo di crittografia a chiave asimmetrica) lunghe 1024 bit, una pubblica ed una privata. In più, ogni utente che utilizza ssh può opzionalmente generare una propria coppia di chiavi RSA.

    All'atto della connessione, il server comunica al client due chiavi pubbliche: una fissa di 1024 bit che è la vera e propria chiave dell'host e l'altra di 768 bit che viene rigenerata ogni ora. Il client allora genera una sequenza casuale di 256 bit e la codifica con le chiavi pubbliche del server. Da questo momento in poi la connessione viene crittografata con uno degli algoritmi a chiave simmetrica supportati da ssh (IDEA, DES, 3DES, Arcfour, Blowfish) e si passa alla fase di autenticazione.

    Ssh può autenticare un utente in vari modi:

    * RhostsAuthentication:

    questo metodo si basa sulla normale autenticazione dei comandi r*: se il nome dell'host client è inserito all'interno del file /etc/hosts.equiv sul server allora ad un utente è concesso il login senza password a patto che abbia uno username sul server uguale a quello sul client; analogamente è concesso il login senza password se la coppia "client username/client host" è inserita all'interno del file $HOME/.rhosts sul server (dove $HOME è la home directory dell'utente sul server).

    Questo è il metodo di autenticazione meno sicuro, in quanto è suscettibile ai problemi di sicurezza descritti all'inizio ed in una installazione di default è disabilitato.

    I file coinvolti in questo tipo di autenticazione sono i seguenti:

    CLIENT
    Nessuno

    SERVER
    /etc/hosts.equiv
    $HOME/.rhosts

    * RhostsRSAAuthentication:

    questo è il metodo principale di autenticazione. Si basa fondamentalmente sulla RhostsAuthentication, ma l'identità dell'host client viene accertata attraverso la sua chiave pubblica RSA: il server possiede una copia della chiave pubblica degli host autorizzati alla connessione all'interno del file /etc/ssh_known_hosts ed inoltre ogni utente può crearsi una propria lista personalizzata di chiavi pubbliche utilizzando il file $HOME/.ssh/known_hosts, nella sua home directory sul server. Una volta accertata l'identità dell'host client la connessione viene autorizzata e il login viene effettuato con le modalità della RhostsAuthentication. Alternativamente ai file /etc/hosts.equiv e $HOME/.rhosts sul server si possono utilizzare i file /etc/shosts.equiv e $HOME/.shosts, di formato identico; in questo modo ci si svincola completamente da qualsiasi legame con i vecchi comandi r* e non si incorre nei loro problemi di security.

    I file coinvolti in questo tipo di autenticazione sono i seguenti:

    CLIENT
    /etc/ssh_known_hosts
    $HOME/.ssh/known_hosts

    SERVER
    /etc/ssh_known_hosts
    $HOME/.ssh/known_hosts
    /etc/hosts.equiv
    /etc/shosts.equiv
    $HOME/.rhosts
    $HOME/.shosts

    * RSAAuthentication:

    questo tipo di autenticazione si basa sulla sola crittografia a chiave asimmetrica e presuppone che l'utente possegga una coppia di chiavi RSA. Se la chiave pubblica dell'utente è inserita nel file $HOME/.ssh/authorized_keys sul server, il server stesso genera una sequenza casuale di bit, la codifica con la chiave pubblica dell'utente e spedisce il tutto al client; il client decodifica con la chiave privata dell'utente la sequenza di bit e la rispedisce al server codificandola con le chiavi pubbliche del server. Cosi' facendo il client dimostra di conoscere la chiave privata, autenticandosi col server. Con questo tipo di autenticazione è richiesto all'utente di inserire la password che sblocca la sua chiave privata.

    I file coinvolti in questo tipo di autenticazione sono i seguenti:

    CLIENT
    /etc/ssh_known_hosts
    $HOME/.ssh/known_hosts
    $HOME/.ssh/identity.pub
    $HOME/.ssh/identity

    SERVER
    $HOME/.ssh/authorized_keys

    Se un utente vuole utilizzare tale forma di autenticazione, è necessario che distribuisca la propria chiave pubblica a tutti i server ai quali vuole connettersi, in pratica copiando il contenuto del file $HOME/.ssh/identity.pub, presente all'interno della sua home directory sul client, all'interno del file $HOME/.ssh/authorized_keys sugli host server.

    * TISAuthentication:

    Questo tipo di autenticazione richiede la presenza di un server di autenticazione TIS: il server ssh cercherà di autenticare l'utente interagendo con il server di autenticazione TIS, agendo da tramite tra quest'ultimo e l'utente. Se l'utente viene autenticato dal server TIS, il server ssh concede l'accesso.

    * Password:

    Quando i metodi di cui sopra falliscono, all'utente viene chiesto di inserire la password del suo account sul server: da notare che la comunicazione sta comunque avvenendo in maniera crittografata.

    Caratteristica interessante di ssh è la possibilità di effettuare una codifica di qualsiasi tipo di connessione, creando cosi' un canale di comunicazione crittografato tra client e server sul quale veicolare la connessione vera e propria. Questa caratteristica è chiamata port forwarding.

    Nel caso del protocollo X11 ssh ne effettua in maniera automatica la codifica, a patto che dal lato client sia definita la variabile di ambiente DISPLAY: in questo caso, sul server al quale ci si è connessi, viene creato un X server fittizio e la variabile DISPLAY viene modificata in modo tale da puntare ad esso. Questo X server si occuperà in realtà solo di inoltrare i dati sul canale di comunicazione sicuro creato da ssh, che poi provvederà a passare i dati decodificati all'X server reale.

  3. #3
    L'avatar di CoD
    CoD
    CoD non è connesso Utente storico
    Data registrazione
    21-04-2003
    Messaggi
    2,451

    Predefinito

    ok va bene, grazie.

    Alcune cose le sapevo gia' ma e' sempre meglio ripassare.

    Pero' adesso veniamo al nocciolo: io ho la mia chiave da 2048-bit dsa che mi ha fornito l'universita'.
    E' leggermente differente come layout da quelle che genera automaticamente ssh (questione di ritorno a capo, vabbe').

    Ora come la metto su linux in modo che funzioni?

    Ho provato a generare con ssh un'altro paio di chiavi dsa 2048 bit e a sostituirle poi con quelle dell'universita', ma inutilmente.

    Ho anche il problema che l'utente predefinito per ssh e' lo stesso della mia session linux (cioe' cod) mentre io ho necessita' di avere un nome utente diverso.

    Mi servirebbe un aiuto passo passo per portare le chiavi dell'universita' sul mio linux mandrake 9.2 e farlo funzionare.

    Grazie
    Collaboratore 332 della Free Software Foundation Europe
    Linux Registered User 354705
    Credo che moriro' il giorno che smettero' di imparare. Di sicuro smettero' di imparare il giorno che moriro'.

  4. #4
    L'avatar di gve
    gve
    gve non è connesso Utente storico
    Data registrazione
    26-01-2003
    Residenza
    Brescia
    Messaggi
    2,964

    Predefinito

    Anche la mia universita` fornisce qualcosa del genere.

    Cio` che posso dirti e` come procedo io, questa e la riga di comando per la connessione:

    ssh -l username host

    a questo punto il server mi chiede la password, e una volta inserita quella mi ritrovo nella shell ssh.

    PS: interessante tutta la tua delucidazione Serverplus, anche se ora non avevo tempo di leggermela con calma, io ne sapevo molto poco al riguardo.
    | Regolamento del Forum | Regolamento di AlterVista | FAQ di AlterVista | Netiquette |

    GVE = GVE Virtual Extension
    AVCM #: 6637

  5. #5
    L'avatar di CoD
    CoD
    CoD non è connesso Utente storico
    Data registrazione
    21-04-2003
    Messaggi
    2,451

    Predefinito

    sigh sob

    Codice:
    [root@localhost cod]# ssh -l xxxxxx www.disclic.unige.it
    xxxxxx@www.disclic.unige.it's password:
    Permission denied, please try again.
    xxxxxx@www.disclic.unige.it's password:
    Authenticated with partial success.
    Permission denied (publickey).
    Sul client di windows ho 2 password, per cui non sapevo quale delle due fosse quella da inserire, la seconda sembra funzionare ma mi dice "Authenticated with partial success." e mi sbatte fuori.

    Idee?
    Collaboratore 332 della Free Software Foundation Europe
    Linux Registered User 354705
    Credo che moriro' il giorno che smettero' di imparare. Di sicuro smettero' di imparare il giorno che moriro'.

  6. #6
    L'avatar di gve
    gve
    gve non è connesso Utente storico
    Data registrazione
    26-01-2003
    Residenza
    Brescia
    Messaggi
    2,964

    Predefinito

    - puoi provare col comando ssh -2 al posto di ssh per forzare l'uso del protocollo v.2 (-1 per il protocollo v.1).

    - visto l'errore di parziale successo, forse devi usare, in aggiunta al resto, l'opzione:
    -i file
    pe passare la tua public key; questa e` solo un'ipotesi, pero` non so come funzioni, mai usata.

    Altre idee non mi vengono ... magari Serverplus o altri piu` esperti di me ti sanno dire di piu`.
    | Regolamento del Forum | Regolamento di AlterVista | FAQ di AlterVista | Netiquette |

    GVE = GVE Virtual Extension
    AVCM #: 6637

  7. #7
    L'avatar di mgs
    mgs
    mgs non è connesso Utente storico
    Data registrazione
    21-03-2003
    Residenza
    Cagliari
    Messaggi
    1,655

    Predefinito

    prova ssh user@host io uso sempre questo ma non so se sia questa la soluzione... forse equivale a -l

    • Il 95% delle risposte che volete avere si trova sul regolamento
    del Forum o su quello di AV. •
    Al restante 5% troverete risposta se ci pensate su solo 2 minuti.



  8. #8
    L'avatar di CoD
    CoD
    CoD non è connesso Utente storico
    Data registrazione
    21-04-2003
    Messaggi
    2,451

    Predefinito

    Ho provato a sostituire i file id_dsa e id_dsa.pub con quelli forniti dall'universita'.

    Ora ssh legge la chiave, ma non gli piace e sembra non capire la passphrase della chiave (me la chiede 3 volte poi ci rinuncia)

    Insiste nel darmi come errore:
    Authenticated with partial success.
    Permission denied (publickey)

    Ma che devo fare?
    Collaboratore 332 della Free Software Foundation Europe
    Linux Registered User 354705
    Credo che moriro' il giorno che smettero' di imparare. Di sicuro smettero' di imparare il giorno che moriro'.

Regole di scrittura

  • Non puoi creare nuove discussioni
  • Non puoi rispondere ai messaggi
  • Non puoi inserire allegati.
  • Non puoi modificare i tuoi messaggi
  •