Tema 2 Acceso Remoto y Lectura de Logs

2
Administracin Linux II - Modalidad Virtual

Tema 2
Acceso remoto y lectura de logs
C
e
n
t
r
o

d
e

E
d
u
c
a
c
i
n

C
o
n
t
i
n
u
a
Edificio Aulas y relacin con el medio externo
Toledo y Lerida, Planta baja
PBX: 25-25-766
infovirtual@cec-epn.edu.ec

Capacitacin en Modalidad Virtual

Administracin Linux II, Acceso remoto y lectura de logs
Ricardo Ortega

Levantamiento de texto: Ernesto Prez
Redaccin de texto 2010: Ricardo Ortega

Registro de derecho autoral: en trmite
ISBN de este volumen: en trmite
Depsito Legal: en trmite

Publicado en http://cursos.cec-epn.edu.ec/aulavirtual/ desde julio 2008

CENTRO DE EDUCACIN CONTINUA
ESCUELA POLITCNICA NACIONAL
UNIDAD DE EDUCACIN VIRTUAL
Quito Ecuador
CEC-EPN Linux II Tema 2

1

Tema 2
Acceso remoto y lectura de logs
Objeti vos
1. Entender lo que es el SYSLOG y aprender a usarlo.
2. Interpretar, leer y analizar los logs del sistema.
3. Aprender el uso de SSH para acceso remoto
4. Saber copiar archivos entre mquinas de forma segura.
5. Realizar respaldos remotos con SSH.
Contenidos
OBJETIVOS........................................................................................................................................................ 1
CONTENIDOS .................................................................................................................................................... 1
2.1. SYSLOG ................................................................................................................................................. 2
2.1.1. ACTIVANDO EL SYSLOG: ..............................................................................................................................4
2.2. LEYENDO E INTERPRETANDO LOS LOGS DEL SISTEMA ........................................................................... 6
2.3. SYSLOG REMOTO ................................................................................................................................ 25
2.3.1 ENVIANDO LOGS A UN SERVIDOR REMOTO ....................................................................................................29
2.4. LOGROTATE ........................................................................................................................................ 30
2.5. HERRAMIENTAS PARA ANLISIS DE LOGS ........................................................................................... 36
2.5.1. LOGWATCH ..................................................................................................................................................36
2.5.2. PARMETROS DEL LOGWATCH ..........................................................................................................................41
2.6. INTRODUCCIN AL TRABAJO REMOTO MEDIANTE EL USO DE SSH ..................................................... 41
2.6.1 PROTOCOLO SSH ....................................................................................................................................42
2.6.2. CARACTERSTICAS DE SSH ...............................................................................................................................42
2.6.3. POR QU USAR SSH? ...................................................................................................................................43
2.6.4. VERSIONES DEL PROTOCOLO SSH .....................................................................................................................44
2.7. EL CLIENTE DE SSH............................................................................................................................... 45
2.7.1. LINUX (UNIX) ................................................................................................................................................45
2.7.2. USUARIOS ....................................................................................................................................................46
2.7.3. COMPRESIN ................................................................................................................................................47
2.7.4. WINDOWS ...................................................................................................................................................47

2
2.7.5. PALMOS .....................................................................................................................................................50
2.8. COPIANDO ARCHIVOS ENTRE MQUINAS DE FORMA SEGURA ........................................................... 51
2.8.1. WINSCP .....................................................................................................................................................52
2.8.2. SFTP ............................................................................................................................................................53
2.9. SSHD: EL SERVIDOR DE SSH ................................................................................................................. 54
2.9.1. QU LOGRAMOS CON NO ESCUCHAR EN LA INTERFAZEXTERNA? ............................................................................56
2.9.2. OTRAS OPCIONES DE CONFIGURACIN DEL SSHD ............................................................................................56
2.10. OTRAS OPCIONES DEL SSH .............................................................................................................. 57
2.10.1. MS QUE UN SHELL SEGURO..........................................................................................................................57
2.10.2. REENVO POR X11 .......................................................................................................................................57
2.10.3. REENVO DEL PUERTO ...................................................................................................................................58
2.11. REALIZANDO RESPALDOS REMOTOS CON SSH ................................................................................ 59
2.11.1. TAR - SSH ..................................................................................................................................................59
2.11.2. AUTENTICACIN AUTOMTICA .......................................................................................................................61

2.1. Syslog
Syslog es el servicio que se utiliza en Linux para guardar los mensajes que los otros
servicios y demonios del sistema necesitan guardar. Recuerda que un servicio es un
programa que realiza alguna tarea en beneficio del sistema, por ejemplo el httpd, el
mysqld, el crond, el iptables son servicios importantes que requieren almacenar
informacin para auditora, monitoreo y depuracin.
No es recomendable que cada servicio o demonio guarde por su lado los mensajes,
puesto que el trabajo de guardar los mensajes es, muchas veces, pesado y debe tratar de
coordinarse para ahorrar recursos. No es lo mismo 5 50 servicios o demonios tratando
de escribir un mismo archivo, que 5 50 demonios envindole mensajes al syslog, que es
el que se encargar, en su debido momento, de escribir estos mensajes en el disco,
coordinando las escrituras y, sobre todo, ahorrando accesos de escritura innecesarios al
disco.
El directorio donde se almacenan los logs se llama /var/log
Sugiero que le des un vistazo. La mayora de archivos son planos (archivos de texto) que
pueden ser leidos con el less o con cualquier editor de texto, aunque no es recomendable
modificarlos. Imagnate un administrador del sistema que mete mano y modifica los logs
seguramente lo despedirn de su trabajo.

3
Algunos archivos son usados por varios servicios. Por ejemplo todos los siguientes
servicios necesitan escribir dentro de /var/log/maillog, que es un archivo
servidor de smtp (para recibir correos)
servidor de POP3 (una variante que posteriormente estudiaremos para leer los
correos)
servidor de IMAP (otra variante que posteriormente estudiaremos para leer los
correos)
Sistema antivirus y antispam
Todos ellos son sistemas independientes, separados, a los efectos de nuestro sistema
operativo Linux, que, sin embargo, escriben hacia /var/log/maillog.
-Oye, Gabriel, te imaginas cmo haran todos para escribir al mismo archivo?, crees que
entraran a empujones hasta lograr escribir?
El estudiante sonre imaginndose los acalorados empujones: A m se me ocurre poner
archivos de lock para saber que uno est escribiendo y que los dems deben esperar.
-Esta variante que t propones es una forma que podra considerarse medio adecuada-
admite Ricardo -slo que no es suficientemente rpida para servidores de mucha
actividad, porque eso de esperar introduce muchas demoras.
Hay una tercera alternativa: que todos ellos manden los mensajes que van a escribir en el
disco (a /var/log/maillog en este caso) hacia un servicio, que es el que se ocupar de
saber cundo y cmo escribir; este es el syslog. Estos mensajes se envan al kernel, que
se los entrega al syslog.
El syslog es un paquete que viene instalado por defecto en un servidor Linux, y,
normalmente, viene bien configurado y trabajando.
Nunca se recomienda detener el syslog, ya que sin l no se podran guardar muchos
mensajes de los demonios del sistema.

Debo hacerte notar, Gabriel, que los logs (histricos) del sistema siempre tienen mucha
informacin intil (ruido), que muchas veces no nos interesa, pero tambin tienen mucha
informacin til, que ya veremos cmo leer e interpretar.

4
2.1.1. Activando el syslog:
Ricardo explica que aunque normalmente el syslog viene activado, nunca est de ms
verificar si efectivamente lo est:
Escribe el comando chkconfig list syslog
chkconfig --list syslog
syslog 0:off 1:off 2:on 3:on 4:on 5:on 6:off
O con el comando service syslog status
Si por casualidad necesitramos activar el syslog, podramos hacerlo con el comando que
ya conocemos (chkconfig o service). Gabriel, recuerda por favor que este paso no es
necesario, solamente deben hacerlo las personas que no lo tengan activado:
chkconfig --level 2345 syslog on
service syslog start
Listo!, con esto tenemos el syslog activo.
Un mensaje de syslog se divide en tres partes:
1. Facili dad (facility) a la que se emite el mensaje. Se pueden utilizar 12+8
facilidades. (No te preocupes, Gabriel, en un rato expondremos todas ellas).
2. Pri ori dad (priority) conque se emite el mensaje. Existen 8 prioridades con las que
se emiten el mensaje.
3. El mensaje en s. Que es una cadena de texto de libre uso.
El responsable de definir la facilidad, prioridad y texto del mensaje, es el servicio que emite
este mensaje. No somos nosotros.
Gabriel quiere sabe para qu se utilizan las facilidades y prioridades. Ricardo se
arremanga la camisa y empieza a explicar:
- Mira, no es necesario conocer todos los detalles para manejar el syslog, pero siempre
ayuda, as que te explicar: se usan para poder determinar hacia qu archivo vamos a
realizar la escritura de este mensaje.

5
Sin embargo, te sugiero no cambiar la configuracin que trae el sistema syslog hasta que
no hayas tenido varios aos de experiencia.
En nuestro caso, necesitamos entender las facilidades y prioridades, con el fin de
comprender el formato del archivo de configuracin /etc/syslog.conf; este formato es el que
usa nuestro demonio de syslog para saber hacia dnde escribir.
El formato de /etc/syslog.conf es el siguiente:
facilidad.prioridad /camino/a/archivo.log

Veamos un ejemplo: yo podra definir en /etc/syslog.conf estas dos lneas:
mail.info /var/log/messages
mail.* /var/log/maillog
La primera lnea significara una orden para syslog, algo as como: "cualquier mensaje
enviado a la facilidad mail, con una prioridad info(rmativa), gurdalo en /var/log/messages".
La segunda lnea dira: "Cualquier mensaje emitido a la facilidad mail, con cualquier otra
prioridad, gurdalo en /var/log/maillog".
Este par (facilidad-prioridad) est separado por el signo de punto (.).
Aqu hay otra lnea interesante:
local7.* /var/log/boot.log
Todos los mensajes de la facilidad local7 irn a /var/log/boot.log. El sistema Linux al
arrancar enva hacia local7 todos los mensajes del sistema de arranque, lo que nos
permite ver cmo fue levantando cada subsistema al arrancar.
Debemos comentar que no todos los demonios del sistema hacen uso del syslog, sobre
todo porque el syslog, cuando fue creado, slo incluy una serie de facilidades que
parecan inamovibles para la poca (uucp, news), y no hizo provisiones muy tiles, para lo
que pudiera surgir en el futuro (web, ftp, proxy, p2p, etc). Por lo que muchos sistemas
escriben directamente a sus propios archivos de logs. Ejemplos de estos sistemas son:
servidor web (httpd)
servidor de ftp
servidor proxy (squid)

6
servidor de netbios (samba)
2.2. Leyendo e interpretando los logs del sistema
Mira Gabriel: Mucha informacin que se incluye en los logs puede y debe ser ignorada, ya
sea porque no comprendes el tema o porque no viene al caso con tu problemtica. Debes
leer y leer y releer! hasta saber qu es normal y qu no es normal. Cuando seas un experto,
ya no tendrs que leer tanto, porque te dars cuenta en seguida de lo que es normal y
puedes ignorar. Esto te lo da el tiempo. En principio, por novato, te tocar leer todo y buscar
informacin sobre todo, hasta saber qu va y qu no va.

Gabriel asiente con la cabeza. Sabe que le va a tocar leer mucho, antes de discernir lo que
es importante de lo que no lo es.

-Bien, dice Ricardo, vamos al grano: los logs del sistema. Si nos fijamos en syslog.conf
veremos que todos se guardan en /var/log. Vayamos a este directorio y listmoslo:

[root@eperez ~]# cd /var/log/
[root@eperez log]# ll
total 5992
-rw-r----- 1 root root 19619 Sep 7 07:19 acpid
-rw------- 1 root root 12391 Jul 21 16:48 anaconda.log
-rw------- 1 root root 15593 Jul 21 16:48 anaconda.syslog
-rw------- 1 root root 49165 Sep 7 07:19 boot.log
-rw------- 1 root root 124258 Sep 4 09:13 boot.log.1
-rw------- 1 root root 98810 Aug 28 19:12 boot.log.2
-rw------- 1 root root 7088 Sep 7 12:01 cron
-rw------- 1 root root 13611 Sep 4 09:13 cron.1
-rw------- 1 root root 14219 Aug 28 19:12 cron.2
drwxr-xr-x 2 lp sys 4096 Sep 4 09:13 cups
-rw-r--r-- 1 root root 10473 Sep 7 07:19 dmesg
drwxr-xr-x 2 root root 4096 Sep 7 07:19 gdm
drwx------ 2 root root 4096 Aug 21 19:23 httpd
drwxr-xr-x 2 root root 4096 Aug 26 23:24 ices
-r-------- 1 root root 19136220 Sep 7 07:19 lastlog
drwxr-xr-x 2 root root 4096 Jul 21 16:33 mail
-rw------- 1 root root 6120 Sep 7 08:24 maillog
-rw------- 1 root root 22977 Sep 4 09:13 maillog.1
-rw------- 1 root root 12346 Aug 28 19:12 maillog.2
-rw------- 1 root root 312996 Sep 7 12:01 messages
-rw------- 1 root root 761886 Sep 4 09:13 messages.1
-rw------- 1 root root 682827 Aug 28 19:12 messages.2

7
drwx------ 2 root root 4096 Feb 21 2005 ppp
-rw-r--r-- 1 root root 30114 Sep 7 08:25 prelink.log
-rw-r--r-- 1 root root 22501 Sep 7 08:25 rpmpkgs
-rw-r--r-- 1 root root 21125 Sep 3 08:53 rpmpkgs.1
-rw-r--r-- 1 root root 20891 Aug 26 09:39 rpmpkgs.2
drwx------ 2 root root 4096 Feb 21 2005 samba
-rw-r--r-- 1 root root 126324 Aug 14 19:31 scrollkeeper.log
-rw------- 1 root root 2865 Sep 7 09:07 secure
-rw------- 1 root root 6175 Sep 4 08:45 secure.1
-rw------- 1 root root 5858 Aug 28 18:07 secure.2
-rw------- 1 root root 0 Sep 4 09:13 spooler
-rw------- 1 root root 0 Aug 28 19:12 spooler.1
drwxr-x--- 2 squid squid 4096 Sep 4 09:13 squid
-rw------- 1 root root 542 Jul 29 11:19 sudolog
drwxr-xr-x 2 root root 4096 Feb 21 2005 vbox
-rw-rw-r-- 1 root utmp 422400 Sep 7 12:10 wtmp
-rw-rw-r-- 1 root utmp 1669248 Sep 1 08:25 wtmp.1
-rw------- 1 root root 0 Sep 4 09:13 xferlog
-rw------- 1 root root 0 Aug 28 19:12 xferlog.1
-rw-r--r-- 1 root root 32678 Sep 7 07:20 Xorg.0.log
-rw-r--r-- 1 root root 32678 Sep 6 19:00 Xorg.0.log.old
-rw-r--r-- 1 root root 891 Aug 1 06:52 Xorg.setup.log
-rw-r--r-- 1 root root 14449 Sep 6 19:42 yum.log

Observamos que tenemos una serie de archivos y directorios. Vamos a examinar los ms
importantes para nosotros: la gran mayora son generados por el syslog, aunque vemos
otros que no revisamos en el syslog.conf, como por ejemplo yum.log o xferlog.

Estos, al igual que muchos ms, son generados por aplicaciones que no dependen del
syslog.
Gabriel se pregunta cules sern esas aplicaciones, y Ricardo, como leyndole la mente, le
dice:
Apache, squid y yum, por ejemplo tienen sus razones para no usar el syslog. No te voy a
explicar aqu las razones... t podrs investigarlo por tu cuenta ms adelante, pero tienen
por poltica grabar siempre los accesos y los errores est o no activado el syslog.

Adems, hay otros casos en los que el trabajo de usar el syslog es demasiado y no vale la
pena.
En serio?- pregunta Gabriel.

8
-Claro... mira, yum, por ejemplo, es el paquete de actualizacin del sistema. No se ejecuta
junto con otros yum y, por lo tanto, no necesita ms que escribirle muy espordicamente al
sistema. Lo mismo ocurre con los Xorg*, que son logs del ambiente grfico que se generan
slo al levantarlo, y no hay ms de un ambiente grfico normalmente activo.
-Pens que todo se escriba usando syslog, dice Gabriel.
-Pues ya ves que no. Pero una parte positiva es que al menos tenemos la certeza de que
todos los logs del sistema se escriben hacia /var/log, sean escritos por syslog o no.

Adems, debes haber notado que existen una serie de archivos con la terminacin 1 (2, 3, 4,
etc.). Estos son archivos viejos de logs. Ms adelante hablaremos del sistema de rotacin de
logs y el programa logrotate.

Veamos entonces los archivos de logs ms interesantes:
dmesg
El primer log que escribe el sistema al levantar se llama dmesg. Lo escribe al acabar de
arrancar el sistema y contiene informacin sobre cmo fue que el kernel fue subiendo. La
utilera dmesg es la encargada de almacenar la informacin del sistema a nivel de kernel y
hardware y, con slo ejecutarla al final del arranque de Linux, se obtiene este log.
-No veo muy bien su utilidad..., apunta Gabriel.

La utilidad es muy simple: gracias al dmesg tenemos la informacin exacta de cmo levant
el sistema la ltima vez; ya que cada vez que el sistema levanta, este archivo es
sobreescrito por el arranque.

Linux version 2.6.9-11.EL (buildcentos@build1.hughesjr.centos.org) (gcc
version
3.4.3 20050227 (Red Hat 3.4.3-22)) #1 Wed Jun 8 16:59:52 CDT 2005
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000001bff0000 (usable)
BIOS-e820: 000000001bff0000 - 000000001bff8000 (ACPI data)
BIOS-e820: 000000001bff8000 - 000000001c000000 (ACPI NVS)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)

9
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 10 11 *12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *10 11 12 14 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Using ACPI for IRQ routing
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
apm: BIOS not found.
audit: initializing netlink socket (disabled)
audit(1126077532.756:0): initialized
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
SELinux: Registering netfilter hooks
Initializing Cryptographic API
ksign: Installing public key data
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected VIA KM400/KM400A chipset
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
divert: not allocating divert_blk for non-ethernet device lo
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller at PCI slot 0000:00:11.1
ACPI: PCI interrupt 0000:00:11.1[A]: no GSI
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.0:USB HID core driver
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard on isa0060/serio0
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
NET: Registered protocol family 2
IP: routing cache hash table of 1024 buckets, 32Kbytes
TCP: Hash tables configured (established 32768 bind 9362)
Initializing IPsec netlink socket
ACPI: (supports S0 S1 S4 S5)
ACPI wakeup devices:
PCI0 UAR1 USB1 USB2 USB3 EHCI PS2K AC9 MC9 ILAN SLPB
Freeing unused kernel memory: 144k freed
kjournald starting. Commit interval 5 seconds

10
EXT3-fs: mounted filesystem with ordered data mode.
SELinux: Disabled at runtime.
SELinux: Unregistering netfilter hooks
inserting floppy driver for 2.6.9-11.EL
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
via-rhine.c:v1.10-LK1.2.0-2.6 June-10-2004 Written by Donald Becker
ACPI: PCI interrupt 0000:00:12.0[A] -> GSI 11 (level, low) -> IRQ 11
divert: allocating divert_blk for eth0
ehci_hcd 0000:00:10.3: irq 10, pci mem dc824f00
md: ... autorun DONE.
usb 2-1: new low speed USB device using address 2
input: USB HID v1.10 Mouse [062a:0000] on usb-0000:00:10.0-1
ACPI: Power Button (FF) [PWRF]
ACPI: Sleep Button (CM) [SLPB]
EXT3 FS on hda3, internal journal
device-mapper: 4.4.0-ioctl (2005-01-12) initialised: dm@uk.sistina.com
kjournald starting. Commit interval 5 seconds
EXT3 FS on hda1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
Adding 522104k swap on /dev/hda2. Priority:-1 extents:1
Sigue .

Este es el dmesg actual. Tiene informacin particular a mi sistema que puede ser analizada
concienzudamente y que tiene ciertos detalles que pueden ser de inters para m.

-S, ya veo, pero me resulta difcil entender todo lo est ah- dice Gabriel, poniendo cara de
resignacin.

-Tranquilo muchacho, te har un resumen:

El kernel que est corriendo es el 2.6.9-11.EL y fue compilado por la versin 3.4.3 del GCC.
Tengo 447MB de memoria (LOW RAM le llaman).

La cadena de arranque del kernel fue: ro root=LABEL=/ rhgb quiet elevator=as.

Tengo una cpu (CPU#0) que es un procesador de 1.6GHz, aproximadamente.

11

La memoria que ocupa el kernel es de 2MB, reserv otros 7MB por si lo necesitara el kernel,
y le quedan unos 450kb disponibles (Memory: 450300k/458688k available (2062k kernel
code, 7736k reserved, 656k data, 144k init, 0k highmem).

El sistema tiene una velocidad de 3268.60 BogoMIPS,

Activ el SELinux en modo permisivo (lo que es lo mismo que tener apagado el SELinux).

Tengo una cach L2 de 256K.

La CPU es un sempron (CPU: AMD Sempron(tm) 2400+stepping 01).

Tiene un puerto serial (ttyS0).

Tiene dos discos ide (hda y hdc).

Tiene un cdrom (hdd).

Tiene una interfaz de ethernet del tipo via rhine (eth0: VIA Rhine II at 0xdffffe00,
00:0b:6a:cc:ed:26, IRQ 11.).

Eso bsicamente es lo que me interes averiguar de lo que el kernel detect al iniciar el
sistema. Gracias a este log lo hemos podido averiguar.
boot.log
Una vez que el kernel levanta, comienza el proceso de arranque de los servicios que
hayamos definido con el chkconfig. Este proceso puede ser observado en /var/log/boot.log

Cada servicio que arranca o se detiene en nuestro sistema queda grabado en boot.log:

Sep 7 07:19:27 eperez network: Bringing up loopback interface: succeeded
Sep 7 07:19:37 eperez xinetd: xinetd startup succeeded
Sep 7 07:19:29 eperez network: Bringing up interface eth0: succeeded
Sep 7 07:19:38 eperez sendmail: sendmail startup succeeded
Sep 7 07:19:38 eperez sendmail: sm-client startup succeeded
Sep 7 07:19:38 eperez gpm: gpm startup succeeded

12
Sep 7 07:19:38 eperez crond: crond startup succeeded
Sep 7 07:19:39 eperez squid: Starting squid:
Sep 7 07:19:40 eperez squid: .
Sep 7 07:19:40 eperez squid:
Sep 7 07:19:40 eperez rc: Starting squid: succeeded
Sep 7 07:19:42 eperez xfs: xfs startup succeeded
Sep 7 07:19:42 eperez anacron: anacron startup succeeded
Sep 7 07:19:42 eperez atd: atd startup succeeded
Sep 7 07:19:42 eperez readahead: Starting background readahead:
Sep 7 07:19:43 eperez rc: Starting readahead: succeeded
Sep 7 07:19:43 eperez messagebus: messagebus startup succeeded
Sep 7 07:19:43 eperez cups-config-daemon: cups-config-daemon startup succeeded
Sep 7 07:19:44 eperez haldaemon: haldaemon startup succeeded
Sep 7 14:44:10 eperez syslog: klogd shutdown succeeded
Sep 7 14:44:10 eperez syslog: syslogd startup succeeded
Sep 7 14:44:10 eperez syslog: klogd startup succeeded
Sep 7 14:44:10 eperez syslog: syslogd shutdown succeeded

Como la mayora de los logs que veremos, que son generados por el syslog, tienen un
formato muy fcil de entender. Primero van el mes, da, hora, minutos y segundos; despus
viene el nombre de la mquina que genera los logs (eperez en mi caso) y posteriormente
una descripcin de quin mand a generar el log y cul es el mensaje. Por ejemplo:

Sep 7 07:19:39 eperez squid: Starting squid:

Este mensaje indica que el da 7 de septiembre, a las 07:19:39, mi mquina (eperez) mand
a escribir un log a nombre de squid ( squid: ) con el mensaje de que haba iniciado el squid.

-Hasta aqu es sencillo, pero imagino que no siempre es as- dice Gabriel.
-Mira, Gabriel, el problema es que los logs no estn compuestos por una lnea, sino que
llevan cientos, muchas veces cientos de miles de lneas, y a veces es difcil buscar la
informacin que deseamos.

cron
Es el archivo encargado de guardar los eventos que han ocurrido en el cron del sistema
(/var/log/cron). Como puedes ver, tiene el mismo formato que usa syslog para todos sus

13
logs. Y ahora que ya has hemos visto algo de syslog, me puedes decir, ms o menos,
cmo es este formato, Gabriel?

Sep 7 14:50:00 srv4 CROND[13256]: (apache) CMD (/usr/local/Zend/sbin/cache_clean
/usr/local/Zend/etc/php.ini)

Sep 7 15:00:00 srv4 CROND[17385]: (root) CMD (/usr/local/bin/weblogs)


Sep 7 15:01:00 srv4 CROND[17846]: (root) CMD (run-parts /etc/cron.hourly)

Sep 7 15:10:00 srv4 CROND[27255]: (root) CMD (/usr/local/bin/weblogs)


- A ver si puedo. Primero: a qu hora ocurri un evento; despus, en qu mquina (srv4 en
este ejemplo no?) y, por ltimo, el comando ejecutado.
-Bien, como ves, hasta aqu, no tiene mayores misterios.

lastlog
Es un log compactado, binario, que no puede ser visto directamente, sino a travs de una
utilera llamada last.

[root@srv4 log]#last|less

root ttyS0 Tue Sep 6 06:06 - 06:13 (00:06)

reboot system boot 2.4.21-32.0.1.EL Tue Sep 6 05:59 (1+09:19)

root tty1 Tue Sep 6 05:52 - down (00:00)

root ttyS0 Tue Sep 6 05:51 - 05:52 (00:00)

14

root pts/2 144.226.uio.satn Tue Sep 6 05:48 - 05:49 (00:00)

root pts/2 144.226.uio.satn Mon Sep 5 21:41 - 21:41 (00:00)











El formato es muy fcil de entender. Qu usuario entr (root), desde qu terminal (pts/0),
desde qu IP (144.226.uio.satnet.net) da y mes y, las horas de entrada (por ejemplo de 8:25
a 8:27 por un espacio de (00:01); es decir, un minuto).

Adems de darnos toda esta informacin compactada, el lastlog nos indica cundo fue
reiniciado un sistema (por ejemplo este fue reiniciado a las 5:59AM) y el tiempo que estuvo
activo (en este caso 1da+9 horas y 19 minutos).

maillog

15
El maillog es el log que se ocupa de guardar todos los eventos de los servicios y sistemas
relacionados con la mensajera. Estos son smtp, pop, imap, antivirus, antispam, etc.

El formato es el estndar del syslog:

Sep 7 15:23:36 srv4 ipop3d[791]: Logout user=drocano@megalimpio.com
host=7.209.cue.satnet.net [200.63.211.7] nmsgs=0 ndele=0

Sep 7 15:23:36 srv4 ipop3d[794]: Logout user=lametroschool@lametroschool.com
host=nova [200.107.35.34] nmsgs=0 ndele=0

Sep 7 15:23:37 srv4 ipop3d[793]: Logout user=contabilidadjetworld@grupojet.com.ec
host=66.134.uio.satnet.net [200.25.134.66] nmsgs=11 ndele=0

Sep 7 15:23:37 srv4 sm-acceptingconnections[762]: j87KNXh2000762: from=<>,
size=54894, class=0, nrcpts=1,
msgid=<20050907200822.243FF94B0F@gye14.ecua.net.ec>,

proto=ESMTP, daemon=MTA, relay=gye14.ecua.net.ec [157.100.1.52]

Sep 7 15:23:37 srv4 sm-acceptingconnections[762]: j87KNXh2000762:
to=<ventas@ecuaforos.net>, delay=00:00:03, mailer=virthostmail, pri=84894, stat=queued

Sep 7 15:23:37 srv4 sm-acceptingconnections[790]: j87KNZ0F000790:
from=<pablo_eche@hotmail.com>, size=4448, class=0, nrcpts=1, msgid=<BAY12-
F15C0CDC2833776B1F655A4EBA60@phx.gbl>, proto=ESMTP, daemon=MTA,
relay=bay12-f15.bay12.hotmail.com [64.4.35.15]

Sep 7 15:23:37 srv4 sm-acceptingconnections[790]: j87KNZ0F000790:
to=<ucceinfo@ucce.edu.ec>, delay=00:00:01, mailer=virthostmail, pri=34448, stat=queued

Sep 7 15:23:37 srv4 ipop3d[792]: Login user=mariop@global-dental.net
host=[201.245.100.209] nmsgs=0/0

Sep 7 15:23:37 srv4 ipop3d[815]: pop3 service init from 200.124.230.250

Sep 7 15:23:37 srv4 ipop3d[816]: pop3 service init from 201.219.10.2

16

Este es un pequeo extracto de un servidor. En el que indica que el servidor srv4 ha
generado todos esos logs. De ipop3d (pop) y de sendmail (sm-*), indicando de quin provino
un mail, el nmero de identificador (j87KNZ0F000790 por ejemplo) y hacia quin fue el mail,
as como el tiempo que se demor en enviarlo (delay=00:00:01) y el tamao (size) del mail.
Tambin nos indica si el mail fue enviado (stat=Sent) o encolado (stat=Queued), si un mail
est encolado es que est esperando para su procesamiento; si est Sent, no hay mayor
historia, el mail ha sido enviado a su destino.

Este log es uno de los ms importantes, pues nos permite averiguar qu pas con un mail y
por qu no lleg a su destino.

-Con esto, no podemos tener secreto ni mentir diciendo que hemos enviado un mail que
nunca escribimos- dice Gabriel un tanto asombrado.

-S, es verdad. Frecuentemente los usuarios llaman diciendo que enviaron un mail a
fulanit@dominio.com y que fulanito no lo ha recibido. Mediante este log podemos saber si en
verdad hemos recibido un mail dirigido (to) a fulanito@dominio.com y sabremos a la hora
que el otro servidor remoto recibi el correo. Si el mensaje tiene el stat=Sent, entonces no
es problema nuestro; nosotros lo enviamos a su servidor de destino y tienen que averiguar
ellos por su otra parte por qu no lleg un mail.
messages
/var/log/messages es otro de los logs ms importantes. Mantiene toda una serie de eventos
informativos del sistema que nos permiten ver qu ha estado ocurriendo. Cmo te imaginas
que es el formato?- pregunta Ricardo a su alumno.

-Supongo que el formato es el generado por syslog.

-Supones bien. Sigamos aprendiendo la utilidad de messages, porque, de hecho, puede ser
muy til en muchas ocasiones. Yo, bsicamente, primero miro en messages antes que en
cualquier otro log, para determinar fallas en el sistema (aunque, claro, si el error o problema
es exclusivo de mail, miramos mejor en maillog).

secure

17
Aqui no slo se guarda informacin de quin entr, sino detalles que podemos obtener en el
lastlog, como la hora en que entr, la IP, a qu hora se desconect, mediante qu servicio
entr, etc. Tambin indica los comandos de sudo que se hayan ejecutado:

Sep 7 15:35:20 srv4 xinetd[7282]: EXIT: imap pid=6633 duration=0(sec)

Sep 7 15:35:20 srv4 xinetd[7282]: START: pop3 pid=6637 from=201.219.10.2


Sep 7 15:35:20 srv4 xinetd[7282]: START: imap pid=6645 from=67.15.12.90














18







xferlog

Es un log generado por el demonio de ftp, que indica qu archivos estn siendo transferidos
hacia o desde nuestro servidor via ftp, y en general qu acciones estn tomando los clientes
va ftp:

Wed Sep 7 13:45:51 2005 5 200.63.242.254 80611 /var/www/html/guayaquil/fotos/fotos.htm
a _ i r farras ftp 0 * c

Wed Sep 7 13:54:36 2005 1 200.63.242.254 14918
/var/www/html/guayaquil/farrasculturales_4/teatro.htm a _ i r farras ftp 0 * c

Wed Sep 7 13:54:40 2005 2 200.63.242.254 50090
/var/www/html/guayaquil/farrasculturales_4/farrasculturales_4.htm a _ i r farras ftp 0 * c

Wed Sep 7 13:55:36 2005 2 200.63.242.254 24215 /home/farras/baradero.htm a _ i

r farras ftp 0 * c

Wed Sep 7 13:59:20 2005 0 200.63.242.254 24215 /home/farras/baradero.htm a _ d

r farras ftp 0 * c

19

Wed Sep 7 13:59:30 2005 1 200.63.242.254 24215 /var/www/html/baradero.htm a _ i r farras
ftp 0 * c

Wed Sep 7 14:00:55 2005 0 200.63.242.254 4392
/var/www/html/guayaquil/farrasculturales_4/imagenes/normalixta_ind.jpg b _ i r farras ftp 0 *
c

Wed Sep 7 14:01:00 2005 0 200.63.242.254 4296
/var/www/html/guayaquil/farrasculturales_4/imagenes/bienal_26_index.jpg b _ o r farras ftp 0
* c

Wed Sep 7 14:03:12 2005 1 200.63.242.254 45039 /var/www/html/indexmain.htm a _

i r farras ftp 0 * c

Wed Sep 7 14:07:15 2005 3 200.63.242.254 29445
/var/www/html/imagenes/portada_foto.jpg b _ i r farras ftp 0 * c

Wed Sep 7 14:07:19 2005 0 200.63.242.254 3113
/var/www/html/imagenes/alcohol_index.jpg b _ o r farras ftp 0 * c

/var/log/httpd/access.log
Me indica los accesos que hay o ha habido a nuestro(s) sitio(s) web. De esta forma
podemos determinar cul es el objeto o script que consume ms recursos o espacio. Ms
tarde en el curso, usaremos estos logs para revisar y crear estadsticas sobre nuestros sitios
web y dems. El formato es muy parecido al del syslog, pero no es generado por el syslog
sino directamente por el apache:

200.69.167.87 - - [07/Sep/2005:17:40:33 -0500] "GET
/guayaquil/dondefarrear1/flyer/sto_remedio_120_100.jpg HTTP/1.1" 200 6213
"http://www.farras.com/guayaquil/dondefarrear1/agenda_flyer.htm" "Mozilla/4.0 (compatible;
MSIE 6.0; Windows NT 5.1)"


20
200.55.225.156 - - [07/Sep/2005:17:40:33 -0500] "GET /guayaquil/fotos/2005-09-
03/miro/05.jpg HTTP/1.1" 304 - "http://www.farras.com/guayaquil/fotos/2005-09-03/miro.php"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"

201.218.6.46 - - [07/Sep/2005:17:40:33 -0500] "GET
/Templates/menu2002/botonInscribete.gif HTTP/1.0" 200 1898
"http://www.farras.com/indexmain.htm" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"

200.69.166.211 - - [07/Sep/2005:17:40:31 -0500] "GET
/guayaquil/television/imagenes/vamoscontodo.jpg HTTP/1.1" 200 26493
"http://www.farras.com/guayaquil/television/telesistema.htm" "Mozilla/4.0 (compatible; MSIE
6.0; Windows NT 5.1)"

201.218.6.46 - - [07/Sep/2005:17:40:33 -0500] "GET
/Templates/menu2002/granhermanobanner.jpg HTTP/1.0" 200 5108
"http://www.farras.com/indexmain.htm" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"

201.218.6.46 - - [07/Sep/2005:17:40:33 -0500] "GET
/guayaquil/dondefarrear1/flyer/fizz_09_120_100.jpg HTTP/1.0" 200 8131
"http://www.farras.com/guayaquil/dondefarrear1/agenda_flyer.htm" "Mozilla/4.0 (compatible;
MSIE 6.0; Windows NT 5.1)"

/var/log/httpd/error_log

Es el log que nos indica cualquier evento o circunstancia que el httpd haya encontrado y
necesite reportar.

-Cmo qu por ejemplo?, pregunta Gabriel.

- Como que no encuentre un objeto o pgina o que determine que su sistema tiene alguna
falla y necesite reportarlo.

[Tue Aug 30 15:09:05 2005] [notice] Digest: done

[Tue Aug 30 15:09:06 2005] [notice] Apache configured -- resuming normal operations

21

[Tue Aug 30 19:13:30 2005] [notice] caught SIGTERM, shutting down

[Tue Aug 30 19:15:13 2005] [notice] suEXEC mechanism enabled (wrapper:
/usr/sbin/suexec)

[Tue Aug 30 19:15:13 2005] [notice] Digest: generating secret for digest authentication ...



[Tue Aug 30 19:47:58 2005] [notice] caught SIGTERM, shutting down

[Tue Aug 30 19:50:29 2005] [notice] suEXEC mechanism enabled (wrapper:
/usr/sbin/suexec)

[Tue Aug 30 19:50:30 2005] [notice] Digest: generating secret for digest authentication ...


/var/log/squid/access.log
Es el log que nos indica quin est accediendo a travs de nuestro proxy hacia Internet. Nos
permite tambin sacar estadsticas de uso de la conexin en lo referente a la navegacin
web.

1126286893.476 9511 127.0.0.1 TCP_MISS/200 613 POST
http://cursos.Ricardoperez.com/moodle/course/mod.php - DIRECT/67.15.12.90 text/html

1126286896.333 2857 127.0.0.1 TCP_MISS/200 16984 GET
http://cursos.Ricardoperez.com/moodle/mod/resource/view.php? - DIRECT/67.15.12.90
text/html

1126286896.634 300 127.0.0.1 TCP_MISS/200 252 GET
http://toolbarqueries.google.com/search? - DIRECT/64.233.185.104 text/html

22

1126286905.599 2766 127.0.0.1 TCP_MISS/200 19092 GET
http://cursos.Ricardoperez.com/moodle/course/mod.php? - DIRECT/67.15.12.90 text/html

1126286905.665 1801 127.0.0.1 TCP_MISS/304 222 GET
http://cursos.Ricardoperez.com/moodle/lib/editor/lang/en.php - DIRECT/67.15.12.90 -

1126286908.230 1162 127.0.0.1 TCP_MISS/200 252 GET

1126287042.973 262 127.0.0.1 TCP_MISS/302 513 GET
http://toolbar.google.com/version3f? - DIRECT/64.233.167.124 text/plain

1126287043.466 466 127.0.0.1 TCP_MISS/200 516 GET
http://toolbar.google.com/version3f_withCookie? - DIRECT/64.233.183.124 text/plain

1126287045.190 880 127.0.0.1 TCP_MISS/200 2205 GET
http://cursos.Ricardoperez.com/moodle/lib/editor/popups/insert_table.php -
DIRECT/67.15.12.90 text/html

1126287045.584 393 127.0.0.1 TCP_MISS/200 252 GET

/var/log/squid/cache.log
Nos indica cmo ha arrancado el squid, qu parmetros est usando, adems de qu
errores o advertencias ha encontrado en el sistema que le impide arrancar, o qu le impide
seguir trabajando. Es importante siempre leerlo en caso de que el squid d problemas.

2005/09/04 16:47:41| Starting Squid Cache version 2.5.STABLE6 for i686-RedHat-linux-
gnu...

2005/09/04 16:47:41| Process ID 2325

2005/09/04 16:47:41| With 1024 file descriptors available


23
2005/09/04 16:47:41| DNS Socket created at 0.0.0.0, port 32770, FD 4

2005/09/04 16:47:41| Adding nameserver 127.0.0.1 from /etc/resolv.conf

2005/09/04 16:47:41| User-Agent logging is disabled.

2005/09/04 16:47:41| Referer logging is disabled.

2005/09/04 16:47:41| Unlinkd pipe opened on FD 9

2005/09/04 16:47:41| Swap maxSize 102400 KB, estimated 7876 objects

2005/09/04 16:47:41| Target number of buckets: 393

2005/09/04 16:47:41| Using 8192 Store buckets

2005/09/04 16:47:41| Max Mem size: 8192 KB

2005/09/04 16:47:41| Max Swap size: 102400 KB

2005/09/04 16:47:41| Rebuilding storage in /var/spool/squid (CLEAN)

2005/09/04 16:47:41| Using Least Load store dir selection

2005/09/04 16:47:41| Set Current Directory to /var/spool/squid

2005/09/04 16:47:41| Loaded Icons.

2005/09/04 16:47:42| Accepting HTTP connections at 0.0.0.0, port 3128, FD 11.

2005/09/04 16:47:42| Accepting ICP messages at 0.0.0.0, port 3130, FD 12.

2005/09/04 16:47:42| WCCP Disabled.

2005/09/04 16:47:42| Ready to serve requests.

2005/09/04 16:47:42| Store rebuilding is 34.8% complete

24

2005/09/04 16:47:42| Done reading /var/spool/squid swaplog (11775 entries)

2005/09/04 16:47:42| Finished rebuilding storage from disk.

2005/09/04 16:47:42| 11775 Entries scanned

2005/09/04 16:47:42| 0 Invalid entries.

2005/09/04 16:47:42| 0 With invalid flags.

2005/09/04 16:47:42| 11775 Objects loaded.

2005/09/04 16:47:42| 0 Objects expired.

2005/09/04 16:47:42| 0 Objects cancelled.

2005/09/04 16:47:42| 0 Duplicate URLs purged.

2005/09/04 16:47:42| 0 Swapfile clashes avoided.

2005/09/04 16:47:42| Took 0.9 seconds (13120.1 objects/sec).

2005/09/04 16:47:42| Beginning Validation Procedure

2005/09/04 16:47:42| Completed Validation Procedure

2005/09/04 16:47:42| Validated 11775 Entries

2005/09/04 16:47:42| store_swap_size =92140k

2005/09/04 16:47:43| storeLateRelease: released 0 objects

Aqu vemos un log de arranque del squid, bsicamente todo fue bien hasta que arranc y
dej guardados unos parmetros de arranque por si acaso los tuviramos que analizar. Es el
log ms importante cuando hay problemas en el squid.


25
En general, siempre que tengamos un problema, debemos referirnos a los logs. En un inicio
es muy difcil leerlos, pues normalmente no se sabe cul es el log que puede tener la
verdad; por lo tanto, si no se conoce, sugiero se busque en messages, y posteriormente en
maillog, si es referido a los mails, o en el directorio de squid o de httpd, si es referido a uno
de ellos dos.

Sinceramente, y aqu te lo advierto muy bien, Gabriel: si tienes un problema, ni se te ocurra
preguntar en un foro o sitio de Internet cul es la solucin sin haber indicado lo que dicen los
logs. Si no lo haces, perders tu tiempo, porque la nica respuesta que obtendrs ser:
mustrame los logs.

-S, entiendo: en los logs est la clave de todo lo que ha sucedido. Es como tener un cmara
que guarda todos nuestros movimientos.

-Bueno, ms o menos... En fin, para solucionar un problema, normalmente tenemos que
revisar los logs, analizar el error y buscar una solucin de acuerdo a lo que se dice.

Es una falla comn por parte de los novatos preguntar sin ofrecer detalles del problema, sin
decir exactamente qu sucede, qu dicen los logs, qu dice la consola. Y al no hacerlo estn
pecando exactamente de lo que no le gusta a la comunidad de Linux: de preguntar
intilmente. Antes, hay que leer los logs, analizarlos y mostrarlos, para poder obtener ayuda.

-Prometo no ser un pecador... al menos en eso, dice Gabriel sonriendo.

-Adems, sabes qu? En el mismo momento en que realizamos la tarea de bsqueda de
los logs, y anlisis para ponerlos en un foro... generalmente nos damos cuenta del error!!

-Sin ayuda?-pregunta Gabriel.

-Bueno, si es que el error est puesto en los logs, no tenemos casi ni que escribir en los
foros, porque automticamente nos damos cuenta de lo que es.

2.3. Syslog remoto
En la tercera reunin, Ricardo y Gabriel tratan del tema del syslog remoto. Ricardo se sienta
delante de la computadora y empieza a explicar:

26

Una de las mejores caractersticas del syslog es que es capaz de aceptar o enviar las
solicitudes de logs de forma remota.

Ejemplo: podemos tener un equipo (o varios) que no tenga disco, pero que s soporte enviar
logs a servidores remotos. Por ejemplo, cisco lo hace con sus ruteadores, linksys, 3com,
allied telesyn, dlink, y muchos ms tienen una directiva que permite enviar los logs hacia un
servidor remoto.

Mira este ejemplo de un telfono de VoIP que tengo:

Si te fijas arriba, dice: Syslog server y tambin dice syslog level (es para saber cules
priorities enviar).

Tambin puede hacerse entre mquinas Linux. Por ejemplo, si tenemos sospechas de que
una mquina tiene el disco daado, y que casi con seguridad no podr reportar problemas
con el disco porque no podr escribir los logs (los logs lgicamente se escriben a disco), la
solucin es enviar los logs hacia una mquina remota y cuando algo pase, entrar en el
sistema remoto y verificar los logs.

Hay muchas variantes. Tenemos sistemas embebidos, es decir sistemas que no tienen
disco, que, por ejemplo, pueden ser usados como firewall o en cualquier otra actividad. Al no
tener disco estos sistemas tienen que escribir remotamente a otro lugar, esto se puede

27
hacer con el syslog.

Gabriel pregunta:

Cmo hacemos para aceptar logs de equipos remotos?
Muy fcil, el demonio de syslog de Linux permite mediante un switch adicional (-r) aceptar
conexiones va Internet de otros sistemas de log.

Sencillamente tenemos que llamar a nuestro syslog con el switch -r, para esto editamos
/etc/sysconfig/syslog:

vi /etc/sysconfig/syslog #Options to syslogd #-m 0 disables 'MARK' messages. #-r enables
logging from remote machines #-x disables DNS lookups on messages recieved with -r #
See syslogd(8) for more details SYSLOGD_OPTIONS="-m 0" #Options to klogd #-2 prints
all kernel oops messages twice; once for klogd to decode, and #once for processing with
'ksymoops' #-x disables all klogd processing of oops messages entirely #See klogd(8) for
more details KLOGD_OPTIONS="-x"

El directorio /etc/sysconfig tiene muchos archivos de configuracin de varios demonios, entre
ellos el syslog. Te pido que, si real mente te interesa aprender, te molestes en ver los
diferentes archivos adicionales que hay dentro de /etc/sysconfig, para que te enteres de los
diferentes parmetros que potencialmente se pueden usar en los diferentes demonios.

En este caso estamos editando el archivo de configuracin del syslog. Como vemos,
bsicamente hay dos lneas a editar, la segunda (KLOGD_OPTIONS) no la toquemos, mejor
remitmonos a la primera.

Encima de esta primera lnea (SYSLOGD_OPTIONS) veremos las diferentes opciones que
tenemos para llamar al syslog.

En principio, viene con una opcin activada, que es la de apagar las marcas (-m). La
facilidad marcas (MARK) es un mensaje que el sistema manda a escribir cada cierto tiempo.
Lo nico que hace es guardar una lnea en todos los archivos de logs con la hora en que se
escribi.

Tiene como ventaja que permite conocer a qu hora dej de funcionar el sistema (si es que
algn da dejara de funcionar), pues tenemos la certeza de que se escribe una marca cada

28
30 segundos.

-Cada medio minuto?- pregunta Gabriel sorprendido.

-Tal como lo oyes. Pero se suele apagar, porque como defecto provoca que cada cierto
tiempo se escriba a disco y, en muchos sistemas, como las laptops, no deja que se apague
la mquina cuando no se, usa sino que la mantiene constantemente encendida y el disco se
mantiene funcionando continuamente. Tambin en las noches (porque hay muchos que
duermen con la laptop al lado) se oye un continuo: "click", que es el disco escribiendo la
marca.

Adems, en los servidores, el tener que escribir cada 30 segundos una marca implica
consumir un poco ms de recursos, por lo que siempre debemos dejar desactivada las
marcas (-m 0).

Volviendo al tema que nos interesa, si quisiramos aceptar logs de mquinas remotas,
sencillamente tendramos que agregar el switch -r a esta lnea:

SYSLOGD_OPTIONS="-m 0 -r -x"

-Hum... pero tambin agregamos -x, qu es la -x? - pregunta Gabriel, mirando el monitor.
-Simple, le indica al syslog que no resuelva la direccin IP del servidor remoto, para as
acelerar el proceso de escritura de logs.

Al recibirse una peticin remota, sta se enviar con una facility y una priority. Nuestro
servidor determinar en qu lugar escribir estas facility y priority (como hara para las
peticiones locales) y, adems, tratar de averiguar el hostname que le enva ese log
mediante los dns del sistema y escribir entonces en el log adecuado esta informacin.

Esto de resolver los dns es un tema lento, pues cada resolucin puede tardar entre algunas
dcimas de segundo y algunos segundos, lo que puede hacer que, potencialmente, el
sistema consuma recursos. Por eso es importante desactivarlo, para no gastar recursos
resolviendo direcciones IP. Entonces el syslog sencillamente guardar el log con la direccin
IP.

Al terminar de editar el archivo /etc/sysconfig/syslog, debemos reiniciar nuestro syslog para
que tome los nuevos valores:

29

service syslog restart

Una vez que los sistemas remotos comiencen a enviarnos informacin, los logs se vern
ms o menos as:

Sep 7 14:01:01 192.168.1.1 crond(pam_unix)[7658]: session closed for user root

Si te fijas, Gabriel, en el nombre de la mquina sencillamente se pone la IP desde donde
provino el evento del log, lo que nos permite diferenciar entre logs locales a nuestra mquina
y logs particulares de cada sistema remoto, pues cada uno ir con su propia IP.

2.3.1 Enviando logs a un servidor remoto
Bueno, Gabriel, acabamos de ver cmo configurar nuestro servidor para recibir logs de
sistemas remotos.

Pero qu tal que yo no quiera eso, sino todo lo contrario? Cmo hacer para que nuestra
mquina no guarde los logs localmente, sino que los enve hacia un sistema remoto?

Ante todo, debemos indicar que el procedimiento anteriormente descrito y este
procedimiento no deben hacerse en una misma mquina.
-Claro, dice Gabriel. -No tiene sentido configurar una mquina para que reciba logs remotos,
y adems configurarla para que enve los logs de ella a otros sistemas.
- Exactamente, o se hace uno, o el otro. No es que sean incompatibles, pero no tendra
mucho sentido.

El procedimiento para enviar los logs a un servidor remoto es muy fcil. En syslog.conf, en
vez de indicarle un archivo para escribir, podemos decirle que enve remotamente ese tipo
de log a otro lugar.

vi /etc/syslog.conf

*.info;mail.none;authpriv.none;cron.none @192.168.1.1

authpriv.* @192.168.1.1 mail.* @192.168.1.1

30

En el ejemplo anterior, como ves, estamos indicndole a nuestro sistema que enve los logs
de mail y los mensajes, as como los mensajes de authpriv, al (@) servidor 192.168.1.1

Una vez cambiado el syslog.conf procedemos a reiniciar el syslog para que tome los nuevos
cambios:

service syslog restart

En cuanto hayamos hecho esto, podemos generar algn evento (por ejemplo entrar como
root en otra consola) y veremos que nuestros logs ya no se estn escribiendo al disco, sino
que se van a ese sistema remoto.

Debemos recordar que ese sistema remoto debe tener activada la opcin de recibir eventos
de log remotos.

Cualquier tipo de evento de log puede ser enviado remotamente. Es decir, si en todas las
lneas del syslog.conf ponemos @192.168.1.1 en vez del nombre de archivo, entonces todos
los logs sern enviados remotamente y nada se escribir a disco.
2.4. logrotate
-Ricardo, es muy interesante todo lo que hemos visto sobre los logs del sistema- le dice
Gabriel a su tutor.
- S, en realidad si te gusta Linux, es un tema apasionante. Ahora, es necesario que sepas
que si los logs no se rotaran, es decir si no se comprimen y si no se eliminaran de vez en
cuando, el espacio en disco de nuestro sistema crecera desmesuradamente hasta llenarse.

-No haba pensado en eso- dice Gabriel.

- Pero no hay que preocuparse. En Linux existe una utilera que se ejecuta todos los das
(desde /etc/cron.daily) que se llama logrotate.

logrotate lo que hace es leer la configuracin general desde /etc/logrotate.conf y la
configuracin particular para cada log rotado desde /etc/logrotate.d


31
En cuanto lea estos parmetros, va a ir de directorio en directorio, dentro de los indicados en
/etc/logrotate.d, y truncar los logs para disminuir su tamao.

-Truncar?- pregunta Gabriel extraado.

-Por truncar realmente quiero decir "cambiar su nombre". Me explico mejor: Supongamos
que lleg la hora de rotar /var/log/maillog, lo que el sistema realiza son tres acciones:

1. Renombrar (con el comando mv) el archivo /var/log/maillog a /var/log/maillog.1.
2. Crear un archivo vaco (touch /var/log/maillog), de forma tal que pueda comenzar a
escribirse en l.
3. Avisarle a todos los servicios relacionados que dejen de escribir en el inodo de maillog.1
y comiencen a escribir al inodo de maillog.

Ahora ya sabemos de dnde vienen estos archivos de /var/log que contienen.1 .2 .3 .4, etc...
son los logs viejos.

maillog.2 significara "el antiguo maillog.1". Antiguo, porque seguramente ya toc rotar
nuevamente los logs y se hizo una operacin parecida a esta:

* maillog.1 lo movi a maillog.2
* maillog lo movi a maillog.1

Por supuesto, cuando pase un tiempo tocar hacer algo similar:

* maillog lo movi a maillog.1

-Entiendo cmo se van rotando, pero por qu todo este movimiento?-pregunta Gabriel.
- Porque los logs pueden alcanzar muchos megas, incluso gigas de tamao y escribir a un
archivo de 600MB de tamao o de digamos 1.8GB de tamao es bien un proceso lento. Por
eso hace falta, de vez en cuando, cortar y poner un archivo nuevo de log.
- Entonces, se va a rotando y cortando, pero hasta cundo todo este movimiento?
- Mira Gabriel, en el archivo de configuracin del logrotate se indica cuntos logs viejos
mantener. Mantener muchos logs es bueno porque te permite remitirte a muchos das o
semanas atrs para averiguar algo. Pero, a la vez, se consume mucho espacio en disco el

32
mantener muchos logs.

-Y no se pueden comprimir estos logs?
-S, se pueden comprimir. Como son archivos de texto, pueden comprimirse muchas veces,
en promedio 1/10 de su tamao, lo que hace que se ahorre bastante espacio.

-Pero recuerda primero usar logwatch (que se explica ms adelante) ya que si primero usas
logrotate antes que logwatch, no obtendrs ningn reporte. El logwatch se explica en el
siguiente punto.

Veamos un momento /etc/logrotate.conf, que es el archivo principal de configuracin de
logrotare

vi /etc/logrotate.conf

#see "man logrotate" for details

#rotate log files weekly

weekly

#keep 4 weeks worth of backlogs

rotate 4

#create new (empty) log files after rotating old ones

create

#uncomment this if you want your log files compressed

#compress

#RPM packages drop log rotation information into this directory

include /etc/logrotate.d


33
#no packages own wtmp -- we'll rotate them here

/var/log/wtmp {

monthly

create 0664 root utmp

rotate 1}

Aqu lo que vemos son parmetros de configuracin general. Estn bien explicados. Por
ejemplo, RedHat/Centos por defecto indica que los logs deben rotarse semanalmente
(weekly), esto es, slo una vez a la semana realmente actuar el logrotate, los dems das
operar calladito, sin hacer nada.

El parmetro weekly es el que se encarga de indicar que se rotar semanalmente. En mi
opinin, en sistemas medianamente cargados (empresas, isp, etc) se debe cambiar las
rotaciones y hacerlas diarias. Cambiando weekly por daily el sistema rotar los logs todos
los das por la maana, reduciendo el consumo de disco.

Ahora, muchos administradores desean ver logs anteriores a la fecha de la rotacin. El
logrotate se encarga de mantener una cantidad determinadas de copias de acuerdo al
parmetro: rotate #; por defecto rotate 4 es el valor que RedHat sugiere, lo que indicara que
mantenga 4 copias de los logs (como por defecto las rotar semanalmente, entonces
tendremos 4 semanas de copias guardadas).

Si cambiamos la rotacin a: diaria, podramos indicarle que haga 7 rotaciones.
-As mantendramos 7 das de copias no?
- S, en realidad podemos poner el parmetro que queramos: 15 30, segn sea nuestro
inters o el razonamiento de la empresa. Sugiero siempre ms de 3 rotaciones.

En empresas muy cargadas, que generan una gran cantidad de logs, no es saludable
mantener todas estas rotaciones, por lo que, a veces, es bueno bajarlo a 3 o menos
rotaciones.

Igualmente, si necesitamos mantener por ms tiempo las copias anteriores, siempre existen
los respaldos para realizarlas y no mantenerlas en disco.

34

Ms adelante vemos un parmetro que est comentado, y que para m es de mucha utilidad.
Es el compress, que permite que una vez rotado un log, este se comprima para ahorrar
espacio. Los logs son pura informacin en modo texto, por lo que el nivel de compresin
suele ser alto. Tenemos casos de clientes con ms de 300 megas de logs, a veces ms de
500, y no es muy saludable mantener todos esos logs rotados abiertos, pues consumiran
mucho disco. Al comprimirlos (por defecto se comprimen con gzip), estos logs bajan a 40 o
menos megas, lo que s hace que sea sostenible el mantener varios logs antiguos en
nuestro sistema.

Para activar la compresin de logs rotados, sencillamente podemos descomentar (quitar la
#) esta lnea y, a partir de maana, se rotarn y comprimirn.

Cmo se rotar cada archivo de log?

Hasta el momento hemos visto la configuracin general del logrotate.

Bueno, dentro de /etc/logrotate.d tenemos una cantidad de ficheros que nos dan una
indicacin sobre cmo se rotar cada log. Al logrotate se le define tambin por cmo se
rotan cada uno de los archivos dentro de /var/log; estas definiciones estn dentro de
/etc/logrotate.d. Sugiero que entres y mires cada uno de los archivos que estn ah dentro.
-Lo har!- promete Gabriel con mucha conviccin.

Por ejemplo: todos los logs que son atendidos por el syslog, se rotan desde un mismo
archivo de configuracin:

vi /etc/logrotate.d/syslog

/var/log/messages /var/log/secure /var/log/maillog /var/log/spooler /var/log/boot.log
/var/log/cron {

sharedscripts

postrotate

/bin/kill -HUP `cat /var/run/syslogd.pid 2>/dev/null` 2>/dev/null || true


35
endscript}

Cmo se entiende todo esto?
Gabriel mira el monitor y se siente un poco abrumado..., hay muchas lneas que no
comprende.

-Ya veo que ests un poco perdido- le dice Ricardo. Mira, es menos complicado de lo que te
imaginas. La primera lnea, hasta el signo de {, indica exactamente todos y cada uno de los
archivos (con sus caminos completos) sobre los que estamos tratando. En este ejemplo son
messages, secure, maillog, spooler, boot.log y cron.

sharedscripts indica que se deben ejecutar las siguientes acciones al rotar este log. Las
acciones pueden ser:

* prerotate: accin a realizar antes de rotar los archivos.
* postrotate .... endscript, indicar la accin a tomar (o acciones) posterior a haber rotado
(cambiado de extensin) los scripts. En este caso sencillamente se le enviar un -HUP al
syslog para que vuelva a leer los archivos de scripts y tome los nuevos inodos de los
archivos de logs (los que se acaban de crear con tamao 0).

Normalmente la accin de postrotate es la que se utiliza e incluye el reinicio del servicio (o el
HUP) para que vuelva a leer su configuracin, pero, sobre todo, para que se d cuenta de
que el archivo donde escriba ya no est (est con otro nombre) y que debe comenzar a
escribir en el nuevo, recin creado.

Veamos el caso del archivo de rotacin para httpd:

vi /etc/logrotate.d/httpd

/var/log/httpd/*log {

missingok

notifempty

sharedscripts


36
postrotate

/bin/kill -HUP `cat /var/run/httpd.pid 2>/dev/null` 2>/dev/null || true endscript}

Como ves es muy similar: trabajamos con todos los archivos .log que estn presentes dentro
de /var/log/httpd, esto se indica justo antes del {

Con missingok: indicamos que no hay problema; es decir, que proceda si falta uno de ellos,
de esta forma el script no fallar si falta uno de los archivos o todos.

notifempty: si el log est vaco, no rotarlo (no hace falta perder el tiempo cambiando de
nombre a un log vaco, no consume nada).

Por lo dems, vemos que es muy parecido, recarga de igual forma el apache en el
postrotate.

Normalmente no debemos preocuparnos por lo que est programado dentro de un script de
rotacin, pero existen ocasiones muy especiales en las que los demonios (sobre todo el
apache) fallan al rotar (el signo ms evidente es que el servidor deja de responder a las 4am
o una hora parecida, que es cuando el logrotate se ejecuta), en este caso podemos realizar
una reprogramacin del script de rotacin en comandos del shell que consideremos
necesario.

2.5. Herramientas para anlisis de logs
2.5.1. logwatch
Esto de andar leyendo todos los logs del sistema se vuelve muy complejo a veces.
Imagnate, Gabriel, todos los das tener que leer 10 20 megas (o ms) de logs del sistema
slo para determinar que no hubo eventualidades de consideracin. Es muy pesado.

-S, sin duda. Pero, entonces, qu hay que hacer?

- Pues tenemos logwatch que es la herramienta que, por defecto, viene en nuestro sistema
CentOS. Esta herramienta se ocupa de analizar diariamente todos los logs importantes de
nuestro sistema y categorizar los eventos guardados en ellos. En cuanto ha hecho eso,
manda un mail a root con el resumen de lo que encontr.

37

Es muy sencillo, a continuacin vemos un ejemplo de un mail que nos lleg:

From root@eperez.ecualinux.com Thu Sep 8 07:54:07 2005

Date: Thu, 8 Sep 2005 07:54:06 -0500

From: Ernesto Perez <root@eperez.ecualinux.com>

To: root@eperez.ecualinux.com

Subject: LogWatch for eperez.ecualinux.com

###################LogWatch 5.2.2 (06/23/04) ####################

Processing Initiated: Thu Sep 8 07:54:04 2005

Date Range Processed: yesterday

Detail Level of Output: 0

Logfiles for Host: eperez.ecualinux.com

################################################################

--------------------- Cron Begin ------------------------

**Unmatched Entries**

STARTUP (V5.0)

---------------------- Cron End -------------------------

--------------------- Named Begin ------------------------



38
succeeded: 1 Time(s)

---------------------- Named End -------------------------

--------------------- pam_unix Begin ------------------------

crond:

Unknown Entries:

session closed for user root: 12 Time(s)

session opened for user root by (uid=0): 12 Time(s)

---------------------- pam_unix End -------------------------

--------------------- Connections (secure-log) Begin ------------------------


userhelper[5017]: pam_timestamp: updated timestamp file `/var/run/sudo/root/unknown'

userhelper[5018]: running '/usr/share/system-config-soundcard/system-config-soundcard'
with root privileges on behalf of 'root'

userhelper[8529]: pam_timestamp: updated timestamp file `/var/run/sudo/root/unknown'

userhelper[8530]: running '/usr/sbin/system-install-packages //root/Desktop/skype-1.2.0.11-
fc3.i586.rpm' with root privileges on behalf of 'root'

userhelper[10824]: running '/sbin/poweroff' with root privileges on behalf of 'root'

---------------------- Connections (secure-log) End -------------------------

--------------------- sendmail Begin ------------------------

Bytes Transferred: 23306

39

Messages Sent: 4

Total recipients: 4

---------------------- sendmail End -------------------------

--------------------- SSHD Begin ------------------------

SSHD Killed: 1 Time(s)

SSHD Started: 1 Time(s)

---------------------- SSHD End -------------------------

------------------ Disk Space --------------------

/dev/hda3 8.6G 6.3G 1.9G 77% /

/dev/hda1 99M 8.3M 86M 9% /boot

/dev/hdd2 7.5G 6.8G 368M 95% /home

/dev/hdc 69M 69M 0 100% /media/cdrecorder

######################LogWatch End #########################

Como vemos, nos cataloga en diferentes secciones los eventos detectados por l. Los
mensajes que muestra no son una receta. Quiero decir que estos varan segn el evento
que haya ocurrido y segn el tipo de sistema. Por eso, debemos ser capaces de analizar y
determinar qu es un verdadero problema y qu no lo es.
-Cmo hay que analizar para detectar los problemas?- pregunta Gabriel.

-En mi caso, primero veo los eventos del cron. Como ves, dice algo de unmatched entries...
Lo veo y considero que realmente no es un grave problema para m, as que contino con
las otras lneas.

40

Despus un mensaje del named. Entiendo que es cuando se reinici (por eso dice success,
que es una buena seal para m).

pam es el sistema de autenticacin; indica que el usuario root abri 12 veces sesiones con
el sistema y tambin cerr 12 veces. Nada inusual: era yo mismo y lo recuerdo; no las 12
veces, por supuesto, pero s que estuve trabajando todo el da de ayer y abr y cerr
sesiones a discrecin.

En secure log dice que configuraron algo del sonido (/usr/share/system-config-
soundcard/system-config-soundcard) como root y en efecto as lo hice. Adems, dice que
instalaron un paquete (skype.rpm) y as fue, pues quera hablar por telfono va Internet.

Ms abajo hay un pequeo reporte de sendmail, que indica que se enviaron unos 23k en
mails en total 4 mensajes. Puede ser, realmente es un sistema personal mo y esos
mensajes deben haber sido eventos que el mismo sistema me envi como reportes (este
mismo reporte posiblemente). Este reporte en sistemas de produccin es ms grande y
alcanza los millones de mensajes y decenas de gigas de transferencia.

Posteriormente, me indica que mataron una vez al ssh y lo arrancaron una vez (cuando
encend y cuando apagu la mquina, claro est). No hay mayor inconveniente.

Y al final vemos un reporte del uso del disco en ese momento que se corri el reporte.
Tampoco hay mayor problema con mis discos pero agradezco que me enve este reporte.

Estos reportes son cansones, de hecho te confieso que no los analizo todos los das ni en
todos los servidores. Se estima que un administrador de Linux debe ser capaz de manejar
tranquilamente 10 servidores Linux, y al decir manejar, me refiero a ejecutar todas las tareas
que veremos durante el curso (contigo y con tus compaeros), incluidas estas de revisin de
logs, por lo que leer los logs de 10 servidores es verdaderamente un problema.

Eso s: siempre recomiendo echar una mirada a los logs y detectar eventos inusuales. El
logwatch nos ayuda mucho a revisar estos eventos y los consolida en una gran medida; sin
embargo, nada como el ojo humano para poder detectar problemas en un sistema. Por eso
siempre es bueno entrenarse para detectar cules son los eventos que normalmente
ocurren en nuestro sistema y cules han comenzado a salir para, posteriormente, poder
determinar cmo mejorar nuestro sistema o reaccionar ante fallas o problemas.

41

2.5.2. Parmetros del logwatch
El logwatch tambin tiene un archivo de configuracin con una infinidad de parmetros, de
los cuales veremos algunos muy sencillos. Este archivo de configuracin principal est en
/etc/logwatch/conf/logwatch.conf

Como vemos, este archivo est vaco (slo una indicacin de que los parmetros por
defecto pueden ser encontrados en /usr/share/logwatch/default.conf/logwatch.conf)

Dentro de /etc/logwatch/conf/logwatch.conf podemos incluir cualquier parmetro que
deseemos cambiar, yo sugerira solamente analizar e incluir dos (no son obligatorios, son
opcionales)

vi /etc/logwatch/conf/logwatch.conf

MailTo =root

Detail =low

MailTo es el parmetro que indica a qu usuario vamos a enviar los logs con las
advertencias. Por defecto va a root, pero podemos, y yo sugiero que as lo hagamos, enviar
los mails con el reporte a un usuario normal, de ser posible fuera del sistema. Se puede
indicar la direccin completa (usuario@mipropiodominio.com).

Detail es el parmetro que indica con qu nivel de detalle o verbosidad hablar el reporte,
por defecto es Low, pero si consideramos que necesitamos reportes ms detallados
podemos ponerlo en Med o en High para incrementar el nivel. Yo prefiero no tocarlo, pues
con low me genera bastante cantidad de mensajes.

Existen otros parmetros que podemos configurar, pero no es nuestro inters analizarlos; en
todo caso, si usamos man logwatch, o analizamos este archivo de configuracin, podemos
obtener una cantidad impresionante de opciones adicionales.

2.6. Introduccin al trabajo remoto mediante el uso de

42
SSH
Ricardo y Gabriel se renen nuevamente.

-Preparado Gabriel? Para un correcto estudio de este tema, necesitars seguramente de
dos mquinas con Linux para que una acte como servidor y otra como cliente.
Empecemos:
2.6.1 Protocolo SSH
SSH (o Secure SHell) es un protocolo que facilita las comunicaciones seguras entre dos
sistemas, usando una arquitectura cliente/servidor, que les permite a los usuarios
conectarse remotamente a un host .

A diferencia de otros protocolos de comunicacin remota, tales como FTP o Telnet, el SSH
encripta la sesin de conexin, haciendo imposible que alguien pueda obtener las
contraseas no encriptadas y tampoco permite ver qu se est escribiendo dentro de esta
sesin.

SSH est diseado para reemplazar los mtodos ms viejos y menos seguros para
registrarse remotamente en otro sistema a travs de la shell de comando, tales como telnet
o rsh. Un programa relacionado, el scp, reemplaza a otros programas diseados para copiar
archivos entre hosts como rcp. Ya que estas aplicaciones antiguas no encriptan contraseas
entre el cliente y el servidor, evita usarlas mientras sea posible.

-Entonces, es preferible usar siempre SSH en lugar de FTP y Telnet?- pregunta Gabriel.

-S, as es. Recuerda que el uso de mtodos seguros para registrarse remotamente a otros
sistemas reduce los riesgos de seguridad, tanto para el sistema cliente como para el sistema
remoto.
2.6.2. Caractersticas de SSH
El protocolo SSH proporciona las siguientes protecciones:

* Despus de la conexin inicial, el cliente puede verificar que se est conectando al
mismo servidor al que se conect anteriormente.
* El cliente transmite su informacin de autenticacin al servidor usando una encriptacin

43
robusta de 128 bits.
* Todos los datos enviados y recibidos durante la sesin se transfieren por medio de
encriptacin de 128 bits, lo cual los hace extremamente difciles de descifrar y leer.
* El cliente tiene la posibilidad de reenviar aplicaciones X11 desde el servidor. Esta
tcnica, llamada reenvo por X11, proporciona un medio seguro para usar aplicaciones
grficas sobre una red.

Ya que el protocolo SSH encripta todo lo que enva y recibe, se puede usar para asegurar
protocolos inseguros. El servidor SSH puede convertirse en un conducto para convertir en
seguros los protocolos inseguros mediante el uso de una tcnica llamada reenvo por puerto,
como por ejemplo POP, incrementando la seguridad del sistema en general y de los datos.

Red Hat Enterprise Linux contiene el paquete general de OpenSSH (openssh), as como
tambin los paquetes del servidor OpenSSH (openssh-server) y del cliente (openssh-
clients).

2.6.3. Por qu usar SSH?
-Bien Gabriel, es importante que comprendas las razones por las que es tan necesario el
uso de SSH.

Gabriel asiente y anota lo que el tutor le explica.

Los potenciales atacantes tienen a su disposicin una variedad de herramientas que les
permiten interceptar y redirigir el trfico de la red para ganar acceso al sistema. En trminos
generales, estas amenazas se pueden catalogar del siguiente modo:

* Intercepcin de la comunicacin entre dos sistemas: en este escenario existe un tercero
en algn lugar de la red entre entidades en comunicacin, que hace una copia de la
informacin que pasa entre ellas. La parte interceptora puede interceptar y conservar la
informacin, o puede modificar la informacin y luego enviarla al recipiente al cual estaba
destinada.

Este ataque se puede montar a travs del uso de un paquete sniffer, que es una utilidad
de red muy comn.
* Personificacin de un determinado host: con esta estrategia, un sistema interceptor finge

44
ser el recipiente a quien est destinado un mensaje. Si funciona la estrategia, el sistema del
usuario no se da cuenta del engao y contina la comunicacin con el host incorrecto. Esto
tambin est relacionado con la tcnica de ataque de hombre en el medio.

Esto se produce con tcnicas como el envenenamiento del DNS o spoofing de IP
(engao de direcciones IP).

Ambas tcnicas interceptan informacin potencialmente confidencial y, si esta intercepcin
se realiza con propsitos hostiles, el resultado puede ser catastrfico.

Si se utiliza SSH para inicios de sesin de shell remota y para copiar archivos, se pueden
disminuir notablemente estas amenazas a la seguridad. Esto es porque el cliente SSH y el
servidor usan firmas digitales para verificar su identidad. Adicionalmente, toda la
comunicacin entre los sistemas cliente y servidor es encriptada. No servirn de nada los
intentos de falsificar la identidad de cualquiera de los dos lados de la comunicacin, ya que
cada paquete est cifrado por medio de una llave conocida slo por el sistema local y el
remoto.
2.6.4. Versiones del protocolo SSH
El protocolo SSH le permite a cualquier programa cliente y servidor, construido segn las
especificaciones del protocolo, comunicarse de forma segura y ser usado de intercambiable.

Existen dos variedades de SSH actualmente (versin 1 y versin 2). La versin 1 de SSH
hace uso de muchos algoritmos de encriptacin patentados (sin embargo, algunas de estas
patentes han expirado) y es vulnerable a un hueco de seguridad que potencialmente le
permite a un intruso insertar datos en la corriente de comunicacin.

-No puede tan efectiva si es vulnerable, opina Gabriel.

- Tiene su pequeo defecto... por suerte hay una nueva versin. La suite OpenSSH bajo Red
Hat Enterprise Linux utiliza por defecto la versin 2 de SSH, que tiene un algoritmo de
intercambio de llaves mejorado que no es vulnerable al hueco de seguridad en la versin 1.
Sin embargo, la suite OpenSSH tambin soporta las conexiones de la versin 1.


45
2.7. El cliente de SSH
Ese mismo martes, despus de bajar a comer algo rpido en la cafetera, Ricardo y Gabriel
continan.
- Dnde nos quedamos?- pregunta Ricardo mirando los monitores.
- Estbamos mirando las caractersticas de SSH.
- Ah ya me acuerdo! Bien, sigamos. Estudiemos ahora el cliente de SSH. Mira, el cliente de
SSH es aquel que nos permite conectarnos desde nuestra estacin de trabajo hacia nuestro
servidor.

Existen una infinidad de clientes de SSH, pero bsicamente veremos 3, para 3 diferentes
sistemas operativos.
2.7.1. Linux (unix)
Existe un cliente de SSH que viene conjuntamente con nuestro servidor Linux. Este paquete
se llama openssh-clients y viene por defecto en todos los Linux instalados.

Uno de los componentes del openssh-clients es la utilera SSH. Veamos cmo usarla:

SSH 192.168.1.1

nos permitir conectarnos al servidor 192.168.1.1 y acceder a l.

El SSH utiliza un sistema de clave pblica y privada. La primera vez que nos conectemos a
un sistema nos indicar que no conoce de la clave del sistema destino, que no la puede
validar, que por favor indiquemos si tenemos confianza en este sistema o no.
-Necesito un ejemplo para poder captar bien lo que me dices, -dice Gabriel mirando el
monitor.
- Claro, a eso iba. Por ejemplo, aqu nos estamos conectando al diario El Mercurio de
Cuenca por primera vez y obtenemos este anuncio:

[root@eperez ~]#SSH mail.elmercurio.com.ec

The authenticity of host 'mail.elmercurio.com.ec (200.93.223.170)' can't be established.

RSA key fingerprint is 0b:95:df:77:60:e3:8c:4b:24:3e:59:e0:4d:1a:c7:9e.

46

Are you sure you want to continue connecting (yes/no)?

Si quisiramos entrar, debemos escribir perfectamente la palabra: yes y ah procedera a
pedirnos la clave.

Si somos detallistas, nos debemos haber fijado que no slo podemos hacer SSH a una
direccin IP sino que podemos usar el nombre de la mquina (mail.elmercurio.com.ec en mi
caso).

2.7.2. Usuarios

Por defecto el SSH enva como username el usuario conque estamos conectados en
nuestra mquina de origen, por lo que si estamos en nuestra mquina conectados como root
el comando anterior tratar de conectarse a 192.168.1.1 como el usuario root.

Slo nos pedir la clave de root de la mquina remota para entrar.

Ahora, si quisiramos conectarnos como otro usuario, podramos usar:

SSH -l eperez 192.168.1.1

esto permitir conectarnos al servidor 192.168.1.1 ya no como el usuario con el que estamos
conectados, sino que nos permitir entrar como cualquier otro usuario que queramos de
forma remota. T puedes poner tu nombre, Gabriel.

Mira, otra variante para entrar con otro usuario es:

SSH eperez@192.168.1.1

Este comando tiene exactamente el mismo efecto, nos permite entrar remotamente con el
usuario eperez, aun cuando seamos otro usuario en nuestra mquina.


47
2.7.3. Compresin
Por defecto el SSH no comprime los datos que circulan en su canal.
- Sin comprimir? Imagino, entonces, que la mquina se volver lenta, apunta Gabriel.
- S, y por eso, muchas veces nos interesa comprimir estos datos para lograr una velocidad
de trabajo mejor. Por ejemplo, cuando estamos conectndonos a un sitio remoto a travs de
una mala conexin. Para esto podemos usar el switch -C, el cual le indicar al SSH que use
compresin para el intercambio de datos y, a menudo, s mejora la percepcin de velocidad.

SSH -C mail.elmercurio.com.ec

-Qu hara -C en esta lnea que acabo de poner, Gabriel?
-Nos permitira conectarnos con compresin al diario El Mercurio de Cuenca.
-Exactamente. En una red local la compresin no tiene mayor efecto, no se nota mucha
diferencia en la velocidad pero s hace que el SSH consuma cpu en comprimir los datos. Por
lo tanto, si estamos trabajando desde una red local o estamos conectndonos a un sitio
cercano o con buena conexin hacia nosotros, sugiero que no uses la compresin para
evitar el consumo de recursos en vano.

Los switches se pueden combinar a conveniencia, por ejemplo:

SSH -l eperez -C mail.elmercurio.com.ec

El cliente de SSH de Linux tambin nos permite ejecutar comandos en otros sistemas de
forma automtica. Por ejemplo:

SSH 192.168.1.1 ls

Lo que hara sera conectarse a 192.168.1.1 y ejecutar el comando ls.

Por supuesto, en vez de ls podemos usar cualquier otro comando presente en el sistema
remoto.

2.7.4. Windows
-Ahora, no todos tenemos la dicha de usar Linux en nuestras mquinas clientes... dice

48
Ricardo, hacindole un guio de complicidad a Gabriel.- Muchas veces tenemos la
desgracia de tener Windows en nuestras estaciones de trabajo por situaciones
imponderables y necesarias.

Gabriel sonre y piensa que l ha tenido esa "desgracia" casi toda su vida. Por eso, quiere
aprender bien Linux.

-Pero cmo nos conectamos a nuestros servidores Linux entonces? Bueno, como
imaginas, existe una solucin que nos permite usar el mouse (para eso es Windows no?) y
se llama PuTTY.

Realmente hay muchas otras soluciones, pero la ms extendida es el PuTTY, primero
porque es gratuita y segundo porque realmente tiene todas las caractersticas necesarias
para trabajar con nuestros servidores Linux.
-Qu bien que sea gratis... y es fcil encontrarla en Internet?- pregunta Gabriel.
- Cuando me ha hecho falta, entro en Google y pongo: putty download. De primerito saldr!
Es un .exe, no hay ni que ejecutarlo... sencillamente lo ponemos en el escritorio y ya!

Puedes bajarlo de aqu:
http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
si te fijas es una URL muy larga, por lo que es preferible que uses google.com para buscar
por las palabras "putty download". Recuerda descargar del sitio primario. Nunca bajes de
elpatitofeo.com o algo falto de seriedad.

En cuanto lo ejecutes, se ver algo as:

49

Bsicamente, tenemos que indicarle a nuestro cliente PuTTY la IP o nombre del servidor al
que nos vamos a conectar. En la parte de connection ->data podemos indicar el username
con el que nos conectaremos. Y en la parte de SSH podemos indicar el tipo de protocolo (1
o 2) conque nos conectaremos.

Es muy simple de usar, nos pedir, igualmente, la clave y podremos trabajar en una ventana
con nuestro Linux.

Realmente este es el mejor indicador de que no necesitamos ambiente grfico en nuestros
servidores. Todas las labores las podemos realizar desde una sesin (ventana) de nuestra
mquina desktop, ya sea que est con Windows o con Linux.


50
El PuTTY tambin nos permite copiar y pegar. Se copian lneas marcando con el click
izquierdo y se pueden pegar las mismas con el click derecho. Por supuesto, podemos portar
informacin desde PuTTY a otras aplicaciones: copiamos en la otra aplicacin (quiz con
CTRL C) y pegamos en PuTTY con click derecho. O a la inversa, copiamos en PuTTY con
click izquierdo, y pegamos en la otra aplicacin como normalmente haramos (quiz CTRL
V).

2.7.5. PalmOS
No slo podemos usarlo desde Windows, sino que tambin lo podemos hacer desde una
mquina palm (y estimo que con una pocket pc, igualmente podemos).

Existen varios clientes de SSH, uno de ellos es el pssh, tambin es gratuito. El autor dice
que es inseguro, pues el generador de nmeros aleatorios de la palm es muy malo, pero por
lo dems permite realizar todas las actividades que queramos dentro del espacito de nuestra
palm

Hay que tener muy en cuenta que en Linux hay que pensar no slo por uno, sino por los
dems que se conectan a nuestros servidores.
-Y para Windows hay tambin un SSH?- pregunta Gabriel.

-No, no conozco ningn servidor de SSH para Windows. Slo conozco clientes.


51
2.8. Copiando archivos entre mquinas de forma segura
El protocolo SSH no slo nos sirve para conectarnos a ejecutar comandos en mquinas
remotas, sino que, adems, nos permite copiar archivos de forma segura a nuestras
mquinas.

El ftp es un protocolo muy bueno que nos permite transferir archivos entre mquinas.
Realmente es muy usado, y recomiendo que se siga usando.

-Pero no es inseguro? Cre que era mejor no usarlo- se extraa Gabriel.
- Normalmente para subir un sitio web no hace falta tanta seguridad, pues, a fin de cuentas,
la informacin que estamos subiendo es pblica.

Ahora, hay ocasiones en que estamos transfiriendo documentos confidenciales entre
servidores y no deseamos que sean vistos por potenciales interesados en robarse la
informacin. Para esto podemos usar el comando scp.

Una de las formas ms simples y sin embargo ms usadas puede ser:

scp /etc/passwd 192.168.1.1:

Esto copiara de forma segura (scp) el archivo /etc/passwd hacia el servidor 192.168.1.1:

Fjate que el nombre del servidor remoto lleva el signo de : al final.

Si quisiramos traer algo de un servidor remoto pondramos:

scp 192.168.1.1:/etc/grub.conf .

Esto traera del servidor 192.168.1.1 (recuerda los : ) el archivo /etc/grub.conf (fjate que va
sin espacios despus de los : ) hacia nuestra mquina (directorio actual: .)

Si quisiramos copiar un directorio completo lo podramos hacer con el switch -r (recursivo):

scp -r /var/log 192.168.1.1:/home/backup/


52

Esto copiara recursivamente todos los contenidos de /var/log hacia el directorio
/home/backup en servidor 192.168.1.1 (fjate que se ha especificado directorio de destino).

-Qu pasa cuando no se especifica directorio, cuando nos referimos al servidor remoto? -
pregunta Gabriel.

-Simple, los contenidos a copiarse se mueven hacia el directorio del usuario con que nos
conectamos.

- Y como otro usuario cmo copiamos?
- Con -l

scp -r -l eperez /etc 192.168.1.1:/home/backup/

copiara recursivamente los contenidos de /etc entrando como el usuario eperez y
copindolo hacia /home/backup.

Tambin podramos haber escrito el comando de la siguiente forma:

scp -r /etc eperez@192.168.1.1:/home/backup/

Esta podra ser una forma de transferir contenidos desde un servidor a otro, digamos
respaldos. Pero requerira que, primero se hiciera un respaldo local y que, despus, se
movieran estos contenidos.
2.8.1. WINSCP
Es la utilera que se usa para copiar archivos desde Windows hacia Linux o viceversa. Usa
el mismo protocolo de SSH. El winscp no cuesta dinero y es una herramienta muy til para
los que todava no hemos podido salir del Windows como estacin de trabajo. Espero que
despus de este curso, tu sistema operativo pase a ser Linux, Gabriel.

- Por supuesto, profe!, dice Gabriel.

53

2.8.2. sftp
El sftp es una forma segura de realizar transferencias como si fuera ftp. Bsicamente se
usan algunos comandos que son similares al ftp, pero no se usa un servidor de ftp, sino el
mismo servicio de SSH.

sftp 192.168.1.1

Hara un ftp al servidor 192.168.1.1 con el usuario con el que estamos en nuestro sistema.
Como siempre, si deseamos usar otro usuario, podramos hacerlo como:

sftp eperez@192.168.1.1

este hara sftp, pero usando a eperez como usuario.

Una vez dentro del sistema remoto los comandos son los mismos que ftp:
Comando Significado
ls lista los contenidos del
directorio remoto
pwd directorio actual (remoto)
rm borra archivo

54
put archivo pone el "archivo" local en el
servidor remoto
get archivo toma del servidor remoto el
"archivo"
cd cambia de directorio remoto
lls ls del directorio local
lpwd pwd del directorio local
progress muestra una barra con el progreso
del sftp
? muestra comandos de ayuda

Bsicamente es muy simple y se usa como un ftp.

Realmente, yo prefiero el scp antes que el sftp, pero, en todo caso, aqu estn las variantes.

2.9. sshd: El servidor de SSH
-Ahora centrmonos en sshd Qu crees que es, Gabriel?
- Tengo una idea, pero prefiero que me lo digas t...
- sshd es el demonio que permite las conexiones desde clientes remotos hacia nuestro
servidor.

Activarlo es muy simple: con el comando chkconfig lo podramos activar:

chkconfig --level 2345 sshd on

service sshd on

A propsito, este servicio viene activado por defecto en nuestro CentOS.

Activado el demonio de sshd, este escuchar en el puerto 22 de nuestro sistema, de nuestro
servidor.

Por defecto siempre sugerimos configurar el servicio de sshd para aceptar solamente la
versin 2, ya que la versin 1 es bastante insegura.

-Pueden adivinar la clave- apunta Gabriel.
-S, es ms fcil que adivinen la clave. Por eso sugiero que usemos la versin 2.

55

Para editar los parmetros de configuracin del sshd podemos acceder al archivo:

vi /etc/ssh/sshd_config

Veremos una serie de parmetros de configuracin. Sugiero no tocar ningn parmetro, a no
ser que conozcamos perfectamente qu estamos haciendo. En este caso, para activar el
protocolo 2 del ssh podemos buscar una lnea que dice:

#Protocol 2,1

Esta lnea, en efecto, est comentada, pero bsicamente indica que por defecto el sshd
aceptar los protocolos 2 y 1 en este orden. Para asegurarnos que no acepte nunca el
protocolo 1, procedamos a descomentar la lnea y quitar el 1:

Protocol 2

Aqu lo que le hemos indicado al sshd es que acepte solamente el protocolo 2 (versin 2).

Dentro del archivo de configuracin del sshd tambin podemos editar en qu interfaces
queremos que este servicio escuche. Bsicamente un servicio de Linux escucha en todas
las interfaces de red disponibles en la mquina; supongamos que tenemos una mquina
Linux con dos interfaces de red, una apuntando hacia nuestra red (LAN) y otro hacia la
Internet:

_____ | | LAN ---------| |-------- Internet IP: 192.168.1.1 |_____|

La Internet siempre es un espacio peligroso, desde la Internet siempre proceden muchos
ataques automticos o dedicados a nuestra red.

- As que no es bueno tener abierto el ssh hacia la Internet.- dice Gabriel.

- No, no es bueno. Por eso, podramos decirle al demonio de ssh que solamente escuche en
la interfaz interna de nuestro servidor. Para esto sencillamente buscamos dentro de
sshd_config la lnea que dice:

#ListenAddress 0.0.0.0

56

La cual, como vemos, est comentada, pero nos indica que escuchar en todas (0.0.0.0) las
interfaces y le decimos especficamente en cul interfaz escucharemos:

ListenAddress 192.168.1.1

Por ejemplo, en este caso, le estamos diciendo que en la interfaz 192.168.1.1 ser donde
escuchar mi sshd; por lo tanto, para la IP de la Internet (no nos interesa saber, pues igual
no escucharemos ah) no estaremos escuchando.

2.9.1. Qu logramos con no escuchar en la Interfaz externa?
Muy simple, lo que logramos es que, aunque nuestro sshd pueda tener una falla de
seguridad, aunque un atacante pueda tener la clave de nuestro usuario root, aunque alguien
est decidido a averiguar mediante un ataque de diccionario nuestra clave, aunque todo eso
se una en contra nuestra, nuestro ssh no va a estar disponible para el exterior; por lo tanto,
un ataque desde fuera, desde la Internetn o ser efectivo va ssh, pues este no estar
atendiendo ningn tipo de peticin desde fuera.

Esta opcin no es obligatoria, slo la recomiendo para empresas o personas que sepan que
no van a acceder via ssh desde fuera de su red.

2.9.2. Otras opciones de configuracin del sshd
Muchas personas recomiendan que no se entre como root de forma remota, cul es el
objetivo? Bsicamente que en caso de que alguien desee intentar adivinar mediante un
ataque de diccionario la clave de root, de forma remota, el sshd siempre rechazar las
conexiones con el usuario root, por lo tanto ya sea vlida o invlida la clave no se aceptaran
esas conexiones y el atacante no sabr cul clave usar para entrar.

De qu forma se entrara?

-Pero con esto, nosotros tampoco podramos entrar como root, - dice Gabriel.

- No, pero entraramos por ssh con otro usuario normal del sistema (UID>=500) y,

57
posteriormente, haramos un su - para entrar como root.

De esta forma, el atacante ahora tiene doble trabajo: Uno, adivinar la existencia o no de un
username (usuario) del sistema y dos: Adivinar la clave que usa este usuario para entrar.

Es una forma bastante efectiva de minimizar un ataque de diccionario. Para esto podramos
buscar dentro de sshd_config una lnea que dice:

#PermitRootLogin yes

y la descomentamos, ponemos no. De esta forma prohibiramos que el root entre va ssh a
nuestro sistema. Slo podrn entrar usuarios que no sean root y hacer su

PermitRootLogin no

Al reiniciar el servicio de sshd (service sshd restart), nuestro servicio de SSH quedar listo
para aceptar cualquier usuario excepto el usuario root, por lo que un atacante no podr
jams descubrir nuestra clave de root.

2.10. Otras opciones del SSH
2.10.1. Ms que un Shell seguro
Una interfaz de lnea de comandos segura es slo el inicio de las muchas maneras de usar
SSH. Dada una cantidad apropiada de ancho de banda, las sesiones X11 se pueden dirigir
por un canal SSH. Por otro lado, usando reenvo TCP/IP se pueden asignar conexiones de
puerto entre sistemas que previamente eran inseguros a canales SSH especficos.
2.10.2. Reenvo por X11
Gabriel, te voy a ensear a reenviar por X11. En primer lugar, debes saber que abrir una
sesin X11 a travs de una conexin SSH establecida es tan fcil como ejecutar un
programa X en una mquina local. Cuando un programa X se ejecuta desde un intrprete de
comandos de shell segura, el cliente y el servidor SSH crean un nuevo canal seguro dentro
de la conexin SSH actual, y los datos del programa X se envan a travs de ese canal a la

58
mquina cliente de forma transparente.

Como podrs imaginar, el reenvo por X11 puede ser muy til. Por ejemplo, se puede usar el
reenvo por X11 para crear una sesin segura e interactiva con up2date. Para hacer esto,
conctate al servidor usando SSH y escribe:

ssh -XYC ipdelamaquinaremota up2date &

Despus de proporcionar la contrasea de root para el servidor, la Agente de actualizacin
de Red Hat aparecer y le permitir al usuario remoto actualizar con seguridad el sistema
remoto.

Si te fijas bien, usamos 3 opciones adicionales, una ya la conocemos, es C (compresin); la
X le activa la opcin de reenvo de X11, y la Y indica que trabaje con conexiones de X11
confiables.
2.10.3. Reenvo del puerto
Con SSH se pueden asegurar los protocolos TCP/IP a travs del reenvo de puertos.
Cuando uses esta tcnica, el servidor SSH se convierte en un conducto encriptado para el
cliente SSH.

El reenvo de puertos funciona mediante el mapeado de un puerto local en el cliente a un
puerto remoto en el servidor. SSH te permite mapear cualquier puerto desde el servidor a
cualquier puerto en el cliente; y los nmeros de puerto no necesitan coincidir para que esto
funcione.

Para crear un canal de reenvo de puerto TCP/IP que escuche conexiones del host local,
utiliza el siguiente comando:

ssh -L local-port:remote-hostname:remote-port username@hostname

Recuerda algo importante: La configuracin del reenvo de puertos para que escuche
puertos bajo 1024 requiere acceso de root.

-No lo olvidar, asegura Gabriel.


59
-Si quieres verificar tu correo en el servidor llamado mail.example.com usando POP3 a
travs de una conexin encriptada, debes usar el siguiente comando :

ssh -L 1100:mail.example.com:110 mail.example.com

Una vez que el canal de reenvo de puerto est entre la mquina cliente y el servidor de
correo, puede direccionar su cliente de correo POP3 para usar el puerto 1100 en su host
local para comprobar el nuevo correo. Cualquier peticin enviada al puerto 1100 en el
sistema cliente ser dirigida seguramente al servidor mail.example.com.

Si mail.example.com no est ejecutando un servidor SSH, pero otra mquina en la misma
red s lo est haciendo, SSH todava puede ser usado para asegurar parte de la conexin.

-Y uso el mismo comando?- pregunta Gabriel.

-No, no usas el mismo; usas un comando ligeramente diferente:

ssh -L 1100:mail.example.com:110 other.example.com

En este ejemplo se est reenviando las peticiones POP3 desde el puerto 1100 en la
mquina cliente, a travs de una conexin SSH en el puerto 22, al servidor SSH,
other.example.com. Luego, other.example.com se conecta al puerto 110 en
mail.example.com para verificar nuevo correo. Observa que usando esta tcnica, slo la
conexin entre el sistema cliente y el servidor SSH other.example.com es segura.

2.11. Realizando respaldos remotos con SSH
-Gabriel, hoy es nuestro ltimo da. Pero t tienes que seguir investigando por tu cuenta. -Le
dice Ricardo a su alumno en cuanto lo ve llegar.
-No hay problema, profe. Me encanta Linux.
-Bien, entonces, sigamos con SSH.
2.11.1. tar - ssh
Esta mezcla de comandos es muy til para cuando en el sistema local casi no tenemos
espacio, por lo tanto podemos realizar un tar pero no guardarlo localmente, sino enviarlo al
vuelo hacia otra mquina remota que s tiene espacio y, por lo tanto, se ocupar de guardar

60
todo lo que no cabe en el sistema local.

Una forma muy comn de realizar respaldos remotos al vuelo es mezclar el comando tar con
el SSH. Mira, el comando es muy simple:

tar zcvf - /etc | ssh 192.168.1.1 "cat - >etc.tar.gz"

Esto lo que hara en su primera parte (delante del | ) sera crear (c) un tar comprimido (z) y
verbose (v) hacia el archivo (f) de salida estndar (-), del directorio /etc.

Al salir por stdout, lo podemos capturar con | y pasrselo al standard input del SSH. Este lo
que har ser conectarse al servidor 192.168.1.1 y ejecutar, en esa mquina el comando
cat, tomando lo que llega por su estndar input (-) y redirigindolo hacia etc.tar.gz y, por lo
tanto, creando, en el servidor remoto, el archivo comprimido.
-Esto lo voy a tener que volver a analizar!- dice Gabriel con un suspiro.
-No es tan difcil! Solo requiere algo de concentracin. Listo para seguir?- pregunta
Ricardo, que en cuento ve el gesto afirmativo de su alumno prosigue:

Como detall, debemos indicar que hemos usado las comillas (") al ejecutar el cat para
indicarle al sistema que es un comando completo que se debe ejecutar en el servidor remoto
(desde cat hasta gz, todo lo que va entre comillas).

De no haber puesto comillas, el sistema local, el que hace el tar, hubiera redirigido la salida
del comando tar hacia un archivo local (no en 192.168.1.1 sino local al servidor que hace el
tar) llamado etc.tar.gz, que no contendra un tar.gz, sino realmente la salida del tar
(verbose), lo que ira diciendo el tar.

-Mmmm, me queda ms o menos claro, dice Gabriel arrugando el entrecejo.

-Mira, te pongo un ejemplo. Bsicamente, y usando smbolos matemticos, el sistema
hubiera pensado as, recuerda que es un ejemplo para que lo entiendas mejor, naturalmente
no funcionar, es solo para que te hagas una idea de cmo lo hubiera codificado el sistema:

(tar zcvf - /etc | ssh 192.168.1.1 cat -) >etc.tar.gz

Hubiera hecho un tar, lo hubiera mandado hacia salida estndar, lo hubiera capturado con

61
SHH y le habra obligado al cat a mostrar en la salida estndar (el vaco pues nadie vera
esto) del sistema remoto. Y el sistema local habra redirigido toda la salida verbose del tar
hacia un archivo llamado etc.tar.gz localmente.

Sin embargo, al hacerlo con comillas, le hemos indicado correctamente qu hacer:

tar zcvf - /etc | ssh 192.168.1.1 (cat - >etc.tar.gz)

Ah s, el signo de redireccin (>) se mandara a ejecutar en el sistema remoto y no en el
local.

Para recuperar, podramos haber hecho lo contrario:

ssh 192.168.1.1 cat etc.tar.gz | tar -zxvf -

Lo que har ser conectarse al sistema remoto (192.168.1.1) y har un cat hacia la salida
estndar, la cual ser capturada (|) y redirigida a mi mquina local al comando tar, que abrir
(x) el archivo que viene en la entrada estndar (f -), que es un archivo comprimido (z).

De esta forma, de forma remota, hemos abierto al vuelo un archivo y lo hemos
descomprimido hacia nuestra mquina local.
2.11.2. Autenticacin automtica
La autenticacin automtica nos permite entrar a una mquina remota sin tener que teclear
la clave.

-En serio?, pregunta Gabriel levantando un poco sus cejas.

- En serio. Mira, para realizar este proceso, debemos generar una clave en nuestra mquina
de ORIGEN (nuestra estacin de trabajo) y enviar esta clave al servidor de DESTINO (al que
queremos conectarnos sin tener que poner la clave). El proceso es muy simple:

[root@eperez ~]#ssh-keygen -t dsa

Generating public/private dsa key pair.


62
Enter file in which to save the key (/root/.ssh/id_dsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /root/.ssh/id_dsa.

Your public key has been saved in /root/.ssh/id_dsa.pub.

The key fingerprint is:

ed:e7:ba:5e:85:47:ec:09:07:6b:be:b9:ea:51:71:6a root@eperez.ecualinux.com

En este caso en mi mquina de desktop (la de origen, desde donde me conectar sin clave)
he invocado al comando ssh-keygen -t dsa.

Lo que hace es generar una clave encriptada con el algoritmo dsa.

ssh-keygen nos pregunta en qu archivo queremos guardar nuestra clave encriptada y nos
sugiere que sea en /root/.ssh/id_dsa. Sugiero dar ENTER para dejar ese archivo por defecto.

Despus, nos pide una frase clave. Si indicramos aqu una frase clave, esta siempre se nos
pedir para culminar la autenticacin. Como queremos entrar sin tener que teclear nada,
demos igualmente ENTER para dejar en blanco esto.

Al final, nos guarda nuestra clave pblica de autenticacin en /root/.ssh/id_dsa.pub

Tendremos, por lo tanto, una clave privada que mantendremos siempre en /root/.ssh/id_dsa
y que no debemos dar a nadie, una clave privada que el sistema ha puesto en
/root/.ssh/id_dsa.pub

Hasta ahora, no hemos hecho nada ms que generar nuestra propia clave (pblica y
privada), que no est en uso todava.

Tenemos que copiar la clave pblica hacia cualquier sistema remoto al que queramos

63
conectarnos (servidor de destino) para que l sepa hacer uso de esta clave.

El proceso es simple:

cat /root/.ssh/id_dsa.pub | ssh 192.168.1.1 "cat - >>~/.ssh/authorized_keys2"

Esto lo que har ser copiar nuestra clave pblica hacia el directorio .sshd que est en la
raz (~) y agregar (>>) los contenidos de nuestra clave pblica al archivo authorized_keys2.

-Por qu agregar (>>) y no sencillamente sobrescribir (>)? -pregunta Gabriel.

-Pues porque el sistema remoto puede tener varias claves pblicas de otras estaciones de
trabajo guardadas y no queremos daar el acceso de otros.

Una vez guardada nuestra clave pblica, podremos entrar al sistema remoto sin tener que
teclear la clave. Probemos:

[root@eperez ~]#ssh 192.168.1.90 ls

etc.tar.gz

-Funciona! nos dej entrar al sistema remoto sin clave...- dice Gabriel muy sonriente- Y
profe, qu ventajas tiene hacer esto?

- Tiene algunas ventajas. Mira, en primer lugar, que usamos un mtodo de autenticacin de
llave pblica/privada. Por otro lado, no tenemos que teclear clave de acceso y, por ltimo,
slo el que tenga nuestra llave privada (/root/.ssh/id_dsa) podr acceder a un sistema
remoto.

Ahora s, si nos roban este archivo, estamos mal, pues podrn entrar al sistema sin clave,
por eso es importante saber de qu mquinas definiremos la entrada.

Fin del tema 2.

Tema 2 Acceso Remoto y Lectura de Logs

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Tema 2 Acceso Remoto y Lectura de Logs

Загружено:

Авторское право:

Доступные форматы

2

Administracin Linux II - Modalidad Virtual

Вам также может понравиться