$ ssh usuario.dominio@sistema
The authenticity of host 'sistema (10.22.31.45)' can't be established.
RSA key fingerprint is 7d:2f:1e:69:21:e9:06:f3:d9:fd:36:0a:9e:6c:47:10.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'sistema.dominio,10.22.31.45' (RSA) to the list of known hosts.
[usuario@sistema ~]$

Actualización 5/7/2010: Como en el ejemplo anterior, en todos los ejemplos que siguen veremos que el comando ssh no nos pregunta la contraseña porque hemos configurado Autentificación trasparente por clave pública/privada con OpenSSH.

Dicha clave se almacena en el fichero $HOME/.ssh/know_hosts:

$ tail -1 known_hosts
sistema.dominio,10.22.31.45 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAng/LUBaJa0qATdMMkmB3ufytR/BauKbCyz+Dvg0NMPUE2EF6zy5o3zSVMRlrgUmKakA3DoUez5oOaaSlR4d5ZZjOfsBmnn5dp7M0QtY681HYny1QQFUpRxNbARP3X8+2jlnWjOEBOmk+N8pRJCURUwkjSMs81ThAiZoIv8sVYYbNzKDpL8RaDTqEN0Xn+1dHJdeLrt+Hsl6GzX8f+SoWwkNVmt8Nc8T7vzrG93Xku6XXdOh5SKeTDXv+0shJUziPQApEwR0gcc+7L0hBEAw4GU1ctGnC22aVDkyqTKlbORq2YoufDErq+wv8lwgZKYd5AbOuvuwX7w9c8P+P+jKw==

Actualización 5/7/2010: Que aparezca el nombre de los hosts en claro en el fichero known_hosts es un problema de seguridad, ya que permite a un atacante que haya conseguido acceder a nuestro sistema conocer fácilmente otras máquinas que pueden ser objeto de ataque. Para evitar el problema, desde OpenSSH 4.0, es posible ofuscar el nombre de la máquina en el known_hosts con un hash. Sólo es necesario usar la opción “HashKnownHosts yes” en /etc/ssh_config o en $HOME/.ssh/config y ejecutar “ssh-keygen -H” para ofuscar el nombre de los hosts en nuestro known_hosts actual: Hashing the OpenSSH known_hosts File. Algunas distribuciones de Linux ya están implementando esto por defecto.

Si la máquina remota es víctima de algún tipo de ataque, si se ha reinstalado, si se ha sustituido por otra máquina con la misma IP o si, por cualquier motivo, la máquina remota no manda la clave de host que corresponde con la que tenemos almacenada, la próxima vez que intentemos conectarnos a ella, obtendremos un error como el siguiente:

$ ssh usuario@sistema.dominio
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
77:8b:3f:5c:95:18:30:2b:83:fe:21:73:d2:16:85:64.
Please contact your system administrator.
Add correct host key in /home/usuario/.ssh/known_hosts to get rid of this message.
Offending key in /home/usuario/.ssh/known_hosts:2
RSA host key for sistema.dominio has changed and you have requested strict checking.
Host key verification failed.

Y no podremos volver a conectarnos a menos que eliminemos la entrada vieja del known_hosts y volvamos a intentarlo. En dicho caso, volverá a pedirnos que aceptemos la nueva clave remota del host remoto, como al principio.

Si tenemos algún proceso no interactivo que se base en SSH, el que nos pregunte si aceptamos la clave del host remoto es un problema importante. En dichos casos, podemos evitar que nos lo pregunte y hacer que el ssh local la acepte siempre automáticamente poniendo el siguiente parámetro en el /etc/ssh_config (para todos los usuarios) o en el $HOME/.ssh/config (sólo para el usuario actual):

StrictHostKeyChecking no

Tras ponerlo comprobaremos que, efectivamente, la clave del host remoto se añade automáticamente al known_hosts la primera vez que accedemos a un nodo sin preguntar:

$ ssh usuario@sistema.dominio
Warning: Permanently added 'sistema.dominio,10.22.31.45' (RSA) to the list of known hosts.
[usuario@sistema ~]$

Pero esto puede no ser suficiente. Hay veces en las que la clave del host remoto siempre o muy a menudo cambia. Por ejemplo, puede ocurrir cuando hacemos un “ssh localhost” tras crear algún tipo de túnel que cada vez acabe en una máquina diferente (Creando túneles TCP/IP (port forwarding) con SSH: Los 8 escenarios posibles usando OpenSSH) o cuando trabajamos con multitud de máquinas físicas o virtuales (con éstas pasa especialmente a menudo) en las que reutilizamos frecuentemente la IP de unas máquinas en otras, etc.

Que la clave del host cambie frecuentemente es una simple molestia en sesiones interactivas (que nos obliga a buscar y a eliminar la entrada correspondiente del known_hosts), pero un auténtico problema cuando queremos usar ssh de forma no interactiva. En dichos casos, podemos solucionarlo usando el “StrictHostKeyChecking no” como antes, pero además, añadiendo ahora “UserKnownHostsFile /dev/null” en el $HOME/.ssh/config (no parece conveniente usarlo en el /etc/ssh_config y que aplique a todos los usuarios) para indicarle al comando ssh que en lugar de usar $HOME/.ssh/known_hosts para almacenar las claves de hosts, queremos usar /dev/null:

StrictHostKeyChecking no
UserKnownHostsFile /dev/null

Así conseguimos que, como las claves en realidad no se guardan, siempre que nos conectemos a una máquina se acepte automáticamente su clave de host, haya cambiado o no haya cambiado:

$ ssh usuario@sistema.dominio
Warning: Permanently added 'sistema.dominio,10.22.31.45' (RSA) to the list of known hosts.
[usuario@sistema ~]$ exit

$ ssh usuario@sistema.dominio
Warning: Permanently added 'sistema.dominio,10.22.31.45' (RSA) to the list of known hosts.
[usuario@sistema ~]$

Sobra decir que estas opciones suponen la eliminación de una medida de seguridad base del sistema SSH, con lo que se está más expuesto a posibles ataques.

:wq

Lo hice y lo entendí © Vicente Navarro 2010 con una licencia CC BY-SA | 9 comentarios
Etiquetas: Cygwin, GNU/Linux, OpenSSH, UNIX

Feed enhanced by Better Feed from Ozh

Para conseguir tal cosa, apenas es necesario descomentar unas líneas de la configuración por defecto de Samba en Debian y Ubuntu (/etc/samba/smb.conf) y releer la configuración (sudo /etc/init.d/samba reload):

# Un-comment the following (and tweak the other settings below to suit)
# to enable the default home directory shares.  This will share each
# user's home directory as \\server\username
[homes]
   comment = Home Directories
   browseable = no

Normalmente un usuario tiene en su $HOME todos los ficheros que pueda necesitar, pero en los PC a menudo tenemos otros sistemas de ficheros (unidades externas, particiones grandes que se comparten entre sistemas operativos, etc.) en los que los usuarios guardan otros ficheros. Por ejemplo, yo tengo unas particiones adicionales que suelo montar en /mnt/e y en /mnt/i con los permisos adecuados para que los usuarios puedan escribir en ellas. En el $HOME de los usuario tengo unos enlaces simbólicos a estos sistemas de ficheros:

vicente@servidorcifs ~ $ pwd
/home/vicente

vicente@servidorcifs ~ $ ll e i
lrwxrwxrwx 1 vicente vicente 7 2008-04-30 20:51 e -> /mnt/e/
lrwxrwxrwx 1 vicente vicente 7 2008-07-17 15:11 i -> /mnt/i/

Pues bien, ¿qué diríais que pasa cuando monto //servidorcifs/vicente/ desde otro sistema e intento acceder a //servidorcifs/vicente/e/ o a //servidorcifs/vicente/i/?

Pues que si intento acceder desde Windows, los enlaces e, i aparecerán como un directorio más al que puedo acceder y en donde encuentro los ficheros de /mnt/e/, /mnt/i/ que hay en la máquina. Este es el comportamiento deseado en este caso.

Sin embargo, si intento acceder desde otro Linux (con una versión reciente de Samba), tras montar el sistema de ficheros remoto:

vicente@clientecifs ~ $ sudo mount -t cifs -o username=vicente //servidorcifs/vicente /mnt/smb/

lo que ocurrirá es que en la máquina donde hemos montado el sistema de ficheros CIFS, los enlaces simbólicos e, i se verán como lo que son, enlaces simbólicos, y apuntarán a los directorios /mnt/e/, /mnt/i/ del cliente de CIFS, no del servidor de CIFS, con lo cual no tendremos acceso a los ficheros del usuario:

vicente@clientecifs ~ $ ll /mnt/smb/e /mnt/smb/i
lrwxrwxrwx 1 vicente vicente 7 2008-04-30 20:51 /mnt/smb/e -> /mnt/e/
lrwxrwxrwx 1 vicente vicente 7 2008-07-17 15:11 /mnt/smb/i -> /mnt/i/

vicente@clientecifs ~ $ cd /mnt/smb/e
-bash: cd: /mnt/smb/e: No such file or directory

(...)

Leer el resto de Samba/CIFS: Enlaces simbólicos y Unix CIFS Extensions (1,033 palabras)

Lo hice y lo entendí © Vicente Navarro 2009 con una licencia CC BY-SA | 7 comentarios
Etiquetas: GNU/Linux, Kernel, Samba, UNIX, Windows

Feed enhanced by Better Feed from Ozh

Sin embargo, en aquella entrada nos dejamos en el tintero el reenvío dinámico de puertos y varios lectores lo echaron de menos, de modo que esta entrada tratará de complementar a aquélla (muchas gracias a todos por la sugerencia).

Cuando hablamos de hacer dynamic port forwarding con SSH, de lo que estamos hablando exactamente es de convertir el SSH en un servidor SOCKS. ¿Y qué es un servidor SOCKS?

¿Sabes para qué sirve un proxy web? Probablemente sí, muchas empresas usan uno. Se trata de un sistema directamente conectado a Internet que permite que los clientes de una intranet sin acceso a Internet puedan navegar por la web si configuran sus navegadores para que hagan sus peticiones a través del proxy (aunque también hay proxies transparentes). Un proxy web, además de permitir la salida a Internet, también cacheará las páginas, imágenes, etc. ya descargadas por algún cliente para no tener que descargarlas para otro cliente. Además, permite filtrar los contenidos y monitorizar la actividad de los usuarios. Sin embargo, su función básica es la de reenviar tráfico HTTP y HTTPS.

Un servidor SOCKS le daría un servicio similar a la intranet de una empresa que el que proporciona un servidor proxy pero no está limitado a HTTP/HTTPS, sino que permite reenviar cualquier trafico TCP/IP (con SOCKS 5 también UDP).

Por ejemplo, imaginemos que queremos usar nuestro correo usando POP3 o ICMP y SMTP con Thunderbird desde una intranet sin acceso directo a Internet. Si sólo tenemos un proxy web disponible, la único sencillo que nos quedaría sería usar algún webmail (aunque si es un webmail también podríamos usar la extensión Webmail de Thunderbird). También podríamos aprovecharnos del proxy montándonos un túnel por HTTP. Pero lo más sencillo sería que la red tuviera un servidor SOCKS disponible que nos permitiera usar POP3, ICMP y SMTP a través de él sin ningún inconveniente.

(...)

Leer el resto de Reenvío dinámico de puertos / montar un servidor SOCKS con SSH (974 palabras)

Lo hice y lo entendí © Vicente Navarro 2009 con una licencia CC BY-SA | 5 comentarios
Etiquetas: GNU/Linux, OpenSSH, Redes, SOCKS, Thunderbird, UNIX, wget, Windows

Feed enhanced by Better Feed from Ozh

Como este tema está muy tratado por toda la red:

• Wikipedia: SSH Tunneling
• O’Reilly: Using SSH Tunneling
• ssh.com: Tunneling Explained
• ssh.com: Port Forwarding
• SecurityFocus: SSH Port Forwarding
• Red Hat Magazine: SSH Port Forwarding

en esta entrada no entraremos en los detalles del reenvío de puertos, sino que pretende ser una chuleta, una referencia rápida (cheat sheet) de cómo reenviar puertos TCP con OpenSSH en los 8 diferentes escenarios que se pueden dar. Otros clientes de SSH como PuTTY también permiten el reenvío de puertos, pero la configuración se hará con un interfaz gráfico. Nosotros nos centraremos en OpenSSH.

En los siguientes ejemplos y situaciones supondremos que tenemos una red externa y una red interna y entre ambas redes, la única conexión posible es una conexión SSH entre el nodo de la red external externo1 y el nodo de la red interna interno1. El nodo externo2 está en la red externa y tiene conectividad total con externo1. El nodo interno2 está en la red interna y tiene conectividad total con interno1.

(...)

Leer el resto de Creando túneles TCP/IP (port forwarding) con SSH: Los 8 escenarios posibles usando OpenSSH (1,089 palabras)

Lo hice y lo entendí © Vicente Navarro 2009 con una licencia CC BY-SA | 18 comentarios
Etiquetas: GNU/Linux, OpenSSH, Redes, UNIX, VNC

Feed enhanced by Better Feed from Ozh

Otros fabricantes desarrollaron otros tipos de terminales, con el mismo concepto, pero incompatibles con otros sistemas, como este HP 700/96, que aún se sigue usando en algunos CPD hoy en día:

Los ordenadores personales, como el PC y los Apple o los Commodore, Spectrum, Amstrad CPC, etc. siguieron otro camino para mostrar la información al usuario, ya que, o bien usaban un sistema de vídeo propietario para mostrar texto y gráficos (p.e. MDA o VGA), o bien se conectaban directamente al televisor.

Los grandes servidores UNIX (basados en AIX, HP-UX, Solaris, etc.) o similares (por ejemplo, basados en OpenVMS, o z/OS) han llegado a nuestros días permitiendo la conexión de un terminal serie para usar la consola, pero cada día es más infrecuente su uso, ya que han sido sustituidos por consolas LAN (accedemos por Telnet o por SSH a una dirección IP diferente a la propia del sistema) o por consolas Web (una página web donde nos aparece la consola), que, por supuesto, nos permiten interactuar con la máquina incluso durante el arranque y la parada.

Hoy en día los terminales serie están bastante en desuso. Sin embargo, los emuladores de terminal están en pleno apogeo, bien sean para conectarnos por Telnet, por SSH, o, por supuesto, por el puerto serie/módem (ya lo vimos en Configurar Linux para permitir el acceso remoto por módem a la consola y por RAS/PPP). Por cierto, ¿qué tipo de terminal emulan la mayoría de emuladores de terminal como mínimo? Pues, por supuesto, el famoso VT100. Pero como otros fabricantes hicieron otros terminales con sus propios protocolos, secuencias de escape y capacidades, hay múltiples tipos de emuladores de terminal. Las emulaciones de terminal ansi y vt100 (y tal vez xterm) son las más usadas.

(...)

Leer el resto de Emuladores de terminal. GNU screen: El multiplexador de sesiones de terminal. (1,373 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 21 comentarios
Etiquetas: GNU screen, GNU/Linux, PuTTY, termcap, terminal, terminfo

Feed enhanced by Better Feed from Ozh

Si lo pensamos detenidamente, tener una partición de swap, es tener una cantidad de espacio ahí abandonada y que en rarísimas ocasiones veremos usar. Y si el kernel llega a usarla, hemos de prepararnos, en la mayoría de los casos, a experimentar un sistema extraordinariamente pesado, con lo que si es una situación habitual, más nos vale comprar una ampliación de la memoria. De nuevo, recalcar que me refiero a sistemas domésticos. En un servidor, la memoria swap nos puede ayudar a absorber un pico puntual de trabajo que sólo se da en ocasiones aisladas y que no podemos dejar de atender.

Para nuestro sistema doméstico, resulta mucho más conveniente un fichero de swap, igual que hacen todos los Windows basados en NT con el pagefile.sys. Las ventajas son muchas:

• Lo podemos poner en la partición/sistema de ficheros que queramos
• Podemos borrarlo para liberar espacio si éste nos hace falta
• Podemos crear uno nuevo en cualquier momento
• No supone tener un espacio en disco bloqueado inservible para otros propósitos
• Posiblemente su rendimiento sea algo peor que el de una partición dedicada de swap, pero si la memoria swap llega a tener que usarse intensivamente, el rendimiento será ya nefasto, ¿qué más da que sea un poco peor?

Y, además, lo último, lo de que el rendimiento es peor parece que ni siquiera es cierto. En la LKML leemos que usando kernels 2.6 el rendimiento de un fichero de swap no es peor que el de una partición de swap (Jesper Juhl: a swap file is just as fast as a swap partition):

With a 2.4.x kernel swap files were slower than swap partitions, but with the 2.6 kernel a swap file is just as fast as a swap partition.

(...)

Leer el resto de Memoria swap en un fichero. ¿Cuánta memoria swap necesitamos? (2,097 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 15 comentarios
Etiquetas: dd, GNU/Linux, HP-UX, Kernel, memoria RAM, rendimiento, swap, sysstat, UNIX

Feed enhanced by Better Feed from Ozh

La última vez que he sido consciente de mi enorme desconocimiento ha sido esta semana, cuando fruto de un comportamiento que me parecía ilógico me enredé con manuales y documentación de diferentes shells. ¿Habrá mucha gente capaz de dominar casi todos los aspectos de la shell?

Vayamos al grano… El problema que tuve fue que un script muy sencillo que en ksh funcionaba sin problemas, en bash no hacía lo que esperaba. El problema estaba en una línea como esta:

comando | read a b c

(...)

Leer el resto de Redirigir la salida de un comando a un read con una tubería (pipe) (1,288 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 4 comentarios
Etiquetas: GNU/Linux, shell, UNIX

Feed enhanced by Better Feed from Ozh

rsync es una herramienta para sincronizar los ficheros y directorios que tenemos almacenados en un sitio en otro diferente minimizando la transferencia de datos (Wikipedia: rsync). En realidad, rsync son dos cosas: un algoritmo de delta compression para sincronizar dos ficheros similares y una utilidad que usa dicho algoritmo junto con otras técnicas para hacer mirroring de ficheros y directorios en otro sitio transfiriendo la mínima cantidad de datos posible.

(...)

Leer el resto de Backups con rsync (3,566 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 82 comentarios
Etiquetas: backup, Cygwin, GNU/Linux, OpenSSH, rsync, Windows

Feed enhanced by Better Feed from Ozh

Cómo hacer esto en concreto varía entre implementaciones de cliente y servidor de SSH, pero si estamos usando OpenSSH, que es lo estándar tanto en Linux y *BSD, como en Cygwin, sólo hay que seguir unos sencillos pasos que vamos a ver a continuación.

(...)

Leer el resto de Autentificación trasparente por clave pública/privada con OpenSSH (534 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 11 comentarios
Etiquetas: Debian, GNU/Linux, OpenSSH, PuTTY, SSH

Feed enhanced by Better Feed from Ozh

El puerto de red asignado al syslog es el 514/UDP:

# grep syslog /etc/services
syslog          514/udp

Sin embargo, el proceso syslogd de Debian no se conecta a ese puerto porque no escucha mensajes de la red por defecto. Si queremos que lo haga, tenemos que editar el fichero /etc/default/syslogd, que en la configuración estándar no contiene ninguna opción:

# For remote UDP logging use SYSLOGD="-r"
#
SYSLOGD=""

Si queremos que escuche de la red, hemos de especificar la opción -r:

# For remote UDP logging use SYSLOGD="-r"
#
SYSLOGD="-r"

que sirve precisamente para esto:

       -r     This option will enable the facility to receive message from the
              network using an internet domain socket with the syslog  service
              (see  services(5)).   The default is to not receive any messages
              from the network.

y reiniciar el proceso con “/etc/init.d/sysklogd restart“. Tras esto, podremos comprobar que el demonio funciona con la opción deseada

# ps -ef | grep syslog
root      4547     1  0 17:35 ?        00:00:00 /sbin/syslogd -r

y que el proceso está escuchando en el puerto 514/UDP:

# netstat -a | grep syslog
udp        0      0 *:syslog                *:*

Puesto que los mensajes del Zyxel van a llegar por la facility local2, podemos querer establecer un fichero de log específico para él en el /etc/syslog.conf (para que se relea después de modificarlo, haremos un “/etc/init.d/sysklogd reload“):

local2.* /var/log/zyxel.log

Si quisiéramos que fuera un sistema Linux (por ejemplo, una Debian) el que mandara ciertos mensajes a un syslog remoto, podríamos hacerlo simplemente poniendo en el syslog.conf una línea como:

local3.* @sistemaremoto.dominio

Tras releer la configuración, con una sencilla prueba con el comando logger:

logger -p local3.info "Mensaje de prueba"

veremos que, efectivamente, el mensaje aparece en el sistema remoto en varios logs configurados para recibir mensajes de la prioridad formada por la pareja facility/level que hemos especificado:

# grep "Mensaje de prueba" /var/log/*
/var/log/messages:Dec  8 18:18:15 ordenador logger: Mensaje de prueba
/var/log/syslog:Dec  8 18:18:15 ordenador logger: Mensaje de prueba

Recordemos que las facilities son:

• auth, security ¹
• authpriv
• cron
• daemon
• ftp
• kern
• lpr
• mail
• mark (sólo para uso interno)
• news
• sys-log
• user
• uucp
• local0 → local7

y los levels:

• debug
• info
• notice
• warning, warn ¹
• error, err ¹
• crit
• alert
• emerg, panic ¹

1. En los casos en que aparecen dos etiquetas juntas, la segunda es equivalente a la primera y está obsoleta.

Si tomamos una traza de red vemos que el protocolo (BSD syslog Protocol) es extraordinariamente sencillo (RFC 3164):

Podemos ver que la prioridad es un byte que contiene la facility (5bits) y el level (3bits).

Con un simple netcat también podemos mandar mensajes a un syslogd remoto que esté escuchando la red, aunque no pongamos la cabecera con la prioridad y la fecha del evento:

# echo "Nuevo mensaje de prueba con el netcat" | netcat -q 0 -u 192.168.1.20 514

y en el /var/log/syslog remoto encontramos el mensaje:

Dec  8 18:39:15 ordenador Nuevo mensaje de prueba con el netcat

:wq

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 9 comentarios
Etiquetas: Debian, GNU/Linux, syslog, UNIX, Zyxel 660HW

Feed enhanced by Better Feed from Ozh

Los PCs no están bien preparados para tener como única posibilidad de entrada/salida un terminal serie. Al menos no durante el arranque y para configurar la BIOS. Una vez que el sistema operativo o el GRUB toma el control ya sí que podemos usar el puerto serie para gestionar el ordenador. Pero es precisamente en circunstancias muy dramáticas cuando nos puede interesar especialmente controlar el arranque remotamente. Por eso hay fabricantes de servidores x86 cuyos sistemas permiten redirigir la salida de la BIOS a un puerto serie, como por ejemplo la HP BIOS Serial Console. Para ampliar información sobre servidores con esta posibilidad, podemos leer sobre IPMI y sobre Out-of-band management o Lights-out management. En la web en japonés sobre la tarjeta Lights-Out 100 de HP podemos ver capturas de una BIOS por el puerto serie.

En cualquier caso, en PCs normales no tenemos esta posibilidad. El primer momento en el que podemos comenzar a redirigir la salida estándar es en el GRUB. El segundo momento es al arrancar el kernel de Linux. El tercero es cuando el sistema operativo ya está totalmente arriba.

Veamos cómo acceder a la consola por el puerto serie una vez que el sistema está arriba y luego veremos qué dificultades presentan los otros casos.

(...)

Leer el resto de Configurar Linux para permitir el acceso remoto por módem a la consola y por RAS/PPP (2,559 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 18 comentarios
Etiquetas: consola, Debian, GNU/Linux, GRUB, minicom, modem, PPP, RAS, terminal, UNIX

Feed enhanced by Better Feed from Ozh

vnavarro@DARKSTAR ~
$echo $TERM
cygwin

Cada tipo de terminal supone una forma diferente de hacer scrolling, de mover las líneas por la pantalla, los retornos de carro y de línea, de borrar el carácter anterior, de limpiar la pantalla, de conocer el número de líneas y columnas, de cómo usar colores y si se pueden usar, etc. Para la mayoría de aplicaciones de línea de comandos típicas de UNIX (por ejemplo, ls, awk, sed, grep, cat, mv, cp), todas estas especificaciones son indiferentes: Ellas toman la información que necesitan de sus argumentos de la línea de comandos o de la entrada estándar y sacan los resultados a través de la salida estándar y del código de error. Pueden incluso funcionar sin un terminal. Sin embargo, hay muchas otras aplicaciones que tienen que conocer muy bien cómo mover y posicionar texto por el terminal, como por ejemplo el vim, el mc, o el top.

Para que las aplicaciones que lo necesiten puedan interactuar con los múltiples tipos diferentes de terminales, las aplicaciones pueden usar, bien la librería Termcap, bien la librería ncurses junto con la base de datos de terminales Terminfo.

El Terminfo almacena la información de todos los tipos de terminal en /usr/share/terminfo. Dentro de ese directorio, por ejemplo el fichero c/cygwin almacena la información sobre el tipo de terminal que por defecto usa el Cygwin en el CMD de Windows, y el fichero v/vt100 almacena el tipo de terminal más común y más emulado.

El Termcap también tiene su (mucho más pequeña) base de datos de terminales centralizada en un fichero único, el /etc/termcap. Podemos usar herramientas como el infocmp -C o el captoinfo (herramientas incluidas en el ncurses) para pasar la configuración para un tipo de terminal de un formato al otro.

(...)

Leer el resto de Terminales para Cygwin. Notas sobre Terminfo y Termcap. (985 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 2 comentarios
Etiquetas: Cygwin, PuTTY, termcap, terminal, terminfo, X Window System

Feed enhanced by Better Feed from Ozh

Para poder usar servicios de red, es muy importante tener en cuenta que la configuración por defecto del Firewall de Windows no nos permitirá su uso, de modo que en todo momento tenemos que tener en cuenta la necesidad de configurar correctamente este Firewall o cualquier otro Firewall Personal que podamos tener instalado.

También es muy importante, si queremos crear servicios de Windows, haber hecho la instalación para todos los usuarios, no sólo para el actual:

Además, los usuarios de Windows 2003 tendrán que tener alguna precaución adicional, ya que como dice el manual de Cygwin en la importante sección NT security and usage of ntsec:

On NT and Windows 2000 the SYSTEM user has these privileges and can run services such as sshd. However, on Windows 2003 SYSTEM lacks the Create a token object right, so it is necessary to create a special user with all the necessary rights, as well as Logon as a service, to run such services. For security reasons this user should be denied the rights to logon interactively or over the network.

En esta entrada vamos a tratar los siguientes servicios:

• inetd
• xinetd
• syslogd
• sshd
• nfsd, mountd, portmap
• cygserver
• Eliminar todos los servicios
• Y si algo no funciona…

(...)

Leer el resto de Servicios en Cygwin (syslogd, sshd, telnetd, ftpd, nfsd, etc.) (2,656 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | Sin comentarios
Etiquetas: Cygwin, OpenSSH, SSH, Windows

Feed enhanced by Better Feed from Ozh

Sin embargo, el Cygwin tiene algunas peculiaridades debidas a su naturaleza Windowsera que conviene que conozcamos para poder sacar el máximo rendimiento de este excelente proyecto. Vamos a verlas:

• Formas de escribir los paths en Cygwin
• El sistema de paquetes
• La longitud de los argumentos en la línea de comandos
• Los ficheros de dispositivo /dev
• La extensión .exe
• El directorio /proc
• Las utilidades
• Enlaces simbólicos
• ¿LF o CR/LF?
• Referencias imprescindibles

(...)

Leer el resto de Trabajando con Cygwin (2,148 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 74 comentarios
Etiquetas: Cygwin, Windows

Feed enhanced by Better Feed from Ozh

• Una librería dll (cygwin1.dll) que proporciona una capa de emulación de POSIX a las aplicaciones que hagan uso de ella.
• Una muy importante colección de herramientas migradas de Linux fácilmente usando la librería anterior.

Con Cygwin tenemos en un entorno unificado la mayoría de las aplicaciones de consola de Linux y, además, como lleva también una implementación del X.org (Cygwin/X), también muchas aplicaciones gráficas. Hay incluso GNOME sobre Cygwin (CyGNOME) y KDE sobre cygwin.

Para dar una idea de lo que lleva cygwin, podemos citar algunos de los programas que lleva la distribución estándar: gcc, bash, sed, awk, bzip2, wget, apache, ssh, sshd, perl, vim, emacs, latex, pine, netcat, rsync, rpm, dpkg, mc, cpio, curl, gv, fvwm, twm, xfig, xterm… Cygwin Package List.

(...)

Leer el resto de Instalar un Cygwin portable en una memoria USB (2,162 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 9 comentarios
Etiquetas: aplicaciones portables, Cygwin, memorias USB, Windows

Feed enhanced by Better Feed from Ozh

The shell exits by default upon receipt of a SIGHUP. Before exiting, an interactive shell
resends the SIGHUP to all jobs, running or stopped. Stopped jobs are sent SIGCONT to
ensure that they receive the SIGHUP. To prevent the shell from sending the signal to a
particular job, it should be removed from the jobs table with the disown builtin (see
SHELL BUILTIN COMMANDS below) or marked to not receive SIGHUP using disown -h.

Ante la señal SIGHUP normalmente todos los procesos reaccionan simplemente saliendo, lo cual es un problema si queremos que nuestro programa siga ejecutándose en el sistema una vez que hayamos dejado la shell. Para evitar que esto ocurra, tradicionalmente se ha usado el comando nohup. Adicionalmente, el bash, desde la versión 2.0, también tiene el comando interno disown como podemos leer en el párrafo anterior.

(...)

Leer el resto de Sobre la señal SIGHUP: nohup, disown, trap (1,183 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 15 comentarios
Etiquetas: bash, C, Debian, disown, GNU/Linux, nohup, patch, shell, SIGHUP, trap, UNIX

Feed enhanced by Better Feed from Ozh

QUERY_STRING='parametro1=valor1&parametro2=valor2&parametro3=valor3'

Estaba yo ya comenzando a darle vueltas a una Expresión Regular para interpretar dicha salida cuando he decidido buscar en Google para ver si alguien tenía una solución más completa que la que yo ya tenía a medias. He llegado al artículo CGI Scripting Tips for Bash or SH que propone lo siguiente para extraer del QUERY_STRING la variable que nos interese:

PARAMETROX=`echo "$QUERY_STRING" | grep -oE "(^|[?&])parametrox=[^&]+" | sed "s/%20/ /g" | cut -f 2 -d "="`

Y es que con bash y sus compañeros sed, awk, cat, grep, etc. aún se puede hacer casi de todo, incluso un weblog o un servidor web. Como las Expresiones Regulares son tan excepcionalmente útiles como complicadas a la hora de usarlas, me he decidido a comentar algunos ejemplos, comenzando por el que me ha llevado a este artículo.

(...)

Leer el resto de Expresiones Regulares en la shell. Ejemplos de uso con grep, awk y sed. (1,917 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 9 comentarios
Etiquetas: aMule, awk, Debian, ed2k, expresiones regulares, GNU/Linux, grep, sed, shell, UNIX

Feed enhanced by Better Feed from Ozh

sst rwx rwx rwx
421 421 421 421
S   U   G   O

S=SUID, SGID y Sticky Bit
U=Usuario
G=Grupo
O=Otros

Esto forma parte de los conocimientos básicos y mínimos de cualquier usuario de UNIX y podemos leer sobre ello en Permisos de ficheros del manual Seguridad en UNIX y Redes. También es muy conocida la existencia de los bits SUID y SGID, formados por los dos bits más significativos del octal más significativo. Aplicados sobre un fichero ejecutable, permiten que el programa se ejecute como si lo hiciera el usuario propietario (SUID) o el grupo propietario(SGID) del fichero.

Pero el propósito de esta entrada es resaltar la curiosidad, bastante menos conocida, de aplicar el bit menos significativo de la cifra octal más significativa (el que en el esquema anterior he marcado con una t), el Sticky Bit, a un directorio (aplicado a un fichero no se usa para nada en la gran mayoría de los UNIX modernos). En el man del chmod leemos:

(...)

Leer el resto de El Sticky Bit y el SGID en directorios (377 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 11 comentarios
Etiquetas: Debian, filesystems, GNU/Linux, Sticky Bit, UNIX

Feed enhanced by Better Feed from Ozh