R3b3l10Nn

El uso de los túneles sobre ssh son una maravilla que puede ahorrarnos muchas configuraciones y tiempo. Lo importante es entender el mecanismo y las aplicaciones que tiene, las cuales son en función de nuestras necesidades. En mi experiencia personal, el uso que le he dado es en la instalación de software a través de un gateway que tiene salida a Internet, en vez de hacer la configuración y puesta a punto de repositorios de software locales o dentro de la misma red, ya que involucra descargar muchos paquetes, configuración de A pache u otro servidor web, o en su defecto, un servidor FTP . Hay diversos dos tiposde túneles , locales y remotos, los cuales dependiendo del sentido del envío/recepción de paquetes de red, será la solución a elegir, entre algunas otras consideraciones que salen del alcance de esta pequeña receta de cocina. Escenario. SO: RedHat 6, Centos 6 Supongamos que sólo un servidor tiene salida a Internet, los demás, por razones diversas...

Muchas veces es necesario, como administrador de middleware o de plataforma hacer la descarga periódica de logs. Está demás decir para qué puede servirnos retenerlos, pero una forma simple y fácil es como la siguiente. #!/bin/sh ######################################################################################## # # # Descarga los los de las aplicaciones administradas. # Lo ideal es que esté ejecutándose en un escheduler, como cron. # # 08 Septiembre 2016 # ######################################################################################## # Variables globales DIR_NAME=`date +'%B'` LAST_MONTH=`date +'%B' -d 'last month'` LAST_MONTH_NUM=`date +'%m' -d 'last month'` SUFFIX_LOG=`date +'%Y-%m'` # APP1 USER="remoteuser" SERVER_1="172.23.100.xxx" LOCAL_LOG_PATH="/home/lyonn/produccion/app1/log/$DIR_NAME" SERVER_REMOTE_LOG_PATH="/opt/jboss/app/myapp1/production/log/*$SUFFIX_LO...

Mi trabajo se va entre terminales, y no es que las odie, al contrario, son una elección de vida. Toda elección contrae desventajas. En mi caso, son las tareas repetitivas que día con día tengo que hacer. Una de las tareas que más odio, es autenticarme a cada cuenta, a cada servidor que tengo que acceder. Una forma de evitarlo es generar un par de llaves, una privada y una pública, para que el otro sistema confíe en nosotros. Lo primero es ejecutar el siguiente comando. Con él, generamos la llave privada y pública. Elegimos la ruta (yo la dejé por defecto), si queremos o no contraseña (¡¡yo no quiero más contraseñas!!) lyonn@mictlan:~$ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/lyonn/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/lyonn/.ssh/id_rsa. Your public key has been saved in /home/lyonn/.ssh/id_rsa.pub. The key fingerprint is...

En todas las distribuciones de GNU/Linux y Solaris he encontrado SSH como vía estándar de comunicación remota. ¿Por qué? Es simple de implementar, de utilizar y sumamente segura por su carácter de encriptación de los puentes que se hacen. No solo podemos sustituir Telnet, también podemos hacer túneles que nos permiten escapar de los firewalls restrictivos.  Al ser un punto de entrada,  por ello capital, es necesario aplicar ciertas políticas de seguridad, especialmente en aquellos sistemas que son productivos. Las siguientes políticas podrían ser útiles para tal tarea. No permitir validación de root Reducir la cantidad de usuarios que pueden autenticarse Sólo permitir la versión 2 de SSH Usar llaves para autenticarse El root es digamos que el usuario más perseguido en las intrusiones, pues su carácter casi bíblico lo hace ser el súper usuario, el usuario de usuarios. Para evitar que por algún descuido alguien pueda robarnos la cuenta, y robarnos lo que se...

Uso de rsync rsync nos sirve para syncronizar copias sin transmitir todo el contenido, sólo aquellos nuevos contenidos y los que fueron modificados. Se puede eliminar el contenido dónde se quiere depositar el nuevo, sin embargo, no sería tan flexible; aunque en algunos casos es necesario.  La transmisión de datos se hace a través del protocolo ssh, es decir, tenemos la certeza de su encripción y seguridad de que nadie que pueda interceptarlos pueda leer el contenido. Para hacer una copia del servidor local actualizando (dónde se ejecuta el comando) hacia el servidor objetivo (192.168.0.11, en mi caso) de la carpeta donde estoy situado ('.', se puede cambiar por la ruta que se requiera) $ rsync --update -a -e ssh . lyonn@192.168.0.11:rsynctest/ Si lo que se quiere es eliminar la antigua estructura, solo hay que cambiar la opción de update por delete . Pipes También es posibe ejecutar comandos remotos a través de ssh. Una de las formas útiles es con tuberías (pipes). Func...