Script para traducir textos desde la linea de comandos

Script para traducir textos desde linea de comandos
Script para traducir textos desde linea de comandos

Un script muy sencillo que nos permitira si queremos utilizar traducción instantaneo en nuestros pequeños programas de bash. Basicamente se hace uso de Google Translate Ajax API y de “curl” para hacer una petición HTTP con los parametros adecuados y se analiza la respuesta recibida, los parametros son el idioma “origen”, el idioma “destino” y el string que queremos traducir.

#!/usr/bin/env bash
#  gtranslate.sh
#  Translate using Google Translate Ajax API:
#  http://ajax.googleapis.com/ajax/services/language/translate?v=1.0 \
#  &langpair=en|es&q=hello+world
#  More Info: http://code.google.com/apis/ajaxlanguage/documentation/
#  ksaver (at identi.ca), March 2010.
#  Licence: Public Domain Code.

progname=$(basename $0)

if [ -z "$3" ]
then
	echo -e "Usage:   $progname lang1 lang2 'string of words to translate...'"
	echo -e "Example: $progname en es 'Hello World!'\n"
	exit
fi

FROM="$1"
TO="$2"

# Google Translate Ajax API Url
TRANSURL='http://ajax.googleapis.com/ajax/services/language/translate?v=1.0'
LANGPAIR="$FROM|$TO"
shift 2

# Parse string to translate, change ' ' to '+'
# STRING: String to translate.
STRING="$@"
PSTRING=$(echo "$STRING" |tr ' ' '+')

# Get translation
RESPONSE=$(/usr/bin/env curl -s -A Mozilla \
		$TRANSURL'&langpair='$LANGPAIR'&q='$PSTRING)

echo -n "$progname> "
# Parse and clean response, to show only translation.
echo "$RESPONSE" |cut -d ':' -f 3 |cut -d '}' -f 1

Redireccionar puertos en Linux usando SSH

En algunas ocasiones necesitamos acceder a algún servicio o aplicación que usa un puerto diferente al que por defecto tenemos permitido.

Imaginemos que estamos usando en nuestro trabajo nuestro portatil con Ubuntu y queremos actualizar repositorios o usar facebook, messenguer, etc … Estos servicios usan un puerto determinado que en principio si no podemos usar directamente se debe a la existencia en la red de un firewall que esta capando un puerto determiando.

Pues bien utilizando SSH , nos enseñana como podremos crear un tunel sobre dicho servidor externo y evitar el firewall, usando nuestra máquina como servidor local y redireccionando todas las salidas sobre el puerto especificado, es bastante sencillo y nos saltaremos el cortafuegos gustosamente:

El ejemplo que vamos a utilizar es el saltarnos un firewall, en nuestra red que capa el puerto que utiliza ubuntu para actualizar unos repositorios en un host concreeto.

Imaginemos que deseaba agregar el repositorio UbuntuGis para instalar algunos paquetes del mismo (Grass y Quantum GIS entre otros), pero al añadirlo:

sudo add-apt-repository ppa:ubuntugis/ppa

Si hay un firewal en la red que capa dicho puerto obtendriamos el siguiente error::
Executing: gpg –ignore-time-conflict –no-options –no-default-keyring –secret-keyring /etc/apt/secring.gpg –trustdb-name /etc/apt/trustdb.gpg –keyring /etc/apt/trusted.gpg –primary-keyring /etc/apt/trusted.gpg –keyserver keyserver.ubuntu.com –recv 6B827C12C2D425E227EDCA75089EBE08314DF160
gpg: requesting key 314DF160 from hkp server keyserver.ubuntu.com
gpgkeys: HTTP fetch error 7: couldn’t connect to host
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0

Executing: gpg –ignore-time-conflict –no-options –no-default-keyring –secret-keyring /etc/apt/secring.gpg –trustdb-name /etc/apt/trustdb.gpg –keyring /etc/apt/trusted.gpg –primary-keyring /etc/apt/trusted.gpg –keyserver keyserver.ubuntu.com –recv 6B827C12C2D425E227EDCA75089EBE08314DF160gpg: requesting key 314DF160 from hkp server keyserver.ubuntu.comgpgkeys: HTTP fetch error 7: couldn’t connect to hostgpg: no valid OpenPGP data found.gpg: Total number processed: 0

* Está capando el puerto 11371, el que usa el servidor de claves en la dirección: keyserver.ubuntu.com

Ahora bien para solucionar esto mediante un tunel con SSH hariamos lo siguiente:

1. Editamos el fichero /etc/hosts (como superusuario), en concreto la siguiente línea:
127.0.0.1 localhost keyserver.ubuntu.com

2. Guardamos y teniendo en cuenta que disponemos un servidor externo con un servidor SSH y sin restricciones en cuanto a firewall se refiere, lanzamos SSH con un tunel sobre el puerto 11371 local y redireccionando la salida sobre la dirección especificada (keyserver.ubuntu.com) y el mismo puerto. Tan sencillo como la siguiente línea (en este caso estoy usando el servidor de mi universidad, y nombre_usuario el nombre de mi usuario en el servidor ts.uco.es):

ssh nombre_usuario@ts.uco.es -L 11371:keyserver.ubuntu.com:11371

3. Nos autenticamos en el servidor y ya estamos preparados para agregar el repositorio, esta vez satisfactoriamente:

      blogofsysadmins.com@asubuntu:~$ sudo add-apt-repository ppa:ubuntugis/ppa
      [sudo] password for ahornero:
      Executing: gpg –ignore-time-conflict –no-options –no-default-keyring –secret
      keyring /etc/apt/secring.gpg –trustdb-name /etc/apt/trustdb.gpg –keyring
      /etc/apt/trusted.gpg –primary-keyring /etc/apt/trusted.gpg –keyserver
      keyserver.ubuntu.com –recv
      6B827C12C2D425E227EDCA75089EBE08314DF160
      gpg: requesting key 314DF160 from hkp server keyserver.ubuntu.com
      gpg: key 314DF160: “Launchpad ubuntugis-stable” not changed
      gpg: Total number processed: 1
      gpg:              unchanged: 1

¡Y listo!, ya tenemos una bonita forma de evitar un cortafuegos para un uso concreto, en este caso agregar un repositorio.

Secure Shell Hacks – Linux

E aqui una pequeña wiki de SSH¡¡¡

SSH hacks

Cómo me conecto por ssh sin contraseñas

En primer lugar es necesario generar una pareja de claves en tu máquina (‘client‘), en este caso ‘bender‘:

cesar@bender ~ $ ssh-keygen -t dsa

Te preguntará un passphrase que es recomendable introducir, aunque también se puede dejar en blanco. Tras esta operación obtendrás los ficheros:

cesar@bender ~ $ ls ~/.ssh
id_dsa
id_dsa.pub
known_hosts

El fichero ‘id_dsa‘ contiene la clave privada y no debería salir de tu ordenador. Debe tener permisos 600:

cesar@bender ~ $ chmod 600 .ssh/id_dsa

El fichero ‘id_dsa.pub‘ contiene tu clave pública. Para autorizar una clave pública en una máquina remota ‘kastor‘:

cesar@bender ~ $ cat ~/.ssh/id_dsa.pub | ssh kastor 'cat - >> .ssh/authorized_keys'

No olvides poner dos símbolos «>», puesto que en caso contrario te cargarás otras claves autorizadas en la máquina ‘kastor‘. La próxima vez que hagas ‘ssh kastor‘ entrará sin más. Si has puesto passphrase, tendrás que hacer primero:

cesar@bender ~ $ ssh-add

Solución de problemas

  • Sigue sin dejar conectarme: Asegúrate de que los permisos de ‘~/.ssh/authorized_keys‘ en la máquina remota son 644.
  • Cuando escribo ‘ssh-add‘ aparece el mensaje Could not open a connection to your authentication agent: La shell desde la que intentas conectarte no esta bajo el control del agente de autenticación.
  • Solucion rápida: Lanza una shell con el agente de ssh.
cesar@bender ~ $ ssh-agent bash
  • Solución mejor: lanza todas tus X bajo el ‘ssh-agent‘. Así todas las terminales colgarán de él.

El archivo /etc/hosts

Para un acceso rápido por ssh resulta muy útil definir alias de tus máquinas comunes en el fichero ‘/etc/hosts‘:

cesar@bender ~ $ sudo vim /etc/hosts
#
# Syntax:
#
# IP-Address  Full-Qualified-Hostname  Short-Hostname
#
192.168.1.4     kastor.zylk.net kastor

Esta operación requiere privilegios de administrador o superusuario.

Como manejar las llaves de ssh ? Uso de keychain

Una posibilidad es iniciar el ordenador en ‘init 3‘ sin X y redefinir tu ‘startx‘: Este es mi ‘~/bin/startx-ssh‘:

cesar@bender ~ $ vim ~/bin/startx-ssh
#!/bin/bash

keychain ~/.ssh/id_dsa || exit
source ~/.keychain/`hostname`-sh
startx

exit

Al iniciarlo, me pide el passphrase. Otra posibilidad es incluir estas dos líneas en tu archivo ‘.gnomerc‘ o similar en otros entornos gráficos.

keychain  ~/.ssh/id_dsa
source ~/.keychain/`hostname`-sh

Y ahora, si hago login desde otra máquina, o quiero que un cron pueda conectarse a otras máquinas, incluyo las siguientes líneas:

cesar@bender ~ $ source ~/.keychain/`hostname`-sh

Si quiero cerrar el acceso, hago:

cesar@bender ~ $ keychain --stop

Para volverlo a arrancar:

cesar@bender ~ $ keychain ~/.ssh/id_dsa

Cómo y por qué usar un túnel ssh?

Has trabajado alguna vez detrás de un firewall? Tienes una página web privada de una institución detrás de un firewall a la que sólo pueden acceder las máquinas de esa institución? Has intentado alguna vez mover un fichero desde detrás de un firewall a otra máquina que esta detrás de otro firewall? Entonces, lo que necesitas es hacer un túnel ssh.

La idea básica es que desde tu máquina (‘client.machine‘) tienes acceso a una máquina ‘bridge.machine‘ que no es a la que quieres acceder, pero que desde ella si podrías acceder a tu objetivo ‘target.machine‘. El túnel te permite operar de forma transparente desde ‘client.machime‘ hasta ‘target.machine‘. Hay dos tipos de túneles: túneles directos e inversos. En un túnel directo (forward) se hace corresponder un puerto de destino (‘dport‘) en la ‘target.machine‘, con un puerto local (‘lport‘) en tu máquina ‘client.machine‘. Esto se hace de la siguiente manera:

cesar@bender ~ $ ssh -NfL lport:target.machine:dport bridge.machine

Regla nemotécnica: acuérdate de la liga de futbol americano (NFL) y que la del medio es en minúscula.
HINT: Por cierto, aseguraros que el puerto local no está siendo usado, por ejemplo que apache este escuchando en ese puerto (aunque este mapeado con un virtual host deshabilitado). Por otro lado la opción verbose (-NfvL) puede ayudar en la traza de algún error.

Conectarse por ssh a target.machine

Primero construiríamos el túnel:

cesar@bender ~ $ ssh -NfL 6666:target.machine:22 bridge.machine

Y a continuación basta con hacer lo siguiente para entrar directamente en ‘target.machine‘:

cesar@bender ~ $ ssh -p6666 localhost

O bien:

cesar@bender ~ $ scp -P6666 fichero localhost:/el/path/que/te/venga/bien

Esto requiere que en tu ‘$HOME/.ssh/config‘ añadas la línea:

NoHostAuthenticationForLocalhost yes

Ejemplos de uso para los túneles ssh

Conexión a una web de una red privada

Si montas un servicio en un ordenador detrás de un firewall, este no va a estar disponible fuera porque en general los puertos estarán capados. Por ejemplo, una web dentro de una máquina de una red privada sin salida al exterior. A través de un túnel ssh se puede acceder a este servicio.

cesar@bender ~ $ ssh -NfL 8080:target.machine:80 bridge.machine

Después en el navegador, la web de ‘target.machine‘ estará disponible en ‘http://localhost:8080‘.

Conexión al LDAP de una red privada

cesar@bender ~ $ ssh -Nvf -L 9999:kastor.zylk.net:389 cesar@kastor.zylk.net

Aunque el puerto del LDAP (389) esta capado, yo puedo acceder a él desde fuera de la red si tengo un acceso a ‘kastor‘ haciéndolo pasar a través del puerto 22 (el del ssh) y mapeandolo a un puerto, digamos el 9999 en mi máquina local. Situación inicial:

               |             |
localhost:9999   ----------- | kastor.zylk.net:389
               |             |

Túnel:

               |          22 |                     |
localhost:9999   -----------   kastor.zylk.net:22    kastor.zylk.net:389
               |             |                     |

Una vez hecho el túnel, puedo configurar en mi agenda el acceso al LDAP con servidor localhost y puerto 9999. Nota: En realidad el proceso incorpora tres máquinas, la local, la de salida y la del servicio. Lo que pasa es que en este caso las dos ultimas son la misma.

Administrar el servidor CUPS de una red privada

Desde mi máquina:

cesar@bender ~ $ ssh -Nvf -L 63131:cups.zylk.net:631 cesar@kastor.zylk.net

Túnel:

               |          22 |                 |
localhost:63131   -----------   kastor.zylk.net   cups.zylk.net:631
               |             |                 |

De este modo me puedo conectar a la interfaz web de administración desde mi máquina en http://localhost:63131

Cómo definir tus propios hosts sin ser root?

Una situación bastante común es que tener acceso a una cuenta en una máquina sin privilegios de administrador o superusuario. Para conectarte a ‘kastor.zylk.net‘ con login ‘cesar‘:

cesar@bender ~ $ ssh cesar@kastor.zylk.net

La solución está en el fichero ‘$HOME/.ssh/config‘:

Host kastor
Hostname kastor.zylk.net
User cesar
Port 22
ForwardX11 no
Protocol 2,1

Host cups
Hostname localhost
User zylk
Port 9999

Con lo cual puedes hacer directamente:

cesar@bender ~ $ ssh kastor

El ssh sabe que tiene que conectarse a la máquina ‘kastor.zylk.net‘ y usar el login ‘cesar‘. Y ahora sabe que tiene que conectarse al puerto 9999 de ‘localhost‘ usando como login ‘zylk‘. Con esto tienes ya total transparencia en los túneles. Sobre todo si te haces un alias para levantarlo del tipo de:

cesar@bender ~ $ alias tncups='ssh -NfL 9999:cups.zylk.net:22 cesar@kastor'

Ejecutas el alias, que puedes copiar en tu ‘.bashrc‘:

cesar@bender ~ $ tncups

y te puedes conectar directamente a ‘cups.zylk.net‘ de forma transparente desde el exterior.

cesar@bender ~ $ ssh cups

Utilizando el sistema de ficheros sshfs

El objetivo es tener un sistema de ficheros remoto. Una especie de NFS o samba, pero seguro a través de ssh. Instalo sshfs:

$ sudo apt-get install sshfs

Me añado al grupo «fuse»:

$ sudo vi /etc/group

Luego ejecuto:

$ sshfs cesar@kastor.zylk.net:/data1/z-docs /mnt/z-docs/

Cómo conectarse unicamente via certificado?

Configurar el demonio de ssh de modo que sólo se puedan realizar conexiones ssh a la máquina si el usuario remoto está en la lista ‘authorized_keys‘.

$ sudo vim /etc/sshd_config
PasswordAuthentication no
UsePAM no

Por defecto esta opción está marcada como yes. También se puede definir donde están las listas autorizadas (claves públicas). Por defecto las define el usuario:

#AuthorizedKeysFile     %h/.ssh/authorized_keys

Reinicio el servicio:

$ /etc/init.d/sshd restart

Desactivar el login a root por ssh

Desactivo conexiones remotas ssh a la cuenta root, como medida de prevención de ataques ssh.

$ sudo vim /etc/sshd_config
PermitRootLogin no

Reinicio el servicio:

$ /etc/init.d/sshd restart

Enviar email cuando el usuario root se conecta por SSH

Una de las configuraciones que más utilizan los administradores de sistemas Linux es la configuración de envío de mail al administrador cuando se detecta un acceso del usuario root al sistema por medio de SSH.

Para ello lo primero que debemos hacer es encontrar un archivo de sistema en entornos Linux que sepamos se ejecuta cada vez que un usuario se conecta, es decir, cada vez que un usuario hace login. Como muchos de vosotros sabréis, ese archivo de sistema en Linux es el archivo oculto .bash_profile. Este fichero es leído y todos los comandos incluidos en él ejecutados cada vez que un usuario se conecta al sistema.

En este fichero podemos indicarle al sistema que cada vez que un usuario se conecte efectúe cierto número de acciones, entre ellas la que queremos configurar en esta ocasión, el envío del mail al administrador.

Como queremos que se envíe cuando se conecte el usuario root, debemos de modificar el fichero .bash_profile correspondiente. Para ello nos conectamos como root y nos dirigimos a al directorio root. Allí editamos .bash_profile con nuestro editor de texto preferido.

En este caso utilizaré nano:

Continuar leyendo «Enviar email cuando el usuario root se conecta por SSH»

Securizar acceso de ROOT en SSH

Seguimos con nuestros artículos sobre como asegurar el acceso SSH a nuestro servidor ya que es uno de los mayores puntos de acceso para posibles intentos de acceso por fuerza bruta, etc.

Normalmente, y como es lógico, estos ataques intentan la entrada con el usuario root, que por defecto es el único que tiene acceso total al servidor. ¿Cómo podemos hacer para dificultarles ese acceso? Pues bien, una de las maneras es quitando el acceso por SSH al usuario root. Y os preguntaréis, ¿y cómo administro el servidor sin usuario root? Pues muy fácil, creando un usuario que una vez dentro del sistema, pueda cambiar a root mediante el comando su. Pero mejor lo vamos viendo por pasos.

Lo primero que debemos hacer es asegurarnos de que existe el grupo wheel (suele venir creado por defecto pero en algunas distribuciones Debian parece ser que no está creado), y para ello debemos mirar si existe en el fichero etc/group. Si vemos que no existe esta línea, wheel:*:0:root,usuarios es que no está creado (donde “usuarios” son los usuarios pertenecientes al grupo). Otra forma de hacerlo es ejecutando el comando groups, que listará los grupos de usuarios del sistema. Si no existe el grupo, la forma más fácil de crearlo es editando el fichero etc/group y añadiendo la siguiente linea:

wheel:*:0:root,usuario_nuevo

Con esto ya estaríamos creando el usuario nuevo a parte del grupo. Si solo queremos crear el grupo:

wheel:*:0:root

Y después para crear el usuario:

adduser -G wheel -m -s /bin/bash -d /home/usuario_nuevo usuario_nuevo
passwd usuario_nuevo

-G wheel ->Crea el usuario dentro del grupo Wheel
-m ->se crea el directorio home si no existe
-s ->se le indica el shell del usuario
-d ->se le indica el nombre del directorio home del usuario

Con esto ya tenemos creado un usuario capaz de ganar privilegios de root mediante el comando su. Antes de continuar es aconsejable salir de SSH y probar si podemos ejecutar su con nuestro usuario_nuevo.

Continuar leyendo «Securizar acceso de ROOT en SSH»