Info:

twitter

Ultimi commenti: Comment feed

Tags:

Sponsor:

Archivio 2018:

Lug Giu Mag Feb Gen

Archivio 2017:

Dic Nov Ott Mag Apr Mar Feb Gen

Archivio 2016:

Dic Nov Ott Ago Mag Mar Feb Gen

Archivio 2015:

Nov Ott Set Mar Gen

Archivio 2014:

Dic Nov Ott Set Lug Giu Mag Apr Gen

Archivio 2013:

Dic Nov Set Ago Lug Giu Mag Apr Feb Gen

Archivio 2012:

Dic Nov Ott Set Ago Giu Mag Apr Mar Feb Gen

Archivio 2011:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2010:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2009:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2008:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2007:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2006:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Offsite Backup–intervallo

Avevo promesso un post dedicato all’assemblaggio dei vari pezzi ma mi son scontrato con qualche difficoltà con OpenSSH a cui penso valga la pena dedicare questo post. La modalità SSH che mi interessa è quella senza password e cioè basata su keyfile per fare in modo che il client installato sul mio PC di test si collegasse automaticamente al server. Il keyfile in pratica sostituisce l’uso della password tramite una chiave privata RSA.

È stato un bagno di sangue ma ce l’ho fatta. In sintesi quello che ho scoperto. Ci sono due versioni di SSHWindows:

  1. quella ‘ufficiale’ 3.81p-1 datata 9 Luglio 2004
  2. quella derivata, 4.2p2-2, qualche anno più nuova

La prima ha un baco molto antipatico: non riconosce i permessi per Windows e si rifiuta, nonostante sia considerato un “warning” e non un errore, di caricare un keyfile senza i permessi settati correttamente; la cosa buffa è che settarli correttamente è impossibile. Il problema si scavalca installando la ‘nuova’ versione ma non è finita.

Sul lato server l’installazione di SSHWindows crea un servizio con permessi di LocalSystem. Questo previene la possibilità di impersonare l’utente desiderato usando il keyfile restituendo un errore di tipo “public key auth seteuid fails”. Cercando su Google e passando per tipi misteriosi che dichiarano che Windows 2003 non è un sistema multi user e blah blah blah mi son ficcato solo in vicoli ciechi. Ho provato invece a far girare il servizio OpenSSH con le credenziali di destinazione sperando che funzionasse al primo colpo. Un ulteriore intoppo, i permessi sbagliati nella cartella dei log, facilmente sistemabile.

Riassumendo i passi correttivi:

  1. installare sshwindows in versione “derivata” su entrambi i lati della connessione
  2. seguire il tutorial indicato in questa pagina per generare la chiave RSA
  3. cambiare i permessi con cui gira il servizio OpenSSH
  4. aggiungere l’utente desiderato al folder di log

Et voilà il gioco è fatto. Visto che sono riuscito a procurarmi ben due librerie diverse per .Net che consentono la connessione SSH, spero di trovare un ritaglio di tempo per creare un client customizzato da fare girare come un servizio alla stregua di PeoneFS. Nella prossima puntata metto tutti i pezzi insieme, ma garantisco che non sarà l’ultima. Ho in mente una versione due dell’accrocchio che… ssst…

-quack

Potrebbero interessarti anche:
Commenti (2):
1. Gabriele
giovedì 21 ottobre 2010 alle 12:21 AM - firefox 2010091807 Debian 3.0.6
   
nonostante sia considerato un “warning” e non un errore, di caricare un keyfile senza i permessi settati correttamente; la cosa buffa è che settarli correttamente è impossibile.

Tutto ciò deriva dal nascita di ssh in un sistema unix-like.

L'utente A sulla macchina client ha una coppia chiave privata e pubblica (id_rsa e id_rsa.pub), di norma contenute in una directory .ssh nella sua home.

L'utente B sul server ha un file di chiavi autorizzate (authorized_keys), di norma contenuto nella directory .ssh, che conterrà la chiave pubblica dell'utente (id_rsa.pub).

Come tutti probabilmente saprete la chiave pubblica può e deve essere diffusa a piacimento, mentre quella privata deve, appunto, rimanere privata.

Quando A@client si connette come B@server, gli offre la sua chiave privata e B controlla che faccia il paio con una di quelle pubbliche in authorized_keys e quindi l'utente è ammesso.

I privilegi in unix sono (semplificando un po' e lasciando perdere le cose sofisticate tipo acl) del tipo rwx,rwx,rwx dove r è il permesso di lettura, w di scrittura e x di esecuzione dei file o di listing del contenuto di una directory.

OpenSSH controlla i privilegi delle directory .ssh, delle home degli utenti coinvolti e dei file id_rsa e authorized_keys.

Questo perché se il file id_rsa o authorized_keys sono scrivibili da altri oltre al loro proprietario (o lo sono le directory che li contengono, a partire dalla home degli utenti A e ovviamente la chiave (o il file delle chiavi autorizzate) sono considerati compromessi e quindi per prudenza non utilizzabili.

Ovviamente per quanto riguarda la chiave privata, essa deve essere anche leggibile solo dall'utente.

In Unix e in Linux tutto questo discorso è logico, ovvio e facile. In Windows, dove il sistema dei privilegi è diverso, diventa invece meno lineare e perciò dà origine a dei problemi.

Per questo a volte converrebbe studiare il meccanismo dove è nato, perché l'intero setup su Linux, compreso generare le chiavi prende meno di un minuto (sono due comandi, uno genera la coppia di chiavi di A, l'altro la copia nell'utente B@server, impostando correttamente tutti i privilegi. Ovviamente openssh-server e openssh-client si installano da repository).

A questo punto ci si può dedicare a studiare i casini del porting su Windows, che sicuramente derivano dalla difficoltà di forzare questi controlli in un ambiente in cui il meccanismo dei privilegi è diverso.

Comunque studiare ssh non è tempo perso, ci si fanno tante cose ganze, come ad esempio il tunneling

   
2. Paperino
giovedì 21 ottobre 2010 alle 1:50 AM - chrome 6.0.472.63 Windows 7
   

In realtà il problema nasce dal fatto che una parte dello stack (il client SSH o la libreria cygwin) non riesce a mappare le cose correttamente, ma il mio rimproverò è 

  1. se è un warning, grazie per avermi avvisato, ma lasciami continuare
  2. se non è un warning, scrivilo che è un errore e proponiti di sistemarlo

   
Lascia un commento:
Commento: (clicca su questo link per gli smiley supportati; regole di ingaggio per i commenti)
(opzionale, per il Gravatar)