La conexión a gitosis servidor a través de un túnel SSH

Question

Tengo un túnel SSH configuración en mi macbook, como este...

$ ssh -o ServerAliveInterval=3 -N -L 22222:gitosis-server:22 user@firewall.domain.com

Así que puedo ssh localhost:22222 y va a terminar en la gitosis-servidor detrás del firewall.

He creado un local id_rsa.pub archivo, copiado en el gitosis servidor(que se ejecuta Centos5), y lo importó a gitosis el uso de...

# sudo -H -u gitosis gitosis-init 

Fue un éxito, ya que puedo ver la clave pública en /var/lib/gitosis/.ssh/authorized_keys.


De vuelta en mi macbook me la instalación de un ~/.ssh/config archivo con el siguiente...

Host gitosis-server
Hostname localhost
HostKeyAlias gitosis-server.domain.com
  Port 22222


Así que...estoy pensando en este comando debería funcionar...

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

No obstante, como viene pidiendo una contraseña....cuando las claves públicas debería estar trabajando.

Initialized empty Git repository in /Users/USER/Development/gitrepo/gitosis-admin/.git/
gitosis@localhost's password: 


Cualquier idea sobre cómo obtener git de trabajo a través de un gitosis servidor detrás de un firewall?

Gracias,

Matt



EDITAR - Agregar Depuración De SSH Intento

Hice este comando, 'ssh-vvv gitosis@gitosis-server'.Tengo algo de depuración de la espalda y no parece como mi Identidad.

debug2: key: /Users/USER/.ssh/id_rsa.gitosis (0x1019b0)
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/USER/.ssh/id_rsa.gitosis
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
gitosis@localhost's password: 



EDIT 2

OK...sin duda una mala clave.He vuelto a revisar todas mis llaves de nuevo y, por supuesto, encontrar la gitosis-servidor fue la celebración de una mala clave en el archivo authorized_keys.


debug1:userauth-solicitud de usuario gitosis servicio ssh-método de conexión a ninguno
debug1:intento 0 0 fallos
debug1:PAM:inicialización para "gitosis"
debug1:PAM:configuración de PAM_RHOST a "firewall.domain.com"
debug1:PAM:configuración de PAM_TTY "ssh"
debug1:userauth-solicitud de usuario gitosis servicio ssh-método de conexión clavepublica
debug1:1 intento de fallas 1
debug1:prueba si pkalg/pkblob son aceptables
debug1:temporarily_use_uid:102/103 (e=0/0)
debug1:tratando de archivo de clave pública /var/lib/gitosis/.ssh/authorized_keys
debug1:restore_uid:0/0
debug1:temporarily_use_uid:102/103 (e=0/0)
debug1:tratando de archivo de clave pública /var/lib/gitosis/.ssh/authorized_keys2
debug1:restore_uid:0/0
Error clavepublica para gitosis de FUEGO.De la PARED.IP.DIRECCIÓN puerto 52453 ssh2

Me tomé una mirada más cercana en el archivo authorized_keys en el gitosis servidor....y fue incorrecta.He vuelto a revisar el archivo de clave pública que yo había copiado en /tmp de mi estación de trabajo y fue el correcto, pero diferente de lo que fue en authorized_keys.He eliminado el archivo authorized_keys en el servidor y reran el 'sudo -H -u gitosis gitosis-init < /tmp/id_rsa.gitosis.pub'.Comprueba el archivo authorized_keys de nuevo.....y todavía estaba equivocado.

He actualizado de forma manual mediante la edición de authorized_keys y la adición de la clave correcta, y luego me puse a trabajar desde mi estación de trabajo a través del túnel para uno o dos intentos.Entonces dejó de funcionar como antes.Volví en el archivo authorized_keys en el gitosis servidor, y por supuesto....gitosis había vuelto a la antigua clave que no funciona.

¿Por qué está haciendo esto....volver de nuevo a una mala clave pública....incluso después de que he intentado añadir que con el comando de arriba...que no cambie....entonces cambió de forma manual....que funcionó, pero git volvía a ser el malo de nuevo.

Es como gitosis mantiene recordar la primera llave que me metiera en el....y no me deja cambiarlo a la corrigió clave.

Frustrante...

Matt

Answer 1

Seguimiento:

No estoy seguro de por qué Gitosis insistido en la reutilización de una clave pública malo. Tratar de forzarlo a tomar la llave correcta no funcionó.

Así que hoy me acaba de quitar y volver a instalar el paquete gitosis en mi caja CentOS5.

yum remove gitosis
rm -rf /var/lib/gitosis
yum install gitosis
sudo -H -u gitosis gitosis-init < /tmp/id_rsa.gitosis.pub  #the correct key

En mi Mac, me SSH túnel localhost: 22222 a través del servidor de seguridad para Gitosis-servidor: 22.

$ ssh -o ServerAliveInterval=3 -N -L 22222:gitosis-server:22 user@firewall.domain.com

En mi Mac, he creado ~ / .ssh / config que se parece a esto ...

Host gitosis-server
Hostname localhost
IdentityFile ~/.ssh/id_rsa.gitosis
HostKeyAlias gitosis-server.domain.com
  Port 22222

A continuación, ... siguiendo las instrucciones en este sitio ...

http: / /scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way

... todo después ... "Aquí sucede algo mágico fresco Ejecutar este en el equipo local:." ... simplemente funciona ... excepto recuerde que debe reemplazar el nombre de usuario "git" con "gitosis".

Espero que todas esas tonterías ayuda a alguien. Gracias también por las sugerencias que llegué aquí .... que ayudó a reducir el problema.

Matt

Answer 2

Mi configuración para situación similar (trabajo)

He de configuración similar para repo.o.cz (que es por alguna razón null-ruta bloqueada por el ISP que yo uso, polaco ISP Telekomunikacja S. A.(tpnet)), y funciona para mí:

Yo ejecute el siguiente comando ejecutar para configurar SSH tunel antes de intentar conectar:

$ autossh -M 20000 -f -N -L 2222:repo.or.cz:22 user@gateway.example.com

(Yo uso autossh en lugar de ssh para volver a conectar si estoy desconectado, es decir,para mantener la conexión).Compruebe que corresponda identidades se agregan a la autenticación SSH-agent:

$ ssh-add -l
2048 d7:d3:69:f5:0f:f9:5e:aa:e0:0b:28:c2:03:42:09:66 /home/user/.ssh/id_dsa_gateway.example.com (DSA)
1024 11:a2:29:fe:37:12:a7:33:c4:23:b0:e1:82:92:e0:6a /home/user/.ssh/id_dsa_repo.or.cz (DSA)

Yo uso llavero para proporcionar contraseñas para mi las claves SSH sólo una vez, en el inicio de sesión.

Tengo el siguiente conjunto en mi ~/.ssh/config:

Host repo.or.cz
        # NoHostAuthenticationForLocalhost yes
        HostName localhost
        Port 2222

Esta configuración me funciona sin problemas.

---

La depuración de su situación

Como para la depuración de su situación?

En primer lugar, me gustaría comprobar si puedo iniciar sesión en la puerta de acceso con "ssh user@firewall.domain.com" para comprobar si el túnel SSH se puede configurar.Si estás en Linux puedes usar por ejemplo netstat --tcp para comprobar si hay conexión establecida con la puerta de enlace;en otros sistemas operativos y entornos usted puede encontrar utilidades similares.

Compruebe si puede conectarse correctamente a gitosis. (Si mal no recuerdo gitorious es el uso de gitosis para la gestión de acceso a través de SSH, así que he usado la respuesta de gitorious en el ejemplo a continuación)

$ ssh gitosis@gitosis-server
Need SSH_ORIGINAL_COMMAND
                             Connection to  closed.

Si no hace algo similar a la anterior (repo.o.cz devuelve "error fatal:¿Qué crees que soy yo?Un shell?", GitHub devuelve "Hola usuario!Usted ha autenticado correctamente, pero GitHub no proporciona acceso shell."), compruebe dónde se produce el error de ssh -v gitosis@gitosis-server":

$ ssh -v gitosis@gitosis-server
[...]
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/.ssh/id_dsa_gitosis-server
debug1: Remote: Forced command: gitosis-server user
[...]
debug1: Authentication succeeded (publickey)

Answer 3

Este es un tema ssh y (todavía) no una cuestión git.

ssh -v es su amigo, ya que le dará a depurar la información acerca de lo que los métodos de autenticación y las claves ssh está intentando utilizar.

Nueve de cada diez veces me parece que esto es un problema con los permisos de los archivos clave. ssh le gusta su directorio .ssh y su archivo id_rsa ser sólo puede ser escrito por 'usuario' y mi máscara de usuario permite que los archivos grabables grupo por defecto. ssh -v le dirá si este es el caso en su situación.

Editar

tiene un aspecto como el servidor sshd no acepta su identidad. No sé si tiene acceso al servidor remoto, pero el funcionamiento de un servidor sshd en modo de depuración podría ayudar.

Ejecutar algo como esto permite una conexión en el puerto determinado (de manera que no interrumpa el servicio sshd normal) y da salida a la información de depuración. Esto puede ayudar a depurar por qué el servidor no le gusta su identidad.

sshd -d -p 2022

Si su servicio 'normal' sshd se ejecuta con parámetros adicionales que asegúrese de proporcionar estas ayudas a la versión de depuración también.

Answer 4

Usted dice que puede ssh a localhost:2222 éxito. Para comprobar que ha configurado correctamente ~/.ssh/config, se puede ssh a solo gitosis-server?

ssh gitosis-server

Answer 5

He tenido un problema similar y lo resolví con:

[srydberg@zeus ~]$ echo $SSH_AUTH_SOCK
/tmp/keyring-KXX3Aw/ssh
[srydberg@zeus tmp]$ sudo rm -rf keyring-KXX3Aw/

Tal vez sus teclas se almacenan en caché allí?