Entries for SSH

Configurar Gitosis

written by uve

28 November 2011

Gitosis es básicamente una herramienta que nos permite gestionar los accesos a repositorios Git. Esto lo realiza a través de SSH, gestionando el fichero authorized_keys del usuario gitosis.

Instalación

Para su instalación, bastará con ejecutar lo siguiente:

$ sudo apt-get install git-core gitosis

dependiendo de la versión de Ubuntu/Debian disponible, el paquete que contiene Git se puede llamar git o git-core.

Una vez instalado, vamos a dar acceso al administrador. Para ello, supongamos un usuario con permisos de administración llamado user.

$ sudo -H -u gitosis gitosis-init < /home/user/.ssh/id_user.pub
Initialized empty Git repository in /srv/gitosis/repositories/gitosis-admin.git/
Reinitialized existing Git repository in /srv/gitosis/repositories/gitosis-admin.git/

Ahora, desde el cliente, vamos a probar la conexión SSH:

$ ssh gitosis@miservidor.com

Si todo ha ido bien, tenemos el acceso al servidor, así que ya podemos cerrar la conexión SSH.

Añadir repositorios y usuarios

Lo primer es clonar el repositorio de administración. A través de él podremos controlar los repositorios y los usuarios de forma simple y sencilla.

$ git clone gitosis@miservidor.com:gitosis-admin.git
Cloning into gitosis-admin...
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 5 (delta 0), reused 5 (delta 0)
Receiving objects: 100% (5/5), done.

Aquí tenemos disponibles dos elementos claves:

  • gitosis.conf: Fichero de configuración
  • keydir: directorio con las claves públicas de los usuarios que tienen acceso

Vamos a crear otro repositorio nuevo llamado miproyecto, para ello editamos gitosis.conf:

[gitosis]

[group gitosis-admin]
writable = gitosis-admin
members = user

[group miproyecto]
writable = miproyecto
members = user member1 member2

Y añadimos las claves de los usuarios member1 y member2:

$ cd gitosis-admin
$ cp ~/member1.pub keydir/
$ cp ~/member2.pub keydir/

Ahora vamos a subir los cambios al servidor:

$ git add keydir gitosis.conf
$ git commit -m 'miproyecto con member1 y member2'
$ git push

Creando nuevos repositorios

Hasta ahora, hemos indicado a gitosis que habrá un nuevo repositorio y los usuarios que tienen acceso a él. Ahora vamos realmente a crear el repositorio. Todo esto se hace desde el lado del cliente:

$ git init miproyecto.git
Initialized empty Git repository in /home/member1/miproyecto.git/.git/
$ cd miproyecto.git/
$ git remote add origin gitosis@miservidor.com:miproyecto.git

Si tratamos de subir los cambios al servidor, nos indicará que el repositorio está vacío.

$ git push origin master
Initialized empty Git repository in /srv/gitosis/repositories/miproyecto.git/
error: src refspec master does not match any.
error: failed to push some refs to 'gitosis@miservidor.com:miproyecto.git'

Así que vamos a crear algo de contenido:

$ echo "" > README
$ git add README
$ git commit
[master (root-commit) 0dcec56] Initial commit
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 README
$ git push origin master
Initialized empty Git repository in /srv/gitosis/repositories/miproyecto.git/
Counting objects: 3, done.
Writing objects: 100% (3/3), 215 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To gitosis@miservidor.com:miproyecto.git
 * [new branch]      master -> master

Y con esto todo listo :)

Full entry >>

Habilitar IPv6 en OpenWRT

written by uve

19 August 2011

Una vez que tenemos OpenWRT instalado en nuestro router llega el momento de habilitar IPv6. Para ello, vamos a utilizar Stateless auto configuration. Para ello necesitaremos hacer uso de IPv4. Aunque todo esto se puede configurar desde LuCI (la interfaz web de administración que usa OpenWRT), usaremos SSH por comodidad.

Full entry >>

Configurando avisos automáticos por correo en Fail2Ban

written by uve

22 April 2011

Hace poco escribía sobre como instalar Fail2Ban para proteger nuestro sistema contra ataques por fuerza bruta. Un detalle interesante es que cada vez que se realice un bloqueo, se nos envíe un informe de forma automática con información de whois. Para ello debemos configurar lo siguiente:

#  nano /etc/fail2ban/jail.conf
...
destemail = admin@micorreo.com
action = %(action_mw)s
...

Después, reiniciamos el servicio y listo:

# service fail2ban restart

 

Full entry >>

Proteger tu servidor SSH contra ataques de fuerza bruta

written by uve

15 April 2011

Hoy he estado revisando los logs de mi servidor, y me he dado cuenta que llevan 5 días de ataques por fuerza bruta para intentar tener un acceso SSH. Seguro que a alguien le resulta útil este script:

import re
exp = re.compile(r'.*[\s]*sshd\[.*?\]:[\s]*Invalid user.*')
f = open('/var/log/auth.log')
for line in f.readlines():
    if exp.match(line):
        print line[:-1]

Este script nos mostrará todos los accesos fallidos que hay en el servidor. Ahora vamos a ver la forma más sencilla de impedir este tipo de ataques: fail2ban.

Full entry >>

Acceder a ficheros del aula de prácticas desde casa

written by uve

24 October 2010

Un pequeño post para refrescar a algunos como podemos acceder a ficheros que estén en los ordenadores del aula de prácticas desde casa. Es muy habitual que en algunas prácticas nos obliguen a trabajar con estos ordenadores y luego se nos olvide copiarnos el trabajo realizado.

Aquí vamos a recuperarlo todo desde casa, aunque bajo ciertas limitaciones. Para empezar debemos tener configurada la VPN y estar conectados.

Full entry >>

Securizando el servidor de Linode

written by uve

16 September 2010

Aprovechando la migración voy a tratar de escribir una serie de artículos acerca de algunos aspectos con los que he tenido que lidiar. Lo primero es preparar el acceso al servidor.

Cuando contratas un "Linode" (LInuxNODE, así es como llaman en Linode a los servidores que alquilan) debemos especificar una contraseña de root. Además, por defecto, el servidor SSH viene preparado para que podamos acceder.

Brevemente voy a hablar de dos aspectos importantes: el tratamiento de usuarios del sistema y la configuración del servidor SSH.

Full entry >>

Configurar un servidor SSH para no usar contraseña

written by uve

3 March 2010

En algunas ocasiones es necesario, o incluso conveniente, no utilizar contraseña para conectarnos a nuestro servidor SSH. Aunque SSH es un protocolo seguro (Secure SHell), es susceptible a ataques. Veamos como podemos reforzar la seguridad a la misma vez que automatizamos procesos que requieran SSH.

Full entry >>

La teoría es cuando crees saber algo, pero no funciona.
La práctica es cuando algo funciona, pero no sabes por qué.
Los programadores combinan la teoría y la práctica:
Nada funciona y no saben por qué.