Newsgroup: it.comp.os.linux.ubuntu
Titolo: Rsync senza richiesta di password

Salve, ho un problema con Rsync e SSh. In poche parole non riesco a 
stabilire una connessione senza richiesta di password.
Ho letto molti tutorial su questo argomento, ma non ho ancora risolto il 
problema.Tipo questo:
http://www.montellug.it/wiki/index.php/How-to_login_in_SSH_con_una_chiave_criptografica
Ho provato a rigenerare la chiave.
ssh-keygen -t dsa -b 1024 -f chiave-ssh
Come da tuturial l'ho messa sul server e inserita nel file 
.ssh/authorized_keys
Ho controllato le impostazione di /etc/ssh/sshd_config I parametri 
importanti dovrebbero essere:
RSAAuthentication     yes
PubkeyAuthentication  yes
AuthorizedKeysFile    %h/.ssh/authorized_keys
PasswordAuthentication no
devo modificare qualcosa anche in ssh_config?
ho controllato i permessi sul file authorized_keys e sulla directory 
.ssh e sembrano a posto.
a quel punto ho provato rsync ma anche questa volta mi ha chiesto la 
password:
rsync -e "ssh -p222 -i chiave" -r --delete 
us...@xx.xxx.xxx.xxx:Pubblici/dir/ /home/user/dir_locale/
ho dovuto specificare la porta esatta. Non è quella standard.
Non avendo particolari problemi di sicurezza ho deciso poi di usare una 
password in chiaro specicificandola nell'opzione
  --password-file=passfile
ho creato il file (passfile) nella stessa dir in cui lancio rsync e ci 
ho messo semplicemente Pippo
in tutti questi casi sia se uso un rsync (o anche scp) sia che entro 
nella shell con ssh mi chiede la password.
Dato che vorrei automatizzare questa operazione con il crontab mi 
servirebbe bypassare la richiesta di password.
Credo di averle tentate tutte. I tutorial sono semplici, ma nessuno mi 
ha risolto il problema. Non so se potrebbe
essere dovuto ad altro: all'impostazione della porta 222, dal server in 
versione paranoica o da qualche passaggio che mi
sfugge e che non ho eseguito.
grazie per i consigli.

password:
Non ho verificato che tutto quel che hai scritto sia a posto, ma una
maniera che spesso ti aiuta a risolvere questi guai è fare un login ssh
con l'opzione -vv.  Se non basta, guarda il daemon.log e auth.log sul
server.

 
Per copiare la chiave sul server remoto puoi usare il wrapper
ssh-copy-id
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

 ssh-copy-id
un dubbio: la chiave pubblica (.pub) nel client dove deve stare? In 
~/.ssh/id_dsa.pub?
Io ho soltanto la chiave pubblica sul server (con il nome 
authorized_keys) nella cartella .ssh e la privata nella stessa cartella 
dove lancio Rsync

dove lancio Rsync
No, la privata la devi avere nella tua home sul server, dentro ~/.ssh

dove lancio Rsync
No, la privata la devi avere nella tua home sul client, dentro ~/.ssh, e
te la devi tenere cara.  Non metterla sui server su cui fai login.


grazie, allora il problema è un altro. :-/

 server.
te lo posto con i dati sensibili criptati. Se riesci a darmi una mano ti 
pago!!!
La terz'ultima riga è molto sospetta, non credi?
userzero@user0:~/sync$ rsync -e "ssh -p222 -i nuovachiave -vv" -r --delete
us...@xx.xxx.xxx.xxx:Pubblici/dir/ /home/userzero/dir
OpenSSH_4.3p2 Debian-8ubuntu1.1, OpenSSL 0.9.8c 05 Sep 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to xx.xxx.xxx.xxx [xx.xxx.xxx.xxx] port 222.
debug1: Connection established.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file nuovachiave type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7p1
Debian-8ubuntu1.2
debug1: match: OpenSSH_4.7p1 Debian-8ubuntu1.2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3p2 Debian-8ubuntu1.1
debug2: fd 3 setting O_NONBLOCK
debug1: Miscellaneous failure
No credentials cache found
debug1: Miscellaneous failure
No credentials cache found
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,
rijnda...@lysator.liu.se
,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,
rijnda...@lysator.liu.se
,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,
hmac-ri...@openssh.com
,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,
hmac-ri...@openssh.com
,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,
zl...@openssh.com
,zlib
debug2: kex_parse_kexinit: none,
zl...@openssh.com
,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,
rijnda...@lysator.liu.se
,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,
rijnda...@lysator.liu.se
,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,
uma...@openssh.com
,hmac-ripemd160,
hmac-ri...@openssh.com
,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,
uma...@openssh.com
,hmac-ripemd160,
hmac-ri...@openssh.com
,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,
zl...@openssh.com
debug2: kex_parse_kexinit: none,
zl...@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 127/256
debug2: bits set: 528/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'xx.xxx.xxx.xxx' is known and matches the RSA host key.
debug1: Found key in /home/userzero/.ssh/known_hosts:2
debug2: bits set: 521/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: nuovachiave (0x80054528)
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: nuovachiave
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
us...@xx.xxx.xxx.xxx's password:

Il 14/07/2010 14.35, Francesco Potortì ha scritto:

perché non funziona neanche se metto la pw in chiaro? Quale metodo 
alternativo all'uso delle chiavi posso utilizzare?
grazie

us...@xx.xxx.xxx.xxx's password:
Qualcosa non va con lo scambio di chiavi.  Prova un login con ssh con
-vv.  Il passo successivo è guardare i log sul server, come ti dicevo.
Il successivo è far partire il server ssh dall'altra parte con -D.
Comincia col primo passo.

 Comincia col primo passo.
sì scusa, ho fatto la prova sbagliata. Questa dovrebbe essere quella giusta:
ssh -p222 -i nuovachiave us...@xx.xxx.xxx.xxx -vv



debug2: bits set: 518/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'xx.xxx.xxx.xxx' is known and matches the RSA host key.
debug1: Found key in /home/userzero/.ssh/known_hosts:1
debug2: bits set: 525/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: nuovachiave (0x80054548)
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: nuovachiave
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
us...@xx.xxx.xxx.xxx's password:
Il file daemon.log è vuoto. In auth.log incollo le ultime righe. Dopo la 
richiesta di password ho premuto invio per non loggarmi. Il 
"blacklisted" è sospetto.
Grazie ancora
Jul 15 23:11:27 user sshd[22928]: Public key
15:01:b1:1c:b0:9c:f3:57:2b:81:5b:d7:51:0c:4f:fe blacklisted (see 
ssh-vulnkey(1$
debug2:23:11:29 0: winsshd[22928]: Failed password for user from 
yyy.yy.yyy.yyy port 56632 ssh2

yyy.yy.yyy.yyy port 56632 ssh2
Ah, quella chiave non va bene.  Tempo fa fu scoperto un baco in ssh, che
generava solo un numero limitato di chiavi.  fai
  man ssh-vulnkey
per la spiegazione completa.  La chiave che usi è una di quelle, devi
buttarla e rigenerarla.

 buttarla e rigenerarla.
ho provato da shell
"No manual entry for ssh-vulnkey"

"No manual entry for ssh-vulnkey"
Su Debian è nel pacchetto openssh-client.


devo aggiornarlo? Senza dover modificare nessun pacchetto cosa posso fare?

:

Per leggere la pagina di man?  Basta che la cerchi in rete con Google.
Hai buttato e rigenerato la chiave come ti dicevo?

:

Mi viene un sospetto.  Qual è la versione di openssh-client che stai usando?

 Mi viene un sospetto.  Qual è la versione di openssh-client che stai usando?
facendo;
  ssh -v
esce fuori:


.
A rigore non è necessario che tu aggiorni quel sistema, perché il suo
unico problema è la generazione di chiavi poco sicure (precisamente può
generare solo 32768 chiavi diverse).  Ma è *molto* importante che tu non
lo usi per generare delle chiavi.  Ed è importante che tu butti via le
chiavi che ci hai generato sopra a partire da settembre 2006.

 chiavi che ci hai generato sopra a partire da settembre 2006.
grazie, appena ne ho la possibilità faccio queste prove e ti faccio sapere
:)


sembra che adesso funzioni tutto! :)

:

Ricordati di verificare le chiavi che hai generato in quel periodo e buttale.