Como el tema de la redes es amplio, también lo es el número de comandos que pueden usarse para configurarlas y controlarlas. Centraremos nuestra atención en sólo unos pocos de los más frecuentemente usados. Los comandos que hemos elegido examinar son los usados para monitorizar redes y los usados para transferir archivos. Además, vamos a explorar el programa ssh que se usa para realizar accesos remotos. Este capítulo cubrirá:
- ping – Envía un ICMP ECHO_REQUEST a hosts de la red
- traceroute – Imprime la traza de la ruta de los paquetes hasta un host de la red
- netstat – Imprime conexiones de red, tablas de rutas, estadísticas de interfaz, conexiones enmascaradas y pertenencias a multicasts
- ftp – Programa de transferencia de archivos de Internet
- wget – Descargas de red no interactivas
- ssh – Cliente SSH OpenSSH (programa de acceso remoto)
- Dirección IP (Internet Protocol)
- Nombres de host y de dominio
- URI (Uniform Resource Identifier – Identificador de recursos uniforme)
Nota: Algunos de los comandos que veremos pueden (dependiendo de tu distribución) requerir la instalación de paquetes adicionales de los repositorios de tu distribución, y algunos pueden requerir privilegios de superusuario para ejecutarlos.
Examinando y monitorizando una red
Incluso si no eres el administrador del sistema, a menudo es útil examinar el rendimiento y funcionamiento de una red.
ping
El comando de red más básico es ping. El comando ping envía un paquete de red especial llamado IMCP ECHO_REQUEST a un host especificado. La mayoría de los dispositivos de red que reciban estos paquetes responderán, permitiendo verificar la conexión de red.
Nota: es posible configurar la mayoría de los dispositivos de red (incluyendo los host Linux) para ignorar estos paquetes. Esto se hace normalmente por razones de seguridad, para ocultar parcialmente un host de un atacante potencial. También es común configurar los cortafuegos para bloquear el tráfico IMCP.
Por ejemplo, para ver si podemos alcanzar linuxcommand.org (uno de nuestros sitios favoritos ;-), podemos usar ping de la siguiente forma:
[me@linuxbox ~]$ ping linuxcommand.org
Una vez que empieza, ping continua enviando paquetes con un intervalo específico (por defecto es un segundo) hasta que lo interrumpamos:
[me@linuxbox ~]$ ping linuxcommand.org
PING linuxcommand.org (66.35.250.210) 56(84) bytes of data.
64 bytes from vhost.sourceforge.net (66.35.250.210): icmp_seq=1
ttl=43 time=107 ms
64 bytes from vhost.sourceforge.net (66.35.250.210): icmp_seq=2
ttl=43 time=108 ms
64 bytes from vhost.sourceforge.net (66.35.250.210): icmp_seq=3
ttl=43 time=106 ms
64 bytes from vhost.sourceforge.net (66.35.250.210): icmp_seq=4
ttl=43 time=106 ms
64 bytes from vhost.sourceforge.net (66.35.250.210): icmp_seq=5
ttl=43 time=105 ms
64 bytes from vhost.sourceforge.net (66.35.250.210): icmp_seq=6
ttl=43 time=107 ms
--- linuxcommand.org ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 6010ms
rtt min/avg/max/mdev = 105.647/107.052/108.118/0.824 ms
Después de interrumpirlo (en este caso después del sexto paquete) pulsando Ctrl-c,ping muestra las estadísticas de funcionamiento. Un funcionamiento apropiado de la red mostrará cero por ciento de paquetes perdidos. Un “ping” exitoso indicará que los elementos de la red (sus tarjetas de red, cables, rutas y puertos de enlaces) están, en general, funcionando correctamente.
traceroute
El programa traceroute (algunos sistemas usan el similar tracepath en su lugar) muestra una lista de todos los “hops” o saltos que el tráfico de red hace para llegar desde el sistema local al host especificado. Por ejemplo, para ver la ruta tomada para alcanzarslashdot.org, haríamos esto:
[me@linuxbox ~]$ traceroute slashdot.org
La salida tiene esta pinta:
traceroute to slashdot.org (216.34.181.45), 30 hops max, 40 byte
packets
1 ipcop.localdomain (192.168.1.1) 1.066 ms 1.366 ms 1.720 ms
2 * * *
3 ge-4-13-ur01.rockville.md.bad.comcast.net (68.87.130.9) 14.622
ms 14.885 ms 15.169 ms
4 po-30-ur02.rockville.md.bad.comcast.net (68.87.129.154) 17.634
ms 17.626 ms 17.899 ms
5 po-60-ur03.rockville.md.bad.comcast.net (68.87.129.158) 15.992
ms 15.983 ms 16.256 ms
6 po-30-ar01.howardcounty.md.bad.comcast.net (68.87.136.5) 22.835
ms 14.233 ms 14.405 ms
7 po-10-ar02.whitemarsh.md.bad.comcast.net (68.87.129.34) 16.154
ms 13.600 ms 18.867 ms
8 te-0-3-0-1-cr01.philadelphia.pa.ibone.comcast.net (68.86.90.77)
21.951 ms 21.073 ms 21.557 ms
9 pos-0-8-0-0-cr01.newyork.ny.ibone.comcast.net (68.86.85.10)
22.917 ms 21.884 ms 22.126 ms
10 204.70.144.1 (204.70.144.1) 43.110 ms 21.248 ms 21.264 ms
11 cr1-pos-0-7-3-1.newyork.savvis.net (204.70.195.93) 21.857 ms
cr2-pos-0-0-3-1.newyork.savvis.net (204.70.204.238) 19.556 ms cr1-
pos-0-7-3-1.newyork.savvis.net (204.70.195.93) 19.634 ms
12 cr2-pos-0-7-3-0.chicago.savvis.net (204.70.192.109) 41.586 ms
42.843 ms cr2-tengig-0-0-2-0.chicago.savvis.net (204.70.196.242)
43.115 ms
13 hr2-tengigabitethernet-12-1.elkgrovech3.savvis.net
(204.70.195.122) 44.215 ms 41.833 ms 45.658 ms
14 csr1-ve241.elkgrovech3.savvis.net (216.64.194.42) 46.840 ms
43.372 ms 47.041 ms
15 64.27.160.194 (64.27.160.194) 56.137 ms 55.887 ms 52.810 ms
16 slashdot.org (216.34.181.45) 42.727 ms 42.016 ms 41.437 ms
En la salida, podemos ver que conectar desde nuestro sistema a slashdot.orgrequiere atravesar dieciséis routers. Cuatro routers que dan información identificativa, vemos sus nombres, direcciones IP, y datos de funcionamiento, que incluyen tres ejemplos de viajes de ida y vuelta desde el sistema local a router. Para los routers que no ofrecen información identificativa (debido a la configuración del router, congestión en la red, cortafuegos, etc.) vemos asteriscos como en la línea del salto número 2.
ip
El programa ip es una herramienta de configuración de red multipropósito que hace uso de todas las posibilidades disponibles en los núcleos modernos de Linux. Sustituye al anterior programa ifconfig. Con ip, podemos examinar las interfaces y tablas de enrutamiento en la red de un sistema.
[me@linuxbox ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000
link/ether ac:22:0b:52:cf:84 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.14/24 brd 192.168.1.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::ae22:bff:fe52:cf84/64 scope link
valid_lft forever preferred_lft foreve
En el ejemplo anterior, vemos que nuestro sistema tiene dos interfaces de red. El primero, llamado lo, es una interfaz virtual que el sistema usa para comunicarse consigo mismo, y el segundo, llamado eth0, es una interfaz Ethernet.
Al realizar diagnósticos de red causales, las cosas importantes a buscar son: la presencia de la palabra "UP" en la primera línea para cada interfaz, indicando que la interfaz de la red está habilitada, y la presencia de una dirección IP válida en el campo inet en la tercera línea. Para los sistemas que utilizan DHCP (Dynamic Host Configuration Protocol), una dirección IP válida en este campo verificará que el DHCP está funcionando.
netstat
El programa netstat se usa para examinar varias configuraciones de red y estadísticas. Mediante el uso de sus muchas opciones, podemos ver una variedad de características de nuestra configuración de red. Usando la opción “-ie”, podemos examinar las interfaces de red de nuestro sistema:
[me@linuxbox ~]$ netstat -ie
eth0 Link encap:Ethernet HWaddr 00:1d:09:9b:99:67
inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::21d:9ff:fe9b:9967/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:238488 errors:0 dropped:0 overruns:0 frame:0
TX packets:403217 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:153098921 (146.0 MB) TX bytes:261035246 (248.9 MB)
Memory:fdfc0000-fdfe0000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:2208 errors:0 dropped:0 overruns:0 frame:0
TX packets:2208 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:111490 (108.8 KB) TX bytes:111490 (108.8 KB)
En el ejemplo anterior, vemos que nuestro sistema de prueba tiene dos interfaces de red. La primera, llamada eth0, es la interfaz Ethernet, y la segunda, llamada lo, es la interfaz loopback, una interfaz virtual que el sistema utiliza para “hablar consigo mismo”.
Cuando realizamos un diagnostico ocasional de la red, las cosas más importantes a revisar son la presencia de la palabra “UP” al principio de la cuarta linea de cada interfaz, indicando que la interfaz de red está disponible, y la presencia de una IP válida en el campo inet addr de la segunda línea. Para sistemas que usen DHCP (Dynamic Host Configuration Protocol – Protocolo de configuración dinámica de host), una IP válida en este campo verificará que el DHCP está funcionando.
Usando la opción “-r” mostrará la tabla de rutas de red del kernel. Ésto muestra como está configurada la red para enviar paquetes de red a red:
[me@linuxbox ~]$ netstat -r
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt 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
En este ejemplo sencillo, vemos un tabla de rutas típica de una máquina cliente en una LAN (Local Area Network – Red de Área Local) detrás de un cortafuegos/router. La primera línea de la lista muestra el destino 192.168.1.0. Las direcciones IP terminadas en cero se refieren a redes en lugar de a hosts individuales, así que este destino significa cualquier host de la LAN. El siguiente campo, Gateway, es el nombre de la dirección IP de la puerta de enlace (router) usada para ir del host actual a la red de destino. Un asterisco en este campo indica que no se necesita puerta de enlace.
La última línea contiene el destino default. Ésto significa todo el tráfico destinado a una red que no esté listada de ninguna forma en la tabla. En nuestro ejemplo, vemos que la puerta de enlace está definida como un router con la dirección 192.168.1.1, que presumiblemente sabe que hacer con el destino del tráfico.
El programa netstat tiene muchas opciones y sólo hemos visto un par. Échale un vistazo a la man page de netstat para una lista completa.
Transportando archivos por una red
¿Qué tiene de bueno una red a menos que sepamos como mover archivos a través de ella? Hay muchos programas que mueven datos por una red. Veremos dos de ellos ahora y varios más en posteriores secciones.
ftp
Uno de los auténticos programas “clásicos”, ftp tomo su nombre del protocolo que usa, el File Transfer Protocol (Protocolo de transferencia de ficheros). Ftp se usa ampliamente en Internet para descarga de archivos. La mayoría, si no todos, los navegadores web lo soportan y a menudo verás URIs que comienzan por el protocolo ftp://
Antes de que hubiera navegadores web, había programas ftp. ftp se usa para comunicar servidores FTP, máquinas que contienen archivos que pueden ser subidos y descargados a través de una red.
FTP (en su forma original) no es seguro, porque envía nombres de cuenta y contraseñas en texto plano. Ésto significa que no están encriptados y que cualquiera que esnife la red puede verlos. Debido a ésto, casi todos los FTP a través de Internet están ofrecidos por servidores anónimos de FTP. Un servidor anónimo permite que cualquiera acceda usando el nombre de usuario “annonymous” y una contraseña sin sentido.
En el ejemplo siguiente, mostramos una sesión típica con el programa ftp descargando una imagen iso Ubuntu localizada en el directorio /pub/cd_images/Ubuntu-8.04 del servidor FTP anónimo fileserver:
[me@linuxbox ~]$ ftp fileserver
Connected to fileserver.localdomain.
220 (vsFTPd 2.0.1)
Name (fileserver:me): anonymous
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd pub/cd_images/Ubuntu-8.04
250 Directory successfully changed.
ftp> ls
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
-rw-rw-r-- 1 500 500 733079552 Apr 25 03:53 ubuntu-8.04-
desktop-i386.iso
226 Directory send OK.
ftp> lcd Desktop
Local directory now /home/me/Desktop
ftp> get ubuntu-8.04-desktop-i386.iso
local: ubuntu-8.04-desktop-i386.iso remote: ubuntu-8.04-desktopi386.
iso
200 PORT command successful. Consider using PASV.
150 Opening BINARY mode data connection for ubuntu-8.04-desktopi386.
iso (733079552 bytes).
226 File send OK.
733079552 bytes received in 68.56 secs (10441.5 kB/s)
ftp> bye
Aquí hay una explicación de los comandos introducidos durante esta sesión:
ftp fileserver
Invoca el programa ftp y se conecta al servidor FTP fileserver.
annonymous
Nombre de acceso. Después del prompt de login, aparecerá un prompt de contraseña. Algunos servidores aceptarán una contraseña en blanco, otros requerirán una contraseña en forma de dirección de correo electrónico. En este caso, prueba algo como “user@example.com”.
cd pub/cd_images/Ubuntu-8.04
Cambia al directorio en el sistema remoto que contiene el archivo que queremos. Fíjate que en la mayoría de los servidores de FTP anónimos, los archivos para descarga pública se encuentran en algún lugar del directorio pub.
ls
Lista el directorio del sistema remoto.
lcd Desktop
Cambia el directorio en el sistema local a ~/Desktop. En el ejemplo, el programa ftp fue invocado cuando el directorio de trabajo era ~. Este comando cambia el directorio de trabajo a ~/Desktop.
get ubuntu-8.04-desktopi386.iso
Le dice al sistema remoto que transfiera el archivoubuntu-8.04-desktopi386.iso al sistema local. Como el directorio de trabajo del sistema local se cambió a ~/Desktop, el archivo será descargado allí.
bye
Se desconecta del sistema remoto y termina la sesión del programa ftp. Los comandos quit y exit también pueden utilizarse.
Escribir “help” en el prompt “ftp>” mostrará una lista de los comandos soportados. Usando ftp en un servidor donde tengamos suficientes permisos, es posible realizar muchas tareas ordinarias de gestión de archivos. Es tosco, pero funciona.
bye
Se desconecta del sistema remoto y termina la sesión del programa ftp. Los comandos quit y exit también pueden utilizarse.
Escribir “help” en el prompt “ftp>” mostrará una lista de los comandos soportados. Usando ftp en un servidor donde tengamos suficientes permisos, es posible realizar muchas tareas ordinarias de gestión de archivos. Es tosco, pero funciona.
lftp – Un ftp mejor
ftp no es el único cliente FTP en línea de comandos. De hecho, hay muchos. Uno de los mejores (y más populares) es lftp de Alexander Lukyanov. Funciona de forma muy parecida al programa ftp tradicional, pero tiene muchas características convenientes adicionales incluyendo soporte de protocolo múltiple (incluyendo HTTP), reintento automático de descargas fallidas, procesos en segundo plano, completado con el tabulador de las rutas, y mucho más.
wget
Otro programa popular de la línea de comandos para descargar archivos es wget. Es útil para descargar contenido tanto de sitios web como ftp. Archivos independientes, archivos múltiples e incluso sitios enteros puede ser descargados. Para descargar la primera página de linuxcommand.org podríamos hacer esto:
[me@linuxbox ~]$ wget http://linuxcommand.org/index.php
--11:02:51-- http://linuxcommand.org/index.php
=> `index.php'
Resolving linuxcommand.org... 66.35.250.210
Connecting to linuxcommand.org|66.35.250.210|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
[ <=> ] 3,120 --.--K/s
11:02:51 (161.75 MB/s) - `index.php' saved [3120]
Las muchas opciones del programa permite a wget la descarga recursiva, descargar archivos en segundo plano (permitiéndote desconectarte pero seguir descargando), y completar la descarga de un archivo parcialmente descargado. Estas características están bien documentadas en su man page que es superior a la media.
Comunicación segura con hosts remotos
Por muchos años, los sistemas operativos como-Unix han tenido la habilidad de ser administrados remotamente a través de una red. En los primeros tiempos, antes de la adopción general de Internet, había un par de programas populares usados para conectarse a hosts remotos. Eran los programas rlogin y telnet. Estos programas, sin embargo, tienen el mismo fallo que el programa ftp; transmiten todas sus comunicaciones (incluyendo nombres de usuario y contraseñas) en texto plano. Esto los hace totalmente inapropiados para usarlos en la era de Internet.
ssh
Para encaminar este problema, un nuevo protocolo llamado SSH (Secure Shell) fue desarrollado. SSH soluciona los dos problemas básicos de la comunicación segura con un host remoto. Primero, comprueba que el host remoto es quien dice ser (previniendo los llamados ataques de “hombre en el medio”), y segundo, encripta todas las comunicaciones entre los host local y remoto.
SSH consta de dos partes. Un servidor SSH funciona en el host remoto, escuchando conexiones entrantes en el puerto 22, mientras que un cliente SSH se usa en el sistema local para comunicarse con el servidor remoto.
La mayoría de las distribuciones Linux están equipadas con una implementación de SSH llamada OpenSSH del proyecto OpenBSD. Algunas distribuciones incluyen los paquetes tanto del cliente como del servidor por defecto (por ejemplo, Red Hat), mientras que otras (como Ubuntu) solo tiene el cliente. Para permitir que un sistema reciba conexiones remotas, debe tener instalado el paquete OpenSSH-server, configurado y ejecutándose, y (si el sistema está también ejecutando un cortafuegos o tras él) debe permitir las conexiones de red entrantes por el puerto TCP 22.
Consejo: Si no tienes un servidor remoto para conectarte pero quieres probar estos ejemplos, asegurate de que el paquete OpenSSH-server está instalado en tu sistema y usa localhost como nombre del host remoto. De esta forma, tu máquina creará conexiones de red consigo misma.
El cliente SSH usado para conectar con servidores SSH remotos se llama, muy apropiadamente, ssh. Para conectar a un host remoto llamado remote-sys, usaríamos el cliente ssh así:
[me@linuxbox ~]$ ssh remote-sys
The authenticity of host 'remote-sys (192.168.1.4)' can't be
established.
RSA key fingerprint is
41:ed:7a:df:23:19:bf:3c:a5:17:bc:61:b3:7f:d9:bb.
Are you sure you want to continue connecting (yes/no)?
La primera vez que se intenta la conexión, se muestra un mensaje indicando que la autenticidad del host remoto no puede ser establecida. Es porque el programa cliente nunca ha visto al host remoto antes. Para aceptar las credenciales del host remoto, introduce “yes” cuando te pregunte. Una vez que se establece la conexión, el usuario/a es preguntado/a por su contraseña:
Warning: Permanently added 'remote-sys,192.168.1.4' (RSA) to the list
of known hosts.
me@remote-sys's password:
Después de que introduzcamos la contraseña correctamente, recibimos el prompt de shell del sistema remoto:
Last login: Sat Aug 30 13:00:48 2008
[me@remote-sys ~]$
La sesión remota de shell continua hasta que el usuario introduzca el comando exit en el prompt de shell remoto, cerrando de ese modo la conexión remota. En este punto, la sesión local de shell vuelve y reaparece el prompt de shell local.
También es posible conectar a sistemas remotos usando un nombre de usuario diferente. Por ejemplo, si el usuario local “me” tiene una cuenta llamada “bob” en un sistema remoto, el usuario me podría acceder a la cuenta bob en el sistema remoto de la siguiente forma:
[me@linuxbox ~]$ ssh bob@remote-sys
bob@remote-sys's password:
Last login: Sat Aug 30 13:03:21 2008
[bob@remote-sys ~]$
Como vimos antes, ssh verifica la autenticidad del host remoto. Si el host remoto no se autentica correctamente, aparece el siguiente mensaje:
[me@linuxbox ~]$ ssh remote-sys
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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
41:ed:7a:df:23:19:bf:3c:a5:17:bc:61:b3:7f:d9:bb.
Please contact your system administrator.
Add correct host key in /home/me/.ssh/known_hosts to get rid of this
message.
Offending key in /home/me/.ssh/known_hosts:1
RSA host key for remote-sys has changed and you have requested strict
checking.
Host key verification failed.
Este mensaje está causado por una de dos posibles situaciones. Primero, un atacante habría intentado un ataque “hombre en el medio”. Es raro, ya que todo el mundo sabe que ssh alerta al usuario de ello. El culpable más probable es que el sistema remoto haya cambiado de alguna forma, por ejemplo, su sistema operativo o su servidor SSH ha sido reinstalado. En interés de la seguridad sin embargo, la primera posibilidad no debería descartarse. Siempre comprueba con el administrador del sistema remoto cuando aparezca este mensaje.
Tras determinar que el mensaje se debe a una causa benigna, es más seguro corregir el problema en el lado del cliente. Ésto se hace usando el editor de texto (quizás vim) para eliminar las claves obsoletas del archivo ~/.ssh/know_host. En el siguiente mensaje de ejemplo, vemos esto:
Offending key in /home/me/.ssh/known_hosts:1
Ésto significa que la línea uno del archivo known_host contiene la clave infractora. Borra esta línea del archivo y el programa ssh podrá aceptar nuevas credenciales del sistema remoto.
Además de abrir una sesión de shell en el sistema remoto, ssh también nos permite ejecutar un único comando en un sistema remoto. Por ejemplo, para ejecutar el comando free en un sistema remoto llamado remote-sys y mostrar el resultado en el sistema local:
[me@linuxbox ~]$ ssh remote-sys free
me@twin4's password:
total used free shared buffers cached
Mem: 775536 507184 268352 0 110068 154596
-/+ buffers/cache: 242520 533016
Swap: 1572856 0 1572856
[me@linuxbox ~]$
Es posible usar esta técnica de muchas formas interesantes, como en este ejemplo en que realizamos un ls en el sistema remoto y redirigimos la salida a un archivos en el sistema local:
[me@linuxbox ~]$ ssh remote-sys 'ls *' > dirlist.txt
me@twin4's password:
[me@linuxbox ~]$
Fíjate que se usan comillas simples en el comando anterior. Ésto es porque no queremos que se produzca la expansión del nombre en la máquina local; en su lugar, queremos que se realice en el sistema remoto. Igualmente, si hubiéramos querido redirigir la salida a un archivo de la máquina remota, podríamos haber colocado el operador de redirección y el nombre de archivo dentro de las comillas simples:
[me@linuxbox ~]$ ssh remote-sys 'ls * > dirlist.txt'
Tunelización con SSH
Parte de lo que ocurre cuando estableces una conexión con un host remoto via SSH es que un túnel encriptado se crea entre los sistemas local y remoto. Normalmente, este túnel se usa para permitir que los comandos escritos en el sistema local sean transmitidos de forma segura al sistema remoto, y que los resultados sean transmitidos de forma segura de vuelta. Además de esta función básica, el protocolo SSH permite que la mayoría de los tipos de tráfico de red sean enviados a través de un túnel encriptado, creando una especie de VPN (Virtual Private Network – Red Privada Virtual) entre los sistemas local y remoto.
Quizás el uso más común de esta característica es permitir que el tráfico de un sistema X Window sea transmitido. En un sistema corriendo un servidor X (o sea, una máquina que muestra una GUI), es posible arrancar y ejecutar un programa cliente X (una aplicación gráfica) en un sistema remoto y hacer que su pantalla aparezca en el sistema local. Es fácil de hacer; aquí tenemos un ejemplo: Digamos que estamos sentados ante un sistema Linux llamado linuxbox que está ejecutando un servidor X, y queremos ejecutar el programa xload un un sistema remoto llamado remote-sys y ver la salida gráfica del programa en nuestro sistema local. Podríamos hacer ésto:
[me@linuxbox ~]$ ssh -X remote-sys
me@remote-sys's password:
Last login: Mon Sep 08 13:23:11 2008
[me@remote-sys ~]$ xload
Después de que se ejecute el comando xload en el sistema remoto, su ventana aparece en el sistema local. En algunos sistemas, necesitarías usar la opción “-Y” en lugar de la opción “-X” para hacerlo.
scp y sftp
El paquete OpenSSH también incluye dos programas que pueden hacer uso de un tunel encriptado SSH para copiar archivos a través de una red. El primero, scp (secure copy – copia segura) se usa de forma muy parecida al familiar programa cp para copiar archivos. La diferencia más notable es que la ruta de origen y destino tienen que ir precedidas por el nombre de un host remoto, seguido de un punto. Por ejemplo, si quisiéramos copiar un documento llamado document.txt de nuestro directorio home del sistema remoto, remote-sys, al directorio de trabajo actual de nuestro sistema local, podríamos hacer ésto:
[me@linuxbox ~]$ scp remote-sys:document.txt
me@remote-sys's password:
document.txt 100% 5581 5.5KB/s 00:00
[me@linuxbox ~]$
Como con ssh, tienes que aplicar un nombre de usuario al prinicipio del nombre del host remoto si el nombre de usuario del host remoto deseado no coincide con el del sistema local:
[me@linuxbox ~]$ scp bob@remote-sys:document.txt
El segundo programa para copiado de archivos SSH es sftp, el cual, como su nombre indica, es un sustituto seguro del programa ftp. sftp funciona muy parecido al programa ftp original que usamos antes; sin embargo, en lugar de transmitir todo en texto plano, usa un túnel SSH ecriptado. sftp tiene una ventaja importante sobre el ftp convencional ya que no requiere un servidor FTP corriendo en el host remoto. Sólo requiere el servidor SSH. Ésto significa que cualquier máquina remota que pueda conectar con el cliente SSH puede también ser usada como un servidor como-FTP. Aquí hay una sesión de ejemplo:
[me@linuxbox ~]$ sftp remote-sys
Connecting to remote-sys...
me@remote-sys's password:
sftp> ls
ubuntu-8.04-desktop-i386.iso
sftp> lcd Desktop
sftp> get ubuntu-8.04-desktop-i386.iso
Fetching /home/me/ubuntu-8.04-desktop-i386.iso to ubuntu-8.04-
desktop-i386.iso
/home/me/ubuntu-8.04-desktop-i386.iso 100% 699MB 7.4MB/s 01:35
sftp> bye
Consejo: El protocolo SFTP es soportado por la mayoría de los gestores gráficos de archivos que encontramos en las distribuciones Linux. Tanto si usamos Nautilus (GNOME) como Konqueror (KDE), podemos introducir una URI comenzando por sftp:// en la barra de direcciones y operar con archivos almacenados en un sistema remoto que esté ejecutando un servidor SSH.
¿Un cliente SSH para Windows?
Digamos que estás sentado en una máquina Windows pero necesitas acceder a tu servidor Linux para hacer algún trabajo; ¿qué puedes hacer? ¡Conseguir un programa cliente SSH para tu Windows, claro! Hay varios. El más popular es probablemente PuTTY de Simon Tatham y su equipo. El programa PuTTY muestra una ventana de terminal y permite que un usuario Windows abra una sesión SSH (o telnet) en un host remoto. El programa también cuenta con funciones análogas para los programas scp y sftp.
PuTTY está disponible en http://www.chiark.greenend.org.uk/~sgtatham/putty
Resumiendo
En este capítulo, hemos inspeccionado el campo de las herremientas de red de la mayoría de los sistemas Linux. Como Linux se usa tan extensamente en servidores y aplicaciones de red, hay muchos más que pueden añadirse instalando software adicional. Pero incluso con la colección basica de herramientas, es posible realizar muchas tareas útiles relacionadas con las redes.
Para saber más
- Para una amplia (aunque anticuada) vista de la administración de redes, el Linux Documentation Project (Proyecto de Documentación de Linux) ofrece la Linux Network Administrator's Guide (Guía del Administrador de Redes Linux):
http://tldp.org/LDP/nag2/index.html
- Wikipedia contiene muchos buenos artículos sobre redes. Aquí tienes algunos de los más básicos:
https://es.wikipedia.org/wiki/Protocolo_de_Internethttp://en.wikipedia.org/wiki/Host_name
http://en.wikipedia.org/wiki/Uniform_Resource_Identifier
No hay comentarios:
Publicar un comentario
Nota: solo los miembros de este blog pueden publicar comentarios.