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.

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.

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

[gve]

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.

sigh sob

[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?

[gve]

- 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`.

[mgs]

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

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?