Gitosis richiede la password, anche se la chiave pubblica viene dato

Question

sto confrontato con alcuni problemi quando si cerca di configurare gitosis sul mio Archlinux

http://wiki.archlinux.org/index.php/Setting_Up_Git_ACL_Using_gitosis

ho fatto riferimento a questo articolo wiki e gitosis installato con successo.

$ sudo pacman -U gitosis-git-20.090.525-1-i686.pkg.tar.gz
$ sudo -H -u gitosis gitosis-init < /tmp/id_rsa.pub

E modificato /srv/gitosis/.ssh/authorized_keys per includere id_rsa.pub del mio utente locale.

Ma quando ho eseguito git clone dell'utente locale,

$ git clone gitosis @ host: gitosis-admin.git

Dice

inizializzato repository Git vuoto in /home/wyx/gitosis-admin/.git/
gitosis@10.132.140.73 password: *****
fatale: 'gitosis-admin.git' non sembra essere un repository git
fatale: la fine remota riattaccato inaspettatamente

Così l'operazione git clone fallito. Mi chiedo perché tenta di inizializzare un repository git vuoto nella directory dell'utente locale (/ home/wyx)? E poiché ho già aggiunto id_rsa.pub dell'utente locale in .ssh/authorized_keys, perché chiede ancora la password?

Answer 1

Un repository vuoto è stato creato perché è così che funziona git: deve inizializzare un repository prima che possa iniziare a trascinare oggetti remoti in esso. Sfortunatamente questo significa che dovrai cancellare manualmente il repository vuoto prima di provare nuovamente a clonare.

Per quanto riguarda il motivo per cui il clone non è riuscito, sembra che si stia utilizzando la sintassi errata per il percorso del repository remoto; git clone non utilizza la sintassi scp. Infatti, se non si specifica un protocollo clone, credo che si presuma il protocollo git piuttosto che ssh, il che probabilmente sarebbe il motivo per cui ti ha chiesto una password. Prova a modificare:

 
$ git clone ssh://gitosis@host/~/gitosis-admin.git 

Answer 2

Gitosis crea un suo file authorized_keys. Se hai già quel file, cancellalo e consenti a gitosis-init di ricrearlo. Una volta fatto, non rovinare il file.

Answer 3

Ho anche affrontato lo stesso problema "fatale:" /gitosis-admin.git "non sembra essere un repository valido." Ho cercato molto per il problema e finalmente ho trovato la soluzione.

In realtà, l'indirizzo predefinito dell'utente gitosis è "/ srv/gitosis": Come nel caso della mia installazione con ubuntu server 10.04.

E quando scriviamo "git clone gitosis@server.com: gitosis-admin.git", cerca repository gitosis-admin.git in/srv/gitosis.Così, quando sono entrato all'interno della/srv/gitosis, ho scoperto che c'è un altro repository al suo interno chiamato come repository che consiste nella repository gitosis-admin.git.

Quindi, in realtà, per impostazione predefinita gitosis-admin.git non si trovava nella posizione predefinita. Quindi devo modificare il percorso del comando e poi ha funzionato bene.

Ho ottenuto il repository clonato sul mio computer locale. Ho usato il comando come:

"gitosis@server.com clone git: repository/gitosis-admin.git" e ha funzionato bene per me.

vedere per la directory gitosis-admin nel tuo caso e spero che sarà in grado di risolvere il problema.

Answer 4

finalmente ho potuto farlo funzionare come questo

git clone ssh://git@host:1337/home/git/repositories/gitosis-admin.git 

dove 1337 la Porta SSH sta usando.

Answer 5

Questo è ciò che risolto il problema per me (su Ubuntu):

git clone gitosis@ns.home:/srv/gitosis/repositories/gitosis-admin.git 

Answer 6

Ho avuto lo stesso problema su ubuntu,

Ha funzionato con git clone ssh://git@serverName/absolutePath/gitosis-admin.git

Answer 7

Modifica authorized_keys non dovrebbe essere necessaria normalmente.

una volta ho avuto un problema di autorizzazione, il server gitosis continuava a chiedermi la password, anche se avevo messo la mia chiave pubblica prima. Mi resi conto che gitosis mi ha dato un avvertimento "ATTENZIONE: gitosis.ssh: Unsafe nome utente SSH nel file di chiavi: 'myuser@myserver.pub'" quando ho cercato di impegnarsi e spingere le mie modifiche gitosis.

Cambiare la parte utente @ host nel file di chiavi e il nome del file di chiavi ha risolto il problema. in qualche modo la gitosi non piaceva quella precedente.

Answer 8

stesso problema, e nel mio caso era che avevo sbagliato authorized_keys in .ssh /. Devo averlo incasinato a un certo punto ...

Answer 9

Dopo essermi trasferito su una nuova macchina Ubuntu e aver risposto a questa domanda, ho visto qui un paio di risposte che mi hanno fatto muovere nella giusta direzione, cioè usare un assoluto percorso dei file .git per ciascun repository.

sperimentazione di un po 'ho notato percorsi relativi alla directory home dell'utente git anche lavorato, che accorciato qualcosa come:

git@host:/var/git/repositories/project.git 

verso il basso per

git@host:repositories/project.git 

Riproduzione di un po' di più ho provato a spostare il progetto file dai repository direttamente nella home directory di git; ora è richiesto solo il progetto:

git@host:project.git 

È un po 'hacky, ma dubito causerà danni. Sarebbe bello sapere cosa è cambiato, dato che stavo ospitando gitosi su un'altra Ubuntu (più vecchia) ed ero in grado di avere i progetti all'interno della directory dei repository con l'ultima notazione di cui sopra.

Answer 10

ho risolto un problema simile.Potrebbe non essere esattamente quello che sta accadendo nel tuo caso ma potresti provare a riapplicare la stessa risoluzione dei problemi che ho fatto.

Mi sono reso conto che quando stavo spingendo le chiavi per un nuovo utente stavo ottenendo questo stacktrace, che è il sintomo che l'hook on gitosis non è riuscito a elaborare la nuova chiave.

remote: Traceback (most recent call last): 
remote: File "/usr/local/bin/gitosis-run-hook", line 9, in <module> 
remote:  load_entry_point('gitosis==0.2', 'console_scripts', 'gitosis-run-hook')() 
remote: File "/usr/local/lib/python2.7/dist-packages/gitosis-0.2-py2.7.egg/gitosis/app.py", line 24, in run 
remote:  return app.main() 
remote: File "/usr/local/lib/python2.7/dist-packages/gitosis-0.2-py2.7.egg/gitosis/app.py", line 38, in main 
remote:  self.handle_args(parser, cfg, options, args) 
remote: File "/usr/local/lib/python2.7/dist-packages/gitosis-0.2-py2.7.egg/gitosis/run_hook.py", line 81, in handle_args 
remote:  post_update(cfg, git_dir) 
remote: File "/usr/local/lib/python2.7/dist-packages/gitosis-0.2-py2.7.egg/gitosis/run_hook.py", line 45, in post_update 
remote:  config=cfg, 
remote: File "/usr/local/lib/python2.7/dist-packages/gitosis-0.2-py2.7.egg/gitosis/gitdaemon.py", line 95, in set_export_ok 
remote:  for (dirpath, repo, name) in walk_repos(config): 
remote: File "/usr/local/lib/python2.7/dist-packages/gitosis-0.2-py2.7.egg/gitosis/gitdaemon.py", line 72, in walk_repos 
remote:  assert ext == '.git' 
remote: AssertionError 

L'errore è stato solo mostrando VOLTA, così ho ingenuamente respinto come un fallimento momentaneo.

In pratica, Gitosis stava lavorando solo per la mia chiave, ma non funzionava per nessuno degli utenti che stavo cercando di supportare. Nel ~/.ssh/authorized_keys non sono riuscito a trovare la chiave pubblica dell'utente che pensavo di aver appena aggiunto. Questo è il motivo per cui il mio amico ha continuato a chiedere la password ogni volta che tentava la clonazione.

ho aggiunto il debug alla configurazione Gitosis, con l'aggiunta di queste due linee di gitosis.conf

[gitosis] 
loglevel=DEBUG 

ho dovuto continuare ad aggiungere e rimuovere utenti al file gitosis.conf in modo che il gancio si sarebbe attivato di nuovo. Il mio registro di debug rivelato

remote: DEBUG:gitosis.gitdaemon:Deny 'syncShare' 
remote: DEBUG:gitosis.gitdaemon:Walking 'legacy.d', seeing ['buildtools', 'QA_Dashboard'] 
remote: DEBUG:gitosis.gitdaemon:Walking 'legacy.d/buildtools', seeing ['.git', 'conf', 'scripts'] 
remote: Traceback (most recent call last): 
etc ... 

A-ha! Mentre l'hook eseguiva il "walk" attraverso il repository, aveva trovato una directory .git sotto legacy.d/buildtools ed è esattamente dove si è verificato lo assert ext == '.git'.

Avevo utilizzato il server per archiviare un semplice clone da qualche altro repository. Si noti, un semplice clone, non uno specchio o un repository nudo. Come ogni clone conteneva la directory .git.

Il gancio in Gitosis non sa cosa fare con una directory .git. Pensa che si tratta di un deposito in un nome vuoto e abortisce. Una volta cancellato quel clone, tutto riprese a funzionare bene.

Answer 11

per guadagnare più la conoscenza delle tematiche Auth, si riuniscono verbose dettagli del registro di debug: utilizzando una diretta trick manuale-connect

ssh -vvv gitosis@gitosis_host

(che, formulata soprattutto/generalmente, utilizza effettivamente il più preciso/riferimento diretto al contesto, in questo caso: i meccanismi ssh reali piuttosto che lo strumento distanti - e quindi per necessità meno precisi - la gestione del git!).