Sign in to follow this  
Lord TIGER

chiavi RSA con SSH

Recommended Posts

Ultimamente ho acquistato anche un Mac mini da utilizzare come file server e media center (e varie ed eventuali) per non tenere perennemente acceso il portatile, e da qualche giorno sto provando a gestire completamente il piccolo dal mio portatile.

Ora, seguendo diverse guide (IKEE), so connettermi via web ad eMule, via VNC con indirizzo locale (della forma COMPUTER.local o 192.168.1.x) e tramite DynDNS (COMPUTER.dyndns.org/info), ed anche tramite un tunnel SSH, del tipo

ssh -p 22 -L 5911:localhost:5900 -f -N [email protected]_ADDRESSvnc://localhost:5911

Da qualche giorno ho scoperto che, nel collegamento via SSH al server, è possibile autenticarsi senza dover ogni volta inviare a questi la password, ma facendosi riconoscere inviando solo la prima volta la propria chiave identificativa, ovvero una RSA KEY.

Ho seguito diversi tutorial su internet (1, 2, 3, 4, 5) che, sebbene con parole o metodi leggermente differenti l'uno dall'altro, dicono la stessa cosa: creare una chiave sul client e passarla sul server (opportunamente aggiungendola a ~/.ssh/authorized_keys o ~/.ssh/authorized_keys2, a seconda della versione di SSH usata).

Il punto è che alla prima connessione dal client il server viene aggiunto correttamente al file ~/.ssh/known_hosts (e la chiave del client sul server) ma, anche dopo la prima connessione, il server continua a chiedere la password dell'utente (del server) e sembra ignorare la chiave identificativa del client.

Ho provato ad aggiungere (sul server) la chiave sia con un

cat id_rsa.pub >> authorized_keyscat id_rsa.pub >> authorized_keys2
sia con

scp ~/.ssh/id_rsa.pub [email protected]_ADDRESS:~/.ssh/authorized_keysscp ~/.ssh/id_rsa.pub [email protected]_ADDRESS:~/.ssh/authorized_keys2

Ho provato inoltre a modificare i permessi dei file authorized_keys, authorized_keys2, id_rsa, id_rsa.pub... ma nulla è servito!

Infatti una normale connessione, in queste differenti forme

ssh [email protected]_ADDRESSssh -l SERVER_USER SERVER_ADDRESSssh -i ~/.ssh/id_rsa.pub [email protected]_ADDRESSssh -i ~/.ssh/id_rsa.pub -l SERVER_USER SERVER_ADDRESS
richiede sempre e comunque la password (ho provato a mettere id_rsa, id.rsa.pub, id_dsa, id_dsa.pub, ma non cambia nulla).

Avviando la connessione con l'opzione "-v"

ssh -v [email protected]_ADDRESS
pare ke il client provi ad inviare la propria chiave identificativa, che viene ignorata, quindi appare il prompt per la password dell'utente del server cui ci si connette:

OpenSSH_4.7p1, OpenSSL 0.9.7l 28 Sep 2006debug1: Reading configuration data /etc/ssh_configdebug1: Connecting to SERVER_ADDRESS [192.168.1.x] port xx.debug1: Connection established.debug1: identity file /Users/Angel/.ssh/identity type -1debug1: identity file /Users/Angel/.ssh/id_rsa type 1debug1: identity file /Users/Angel/.ssh/id_dsa type 2debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7debug1: match: OpenSSH_4.7 pat OpenSSH*debug1: Enabling compatibility mode for protocol 2.0debug1: Local version string SSH-2.0-OpenSSH_4.7debug1: SSH2_MSG_KEXINIT sentdebug1: SSH2_MSG_KEXINIT receiveddebug1: kex: server->client aes128-cbc hmac-md5 nonedebug1: kex: client->server aes128-cbc hmac-md5 nonedebug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sentdebug1: expecting SSH2_MSG_KEX_DH_GEX_GROUPdebug1: SSH2_MSG_KEX_DH_GEX_INIT sentdebug1: expecting SSH2_MSG_KEX_DH_GEX_REPLYdebug1: Host 'SERVER_ADDRESS' is known and matches the RSA host key.debug1: Found key in /Users/Angel/.ssh/known_hosts:2debug1: ssh_rsa_verify: signature correctdebug1: SSH2_MSG_NEWKEYS sentdebug1: expecting SSH2_MSG_NEWKEYSdebug1: SSH2_MSG_NEWKEYS receiveddebug1: SSH2_MSG_SERVICE_REQUEST sentdebug1: SSH2_MSG_SERVICE_ACCEPT receiveddebug1: Authentications that can continue: publickey,password,keyboard-interactivedebug1: Next authentication method: publickey debug1: Offering public key: /Users/Angel/.ssh/id_rsadebug1: Authentications that can continue: publickey,password,keyboard-interactivedebug1: Offering public key: /Users/Angel/.ssh/id_rsadebug1: Authentications that can continue: publickey,password,keyboard-interactivedebug1: Offering public key: /Users/Angel/.ssh/id_rsadebug1: Authentications that can continue: publickey,password,keyboard-interactivedebug1: Trying private key: /Users/Angel/.ssh/identitydebug1: Offering public key: /Users/Angel/.ssh/id_rsadebug1: Authentications that can continue: publickey,password,keyboard-interactivedebug1: Offering public key: /Users/Angel/.ssh/id_dsadebug1: Authentications that can continue: publickey,password,keyboard-interactivedebug1: Next authentication method: keyboard-interactivePassword:

Ah, ovviamente ho provato (e sono 2 o 3 giorni ormai) tutti i modi possibili descritti nei tutorial che ho elencato, sempre cancellando completamente la directory .ssh sia dal client che dal server (con un rm -fR ~/.ssh, quindi...) e ricominciato sempre da capo, provando anche la procedura invertendo il client e il server!

Infine oggi ho seguito passo passo anche la procedura fornita da Federico Corazza qui su Tevac con l'ausilio di SSH Helper, ma con gli stessi pessimi risultati...

È un problema mio di configurazione interna, del server OPENSSH, di permessi? Faccio qualche errore nell'immettere i parametri?

Qualcuno saprebbe aiutarmi?

Chiedo immensamente venia per la prolissità del mio post e ringrazio anticipatamente chiunque voglia darmi una mano...

Share this post


Link to post
Share on other sites

ERRATA CORRIGE

Infine oggi ho seguito passo passo anche la procedura fornita da Federico Corazza qui su Tevac con l'ausilio di SSH Helper, ma con gli stessi pessimi risultati...

La procedura cui mi riferisco è qui.

Share this post


Link to post
Share on other sites

Trovata la soluzione, sperando possa servire a qualcuno nel caso dovesse verificarsi lo stesso problema mio.

Ho creato un secondo account (non amministratore, ma ciò non influisce sul risultato finale), creato la directory .ssh nella home e copiatovi il file id_rsa.pub, generato sulla macchina client, come authorized_keys2.

Chiedendo la connessione con ssh, quindi, viene bypassata la richiesta della password in quanto il client è riconosciuto come fidato grazie alla propria chiave pubblica RSA.

Pensavo il problema fosse del fatto che l'account usato (quello del server) fosse amministratore, o che facesse conflitto perché avente lo stesso nome di quello del client, ma non c'entrava nulla.

Infatti, ho eliminato l'account del server, salvando prima tutto, creatone uno nuovo con lo stesso nome e stessa cartella Inizio del vecchio, ritrasferito i file (immagini, video, etc.) e copiato la chiave RSA del client.

Ebbene, funziona tutto...

Sembra strano, eh?!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this