Creacion de un RPM de OpenVpn desde los sources
1) conectarnos como root e ir al directorio de trabajo por ej:
cd /root
mkdir openvpn
cd openvpn
Para poder trabajar con llaves públicas, lo primero que tendremos que hacer será configurar el servidor de SSH para que las acepte. Habitualmente los archivos de configuración de OpenSSH se ubican en la carpeta /etc/ssh, en este caso, el archivo que nos interesa es /etc/ssh/sshd_config, lo abrimos con un editor de textos y corregimos los valores de las siguientes opciones relacionadas con las llaves públicas:
#RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys
La primera opción (RSAAuthentication) sirve para indicar cuando se permitirá autenticación RSA, está opción esta habilitada por defecto, y en el ejemplo está comentada porque sólo sirve para la versión 1 del protocolo SSH.
La segunda opción (PubkeyAuthentication) es la que especifica si se podrán usar llaves públicas para demostrar la autenticidad de un usuario. Si su valor es yes como en el ejemplo, entonces se podrán emplear las llaves públicas, si por el contrario su valor es no, entonces el uso de llaves públicas quedará prohibido.
La tercera opción (AuthorizedKeysFile) especifica el archivo que contiene las llaves públicas empleadas para la autenticación de los usuarios. Por defecto suele ser el archivo .ssh/autorized_keys, dentro de la carpeta personal de cada usuario.
Finalmente, en caso de haber alterado el archivo de configuración del servidor, para que los cambios sean efectivos, será necesario reiniciar el servidor de SSH.
Para poder crear nuevas llaves privadas y sus correspondientes llaves públicas, OpenSSH dispone de una herramienta llamada ssh-keygen, esta herramienta puede crear llaves RSA para el protocolo SSH versión 1, cuyo uso se desaconseja y aquí no se va a hablar de ellas, por otro lado, también puede generar llaves RSA o DSA para el protocolo SSH versión 2. Para especificar que tipo de llave crear, se emplea el parámetro -t seguido del tipo de llave: “rsa” o “dsa”. Por ejemplo, para crear una llave RSA podemos poner:
[linux@local] $ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/pablo/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/pablo/.ssh/id_rsa. Your public key has been saved in /home/pablo/.ssh/id_rsa.pub. The key fingerprint is: c0:40:50:27:e8:d9:b8:55:d6:a4:5f:af:e5:30:5d:9b hell@local [hell@local] $
Por el contrario, para generar una llave DSA, simplemente:
[linux@local] $ ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/pablo/.ssh/id_dsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/pablo/.ssh/id_dsa. Your public key has been saved in /home/pablo/.ssh/id_dsa.pub. The key fingerprint is: f5:b2:f3:2d:43:1b:22:44:98:6c:fe:42:df:a3:15:09 hell@local [linux@local] $
Los anteriores comandos piden los mismos datos, el primero, en donde salvar la llave privada, si simplemente pulsamos intro, se salvará en la ruta por defecto (la indicada entre paréntesis), a no ser que emplees varias llaves privadas, la ruta por defecto es una buena opción, ya que el cliente la usará sin necesidad de que el usuario tenga que especificarla.
Las siguientes dos cosas que pide son la frase clave con la que encriptar la llave privada y una petición de que se repita la frase para cerciorarse de que no se han cometido errores al escribirla la primera vez. Para la frase con la que encriptar la llave privada se puede emplear cualquier carácter (letras, numeros, signos de puntuación, espacios), en principio el tamaño de la frase puede ser arbitrario, pero ssh-keygen se quejará si es menor de cuatro carácteres. En caso de no introducir ninguna frase, la llave privada quedará sin encriptar, lo cual podria ser útil para realizar algunas automatizaciones como podría ser el realizar copias de seguridad, pero, para uso habitual, se desaconseja dejar las llaves privadas sin encriptar por el peligro que puede representar que estas sean robadas.
A continuación el ssh-keygen muestra donde se ha salvado la llave privada (/home/pablo/.ssh/id_dsa) y donde está la llave pública que le corresponde (/home/pablo/.ssh/id_dsa.pub), que no es más que el mismo nombre de archivo con la extensión .pub añadida al final.
En la última línea imprime una huella dactilar que sirve para identificar la llave que acabamos de crear, seguida de un comentario que puede servir para identificar la llave pública.
Despues de haber creado un juego de llaves privada y pública, nos encontramos con el dilema de que hacer con ellas, lo primero es mantener la llave privada secreta, por defecto ssh-keygen establecerá los permisos del archivo con esta llave para que sólo el dueño pueda leerla y modificarla. Por el contrario la llave pública podrá ser leida por cualquier usuario, pues por algo es pública.
Pero para poder autenticarnos en un equipo remoto con nuestra llave privada, lo único que tendremos que hacer es añadir nuestra llave pública en el archivo .ssh/authorized_keys dentro del directorio personal del usuario al que queremos acceder (generalmente $HOME/.ssh/authorized_keys).
El primer dilema que se nos plantea es el cómo enviamos nuestra llave pública al equipo remoto, una forma, en caso de que podamos acceder a el usando SSH con contraseñas de usuario para autenticarnos, sería mediante SCP, a modo de ejemplo, imaginemos que despues de crear el juego de llaves tenemos lo siguiente en nuestro directorio .ssh:
[linux@local] $ ls -1 ~/.ssh id_rsa id_rsa.pub [linux@local] $
De esta manera en la máquina remota tendremos el archivo mi_llave.pub que contiene nuestra llave pública, ahora tan sólo nos resta crear el directorio .ssh, en caso de que no exista, y añadir la llave pública al archivo $HOME/.ssh/authorized_keys, para ello, podemos conectarnos mediante SSH y usar el comando cat. Una sesión SSH a modo de ejemplo sería la siguiente:
[linux@local] $ ssh ejemplo.remoto.com
linux@remoto.ejemplo.com’s password:
[linux@remoto] $ mkdir .ssh
[linux@remoto] $ chmod 700 .ssh
[linux@remoto] $ cd .ssh
[linux@remoto] $ cat ../my_llave.pub >> authorized_keys
[linux@remoto] $
Ahora, la próxima vez que nos conectemos al servidor remoto.ejemplo.com, en lugar de pedirnos la contraseña del usuario, nos pedira la frase clave con la que la encriptamos nuestra llave privada:
[linux@local] $ ssh ejemplo.remoto.com Enter passphrase for key ‘/home/hell/.ssh/id_rsa’:
[linux@remoto] $
Por defecto, ssh-keygen genera llaves de 2048 bits, cuanto más grande sea una llave, más segura será. En la actualidad, ssh-keygen admite que las llaves tengan un mínimo de 512 bits y aunque en la página del manual no se indique, el máximo son 32768 bits, pero este último valor podría cambiar a medida que la potencia de los equipos informáticos se incremente. No obstante, con la liberación de la versión 4.3 de OpenSSH, sus desarrolladores decidieron fijar el tamaño de las llaves DSA a 1024 bits, pudiendo alterarse tan sólo el tamaño para las llaves RSA.
Por lo general el número de bits para la llave que escoge ssh-keygen por defecto es suficiente, pero para quienes prefieran otros valores, se puede especificar el tamaño de la llave con el parámetro -b seguido del número de bits que se desea que tenga la llave. Un ejemplo para generar una llave RSA de 4096 bits podría ser el siguiete:
[linux@local] $ ssh-keygen -t rsa -b 4096 Generating public/private rsa key pair. Enter file in which to save the key (/home/pablo/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/pablo/.ssh/id_rsa. Your public key has been saved in /home/pablo/.ssh/id_rsa.pub. The key fingerprint is: 4b:29:23:e9:20:c1:e5:32:6e:fa:b4:91:9a:01:b5:10 hell@local [linux@local] $
En el momento de su creación, ssh-keygen nos permite añadir un comentario a las claves públicas, por defecto el comentario que pone es del tipo usuario@máquina, pero podemos emplear el parámetro -C seguido del comentario que queramos, para así diferenciar más facilmente nuestra llave pública del resto de llaves. A modo de ejemplo, supongamos que queremos crear una clave de pruebas de tipo RSA con el comentario “Clave de pruebas”:
[linux@local] $ ssh-keygen -t rsa -C “Clave de pruebas”
Generating public/private rsa key pair.
Enter file in which to save the key (/home/pablo/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/pablo/.ssh/id_rsa.
Your public key has been saved in /home/pablo/.ssh/id_rsa.pub.
The key fingerprint is: 97:47:90:2d:b6:d9:ab:6d:91:41:ed:ad:dc:fb:a0:64 Clave de pruebas
[linux@local] $
En alguna ocasión nos veremos en la necesidad de querer cambiar la frase con la que una llave privada fue encriptada, o en el caso de que la llave privada no estubiese encriptada, querer encriptarla. Para conseguir este objetivo podemos invocar al programa ssh-keygen con el parámetro -p, veamos un ejemplo:
[linux@local] $ ssh-keygen -p
Enter file in which the key is (/home/pablo/.ssh/id_rsa):
Enter old passphrase: Key has comment ‘/home/pablo/.ssh/id_rsa’
Enter new passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved with the new passphrase.
[linux@local] $
En primer lugar nos pide la frase con la que está encriptada (old passphrase), a continuación, nos pide que introduzcamos la nueva frase (new passphrase), entre paréntesis, nos indica que si no ponemos nada, la llave privada quedará sin encriptar (empty for no passphrase). Después nos pide que repitamos la frase, para asegurarse de que no hemos cometido errores al escribirla la primera vez y finalmente, graba la llave privada encriptada con la nueva frase.
1. Identify all corrupted tables using myisamchk
# myisamchk /var/lib/mysql/bases/*.MYI > /tmp/mysqlchk_log.txt
and you have some output like this:
Read more…
How to manually purge
Exchange Server transaction logs
Exchange Server transaction logs are a key part of the way Exchange backups work. If a transaction log is missing from a backup set, or not available in an online backup, the Exchange restore operation will not be able to complete. Read more…
Choosing a backup type for Exchange
Choosing a backup type may seem complicated, but it’s not. The bottom line is that the amount of time required for a restore is roughly double the amount of time required to make the backup in the first place. Factor in your RTO to quickly determine how much time you can afford to do a restore, which in turn tells you how long your backup can take if you’re going to hit your SLAs and RTO. You can always tweak your backup solution’s hardware (for example, by adding more tape drives and striping data across them, or switching to a higher-capacity, faster solution), but the time required for the backup window will ultimately be the number one factor in determining your backup pattern.
Clearing the confusion around
Exchange Server circular logging
An issue that commonly confuses new Exchange Server administrators is circular logging. Because Microsoft’s circular logging recommendations have changed over the years based on Exchange Server version changes, there is a lot of contradictory information out there on the topic. In this article, I explain what circular logging is and the pros and cons of using it.
Read more…
Backing up Exchange Server with Microsoft VSS
One of the more significant improvements in Exchange Server 2003 is the ability to use Windows Server 2003’s Volume Shadow Copy Services (VSS) for backups. This tutorial explains how the VSS backup process works for Exchange and the pros and cons of implementing it.
To make Auth automatic via ftp make this:
on your home create a file named .netrc with 0600 perms and owned by you and put this info on this file:
[root@starwars ~]# cat /root/.netrc
machine ftp.domain.com login anakin password deathstar
and that’s all when you make an ftp -i ftp.domain.com
you can login without supply user and password
regards
Admin
First you need to create a blacklist, type the following command:
# wget -O - http://www.malware.com.br/cgi/submit?action=list_postfix > /etc/postfix/mbl-body-deny Read more…
Verificar el estado de las rutas actuales
# netstat -nr
Eliminar todas las rutas existentes
# route -f
(ojo no hacerlo remoto por razones obvias)
Read more…
