$ 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

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

En esta entrada veremos cómo conseguir configurar nuestra distribución Debian o Ubuntu para conectarnos a una red WiFi encriptada con WEP o con WPA usando la línea de comandos. También veremos cómo modificar el fichero /etc/network/interfaces para que el sistema se conecte automáticamente a una red WiFi durante el arranque.

Para que no interfiera con mis pruebas, he deshabilitado el NetworkManager antes de comenzar con las mismas (lo que causará que nos desconectemos de las redes que éste gestione):

$ sudo /etc/init.d/NetworkManager stop

También he verificado si el demonio wpa_supplicant está corriendo en segundo plano y lo he matado con un simple kill. Hablaremos más adelante de este proceso.

(...)

Leer el resto de Configurar WEP y WPA en línea de comandos y en el arranque en Debian y Ubuntu (1,422 palabras)

Lo hice y lo entendí © Vicente Navarro 2009 con una licencia CC BY-SA | 5 comentarios
Etiquetas: Debian, GNU/Linux, seguridad, Ubuntu, WEP, WiFi, WPA

Feed enhanced by Better Feed from Ozh

Para quien no lo sepa, WEP (Wired Equivalent Privacy) es un algoritmo de encriptación para redes WiFi que ha demostrado ser extremadamente débil. Para solucionarlo se creó otro sistema, el WPA, y posteriormente, el aún más robusto WPA2. A la mayoría de lectores del blog sí que les serán muy conocidas las siglas WEP, WPA y WPA2 de cuando configuran su red WiFi doméstica, tanto en el router, como en el ordenador, aunque para usar WPA2 en Windows XP es necesario instalar la actualización KB917021, incluida en el SP3.

En el estado actual de las cosas, la clave de una red WiFi encriptada con una clave WEP de 104 bits se puede recuperar fácilmente consiguiendo capturar entre unos 40000 y 90000 paquetes que contengan vectores de inicialización débiles (aircrack-ptw). Además, con las técnicas adecuadas, es muy fácil conseguir que un AP (Access Point) mande todos esos paquetes a gran velocidad, siendo posible conseguirlos en cuestión de minutos.

En cambio, la clave de una red WiFi encriptada con WPA sólo puede ser recuperada por fuerza bruta, de forma que si la clave es suficientemente compleja, la potencia computacional necesaria puede ser simplemente inalcanzable hoy en día, incluso usando la tecnología CUDA de NVidia para ayudar a romper WPA.

(...)

Leer el resto de ¿Aún sigues con encriptación WEP para tu WiFi? (1,291 palabras)

Lo hice y lo entendí © Vicente Navarro 2009 con una licencia CC BY-SA | 24 comentarios
Etiquetas: aircrack-ng, GNU/Linux, seguridad, WEP, Wi-Fi, WPA

Feed enhanced by Better Feed from Ozh

En realidad, se podría argumentar que esos datos tienen que permanecer ahí por si alguna vez queremos volver a instalar el plugin, tener ahí disponible la configuración que se ajusta a nuestro entorno. Es decir, como los ficheros y directorios que comienzan por punto del $HOME de nuestros sistemas Linux, que son ficheros de configuración de los diferentes productos y que permanecen ahí aunque desinstalemos un producto, por si algún día decidimos volver a instalarlo. Pero en realidad, la comparación no es justa, ya que no es lo mismo en términos de sencillez hacer “rm -rf $HOME/.mozilla” o “rm -rf $HOME/.gnome” que tener que ir buscando por la base de datos qué se habrá dejado ahí tal o cual plugin.

Bueno, y esto no es que sea algo que piense yo sólo. También opinan así en:

• WordPress Ideas » WordPress needs an Uninstall Option for Plugins
• WordPress Ideas » Give us the option to not just deactivate, but uninstall a plugin
• Uninstall – Is There Such A Thing?
• wp-fun » Fun with Uninstallation
• WordPress Trac: Ticket #5625 (new enhancement) Include a separate uninstall for plugins

La verdad es que ahora mismo cualquier responsabilidad en el área de la desinstalación de un plugin se deja enteramente en los desarrolladores de los mismos. Pero sin embargo, yo creo que a poco que hubiera una mínima infraestructura en la API de WordPress para fomentar o facilitar la desinstalación de plugins, muchos desarrolladores que hoy en día ignoran completamente el área de la desinstalación, probablente pasaran a considerarla.

(...)

Leer el resto de Desinstalar plugins de WordPress. Los casos de “subscribe to comments”, “WP Ajax Edit Comments” y WP-OpenID. (2,596 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 3 comentarios
Etiquetas: MySQL, SQL, WordPress

Feed enhanced by Better Feed from Ozh

Sin embargo, en su día llegué a pensar en otra cosa: Visitar a los vecinos o poner un anuncio en el portal para intentar repartir los canales Wi-Fi de forma que todos usáramos alguno que no interfiriera a los vecinos más cercanos ni ellos nos interfirieran a nosotros.

Cualquiera que se haya puesto a trastear un poco con la configuración de su router Wi-Fi, probablemente se haya llegado a encontrar con la posibilidad de elegir qué canal usar y habrá visto que hay hasta 13 canales disponibles, con lo que teóricamente podríamos tener hasta 12 vecinos a nuestro alrededor (y nosotros siendo el 13) con distintos canales para no molestarnos los unos a los otros. Por ejemplo, en el formulario de configuración de Wi-Fi de mi Zyxel 660HW, hay un desplegable como este:

Sin embargo, el tema no es tan sencillo. Para ver por qué, empecemos por echarle un vistazo a la tabla de canales Wi-Fi que encontramos en la Wikipedia:

(...)

Leer el resto de Los canales Wi-Fi en la banda de 2.4GHz (802.11b/g) (1,209 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 14 comentarios
Etiquetas: 802.11, Wi-Fi, Zyxel 660HW

Feed enhanced by Better Feed from Ozh

• ¿Realmente queremos tener un hosting casero?
• El servidor
• El proveedor de Internet
• El dominio
• El sistema operativo
• El router
• El servidor web
  • Configuración de los sitios virtuales
  • Poniendo en marcha la nueva configuración
  • MaxClients
  • Moderación con el tamaño de lo que publicamos
  • Un poco de SEO para ahorrar ancho de banda
  • Apache HTTP server benchmarking tool
• El servidor de correo
  • Correo con nuestro propio dominio con Google Apps
• Otras cuestiones
  • Backups
  • El sistema de respaldo
  • Los cortes de corriente
  • Mantenimiento remoto
  • ¿P2P y hosting casero?
  • Scripting
• Conclusión

(...)

Leer el resto de Hosting casero HOWTO (10,593 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 129 comentarios
Etiquetas: Apache, backup, blog, ddclient, Debian, DNS, DynDNS, exim, GNU/Linux, Google, hosting, Internet, modem, MySQL, OpenSSH, PHP, rsync, shell, SMTP, spam, VIA EPIA, wget, WordPress, Zyxel 660HW

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

En concreto, si ya somos capaces de arrancar la instalación de Debian por la red, alterando el fichero de configuración del PXELINUX podemos lograr que el sistema que arranca de la red use el kernel que nos interese y, a continuación, montar por NFS el sistema de ficheros que tendremos preparado en otra máquina.

El primer paso es crear una instalación de Debian dentro de un directorio del servidor de arranque (en mi caso /exports/peggy, donde peggy es el nombre del sistema que arrancará Debian de la red) usando el útil comando debootstrap

# mkdir -p /exports/peggy
# debootstrap --arch i386 etch /exports/peggy http://ftp.es.debian.org/debian/

El debootstrap no instala un kernel por defecto, así que entramos en la nueva instalación con chroot para instalar uno:

# chroot /exports/peggy
# apt-get install linux-image-686 libc6-i686
# exit

Ahora vamos a crear un nuevo fichero de configuración para el PXELINUX. Como podemos leer en la documentación del PXELINUX, el fichero default, que es el que ya tenemos, es el último que se intenta cargar. Antes de eso, el gestor de arranque por red trata de usar un fichero con un nombre como 01-<direccion MAC en minúsculas y con guiones como separadores de bytes>. Por ejemplo, si la dirección de nuestro sistema es 00:41:64:ED:29:D3, necesitaremos un fichero con el nombre 01-00-41-64-ed-29-d3 en /var/lib/tftpboot/pxelinux.cfg/.

(...)

Leer el resto de Configurar un sistema Debian diskless (307 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | Sin comentarios
Etiquetas: Debian, DHCP, filesystems, initrd, NFS, PXELINUX, TFTP

Feed enhanced by Better Feed from Ozh

Con esta configuración necesitaríamos arrancar de la red para poder hacer algo y estaríamos hablando de un sistema diskless.

Si queremos que el sistema sea autónomo, además de las piezas anteriores, necesita un sistema de almacenamiento propio (disco duro, memoria USB, unidad óptica, disquetera) del que arrancar, que normalmente será un disco duro. Supongamos que tenemos un sistema mínimo sólo con un disco duro, queremos instalarle Debian y no tenermos una unidad óptica externa ni nada que podamos usar para hacer la instalación estándar. En ese caso, necesitaremos arrancar la instalación por red.

Es un proceso bastante sencillo, aunque necesitaremos una cierta infraestructura en otro sistema ya instalado del que el sistema a instalar obtendrá todo lo necesario. La máquina a instalar ha de soportar arrancar desde la red por PXE, una combinación de DHCP y TFTP que permite asignar una dirección IP al sistema cliente y a continuación pasarle los ficheros necesarios para que lo haga.

En mi caso, como el router ADSL que uso ya es servidor de DHCP, es deseable evitar posibles interferencias al montar un nuevo servidor DHCP a pesar de que, según la Wikipedia, esto en teoría se podría evitar:

The PXE Client/Server Protocol was designed so it can be used in the same network as an existing DHCP environment without interference

Por ello, y como el PC destinado a servidor de arranque tiene dos interfaces de red, uno normalmente sin usar (eth0) y otro conectado al router (eth1), yo prefiero independizar ambas redes, de tal forma que si conectamos con un cable cruzado la toma de red del sistema a instalar con el interfaz sin usar, estamos listos para comenzar la configuración del sistema.

(...)

Leer el resto de Iniciar una instalación de Debian por red (612 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 3 comentarios
Etiquetas: Debian, DHCP, PXELINUX, SYSLINUX, TFTP, wget

Feed enhanced by Better Feed from Ozh

No te vuelvas loco… El cliente de DHCP pump, que es el que lleva por defecto Knoppix, no es capaz de obtener una IP por DHCP de un 660HW-61 (al menos no el mío con firmware V3.40(PT.0)b46 de Telefónica). Hay incluso un bug de Debian abierto que expone el problema: Bug#362207: pump does not get IP address from Zyxel Prestige 660HW-61.

Como hay varios clientes de DHCP para Linux:

# apt-cache search "dhcp client"
dhcdbd - D-Bus interface to the ISC DHCP client
dhcp-client - DHCP Client
dhcp3-client - DHCP Client
dhcpcd - DHCP client for automatically configuring IPv4 networking
pump - BOOTP and DHCP client for automatic IP configuration
resolvconf - nameserver information handler
udhcpc - very small DHCP client

la solución es usar uno de los otros, siendo el dhcp3-client el que instala Debian por defecto y funciona bien con este router.

Si estamos con Knoppix o con algún otro LiveCD, como no podemos instalar un cliente diferente, tendremos que asignar la IP manualmente tras eliminar todos los pump que puedan estar corriendo con un “killall -9 pump” seguido de un “ps -ef | grep pump“. El pump puede tardar un poco en morir, así que esperamos a que lo haga y a que no salga en la lista del ps. A continuación, si nuestro interfaz ethernet es el eth0, nuestro router tiene la IP 192.168.1.1/24 y la dirección que queremos asignarle al sistema es la 192.168.1.40, para especificar la IP, añadir la IP del servidor de nombres (en este caso el propio router) y añadir la ruta por defecto haremos:

# ifconfig eth0 192.168.1.40 netmask 255.255.255.0 up

# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:16:D4:C3:D2:F2
          inet addr:192.168.1.40  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:28 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:4248 (4.1 KiB)  TX bytes:2128 (2.0 KiB)
          Interrupt:16 

# echo 'nameserver 192.168.1.1' >> /etc/resolv.conf

# cat /etc/resolv.conf
# Insert nameservers here
# nameserver 127.0.0.1
nameserver 192.168.1.1

# route add default gw 192.168.1.1

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0
default         192.168.1.1     0.0.0.0         UG    0      0        0 eth0

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 4 comentarios
Etiquetas: Debian, DHCP, pump, Zyxel 660HW

Feed enhanced by Better Feed from Ozh

Por eso decidí hacer llegar a (casi) todas las habitaciones cables Ethernet usando los tubos del operador alternativo de telecomunicaciones, para olvidarme de los cortes e inestabilidades para siempre. Aquí vemos el router Zyxel Prestige 660HW-61 con cables de red y de teléfono saliendo hacia las habitaciones:

Y aquí vemos cómo quedan las rosetas de teléfono y red (es muy difícil encontrar rosetas de red bonitas, y cuando se encuentran, son muy caras):

Y fruto del trabajo hecho, y de los múltiples cables que he hecho a posteriori a petición popular, me declaro una autoridad en la materia y me voy a atrever a contar los difíciles pasos que hay que seguir hasta llegar a tener un cable de red.

(...)

Leer el resto de ¿Cómo hacer cables de red? (733 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 88 comentarios
Etiquetas: cable de red, RJ45

Feed enhanced by Better Feed from Ozh

Pero hay veces que, estando lejos, nos puede interesar encender ese otro ordenador de forma remota porque necesitamos un fichero que tenemos en él o necesitamos hacer algo en él. Para esas situaciones, lo mejor es tener el Wake on LAN (WoL) preparado en esa máquina y las utilidades necesarias para activarlo en la máquina que no solemos apagar.

El WoL es posible en los PCs actuales gracias a las fuentes de alimentación ATX que, cuando el ordenador está apagado, siguen alimentando a ciertas partes de la placa base permitiendo asimismo el Wake on Ring y la posibilidad de arancar el PC sólo pulsando una tecla del teclado o que se encienda a una determinada hora.

(...)

Leer el resto de Wake on LAN (1,947 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 70 comentarios
Etiquetas: ATX, C, DynDNS, fuentes de alimentación, GNU/Linux, PC, Wake-on-LAN, Windows, Zyxel 660HW

Feed enhanced by Better Feed from Ozh