Acceso al sistema

Lo principal al instalar un servidor RHEL será acceder al mismo. Es por eso que en este capítulo veremos las principales forma de acceso a un sistema, ya se en forma local (in situ) o remota. Analizaremos las principales formas de acceder como administrador y cual es la manera más conveniente. Por último, daremos un repaso a las principales herramientas de virtualización en RHEL.

Acceso vía consola

Tanto en RHEL como en todos los sistemas Linux siempre se debe de contemplar la posibilidad de que varios usuarios trabajen simultáneamente en un mismo equipo. Para esto, se utilizan consolas o terminales que están enlazadas a un dispositivo (archivo de dispositivo), de forma tal que cada dispositivo que le permita a un usuario interactuar con un equipo se le denomina terminal. Los terminales puede ser de entrada (como por ejemplo un lector de código de barras) o de salida (como por ejemplo una impresora), y/o ambos a la vez (como los clásicos terminales de pantalla que son de entrada y salida). Existen diversas clases de terminales de las cuales la más utilizada es el conformada por la pantalla y el teclado. El acceso a la consola o terminal es sistemas Linux/UNIX puede ser de diversos tipos: física, virtual, serial y del sistema.

Figura 1. Las consolas o terminales nos permiten administrar el sistema.

Consola física: Es la que se obtiene cuando estamos físicamente parados frente a nuestro equipo o servidor, es decir, cuando tocamos literalmente el teclado y mouse y vemos los cambios reflejados en la pantalla o monitor físico.

Consola virtual: Es una de varias terminales que emulan una consola física. Por medio de las consolas virtuales se expande la cantidad de accesos y pantallas que puede tener un sistema. Los programas mingetty y prefdm facilitan estos accesos. El primero es acceder en modo texto a una consola virtual, mientras que el segundo es para iniciar una sesión gráfica (en un entorno X Window).

Consola serial: Es un tipo de pantalla especial que se obtiene al conectarse por puerto serie. En los sistemas Linux se representa mediante el dispositivo /dev/ttySx, siendo x el número de consolas seriales (que en los sistemas RHEL actuales van de 0 a 3). Proporciona una acceso a una consola en modo texto a través un cable serial que es conectado al puerto serie del equipo objetivo. Generalmente, se utiliza para acceder desde terminales seriales como DEC VT100 o servidores de consola seriales como Cyclades TS800. Para lograr un inicio de sesión en una consola serie, debe editarse el archivo /etc/inittab para que inicie sesión con el comando agetty, el cual abre un puerto tty, solicita un nombre de entrada y ejecuta el programa /bin/login (el cual normalmente es llamado por el proceso init). Este programa es una alternativa al getty tradicional de UNIX.

Consola del sistema: La consola del sistema es utilizada por el mismo para enviar mensajes de inicio, de errores y de inicio de sesión en modo single-user (monousuario). Es representada por el dispositivo /dev/console.

Acceso gráfico y remoto

Como los primeros terminales no tenían monitor y eran simples teletipos se utilizó la denominación tty (deriva de TeleTYpe que traducido significa teletipo) para designar los dispositivos que controlan los terminales. Felizmente, los sistemas UNIX/Linux permiten la emulación de varios terminales sobre un único monitor. A estos terminales se les denominan terminales virtuales o pseudoterminales y podremos deslizarnos de un terminal virtual a otro presionando la combinación de teclas ALT + F1, ALT + F2, ALT + F3, etc. De esta forma, accederemos a los terminales /dev/tty1, /dev/tty2, /dev/tty3, etc, respectivamente. Esto es sumamente productivo, ya que en cada uno de estos terminales virtuales podemos mantener una sesión de trabajo distinta, como si tuviéramos varios terminales físicos distintos formados por un monitor y un teclado, pero sin depender de un dispositivo físico.

De esta forma el principal acceso a un sistema RHEL que actúe como servidor de aplicaciones será a través del acceso a una consola en modo texto, que no contemplará la posibilidad de ejecutar aplicaciones gráficas. Sin embargo, existen otros tipos de accesos como el gráfico a través de la instalación del sistema X Window, que generalmente es acompañado de un gestor de acceso gráfico como por ejemplo GDM, KDM, XDM, entre los principales. Además, en el servicio de acceso remoto seguro mediante SSH puede configurarse para ejecutar programas gráficos (activando una opción llamada X11Forwarding). Por último pueden obtenerse múltiples pseudoterminales en un solo terminal mediante la aplicación screen.

Configuración del servidor X11 vía Xorg

El Sistema X Window, al que generalmente se le suele llamar X11 o simplemente X, es la base de la interfaz gráfica de usuario (representado por las siglas GUI que en inglés significan Graphical User Interface) en los sistemas RHEL. Este sistema es mantenido por la entidad X Consortium bajo licencia open source (de código abierto). El proyecto Xorg, originario de la fundación que lleva su mismo nombre, agrega drivers para soportar una amplia variedad de hardware, desde placas de videos hasta dispositivos de entrada y puede correr en mucas plataformas y sistemas operativos.

Arquitectura cliente/servidor en X

El Sistema X Window utiliza la arquitectura cliente/servidor, en donde un servidor está a la espera de conexiones (escuchando) desde clientes con aplicaciones X. Estas conexiones pueden ser vía red, como sucede en los servidores corporativos, o a través de la interfaz de red local (loopback), como sucede en la mayoría de los sistemas de escritorio. El servidor X se comunica con los distintos periféricos (placa de video, monitor, teclado y mouse), mientras que la aplicación X del lado del cliente crea la GUI para el usuario enviando las peticiones a este servidor.

Configuración del servidor X

Actualmente, RHEL viene con el programa X11R7.1 como base del Sistema X Window. Todas las bibliotecas, headers (archivos de cabeceras del lenguaje C) y los binarios se encuentras en el directorio /usr (/usr/X11R6 ya es obsoleto). El directorio que contiene los archivos de configuración tanto del cliente como del servidor X se guardan en el directorio /etc/X11 junto con el resto de las configuraciones. Por ejemplo, el archivo de configuración de las fuentes (donde residen las distintas tipografías) es /etc/fonts/fonts.conf.

Debido a que el servidor X realiza tareas avanzadas en una amplia gama de hardware, se requiere información detallada sobre el hardware que trabaja. El servidor X detecta automáticamente parte de esta información; otros detalles deben ser configurados.

Al momento de la instalación, a menos que se le indique lo contrario, se instalará y configurará automáticamente el servidor X. Hay que tener en cuenta, que cualquier cambio en la placa de vídeo, monitor u otros dispositivos harán necesario la reconfiguración el entorno X. Una recomendación en estos casos es utilizar la Herramienta de configuración de X que se invoca desde el intérprete de comandos escribiendo como administrador la instrucción system-config-display. De igual modo, si hemos instalado Gnome (el entorno gráfico predeterminado de RHEL), podremos sencillamente ir al borde superior de la pantalla y seleccionar en el menú Sistema/Administración/Pantalla. No olvidemos que los cambios realizados tendrán efecto siempre después de cerrar y volver la sesión. Por otro lado, hay que indicar en algunos casos quizás haya que reconfigurar manualmente el servidor X editando directamente el archivo /etc/X11/xorg.conf, que es el archivo principal de configuración. Esto último debe realizarse solo en caso de que la reconfiguración automática mediante la instrucción system-config-display --reconfig falle.

Figura 2. Gnome es el entorno gráfico por defecto en los sistemas RHEL.

Entornos de escritorio

Un entorno de escritorio integra un conjunto de programas para lograr la interacción entre el usuario y servidor. Brinda una solución completa de GUI, permitiendo el acceso y configuración, mediante barras de herramientas e integración entre aplicaciones con habilidades como arrastrar y soltar. Un entorno de escritorio por lo general consiste de iconos, ventanas, barras de herramientas, carpetas, fondos de pantalla y widgets de escritorio. RHEL dispone de dos principales entornos de escritorio: Gnome y KDE.

GNOME es el entorno gráfico que viene por defecto. Estable y de consumo medio de recursos del sistema, es rápido, ágil, amigable e intuitivo al usuario. Está basado en el kit de librerías GTK+ 2.

KDE, sin embargo, es una alternativa estable, robusta, pero poco liviano. Es todo lo opuesto a un entorno minimalista. Está basado en el kit de librería Qt 3.

Figura 3. KDE es el entorno gráfico alternativo en los sistemas RHEL.

Dato útil- XFCE, una mejor alternativa

No estamos condenados a utilizar solamente Gnome y KDE como sistemas de escritorio. El entorno XFCE es reconocido como un escritorio liviano y rápido para sistemas UNIX/Linux, ya que realiza un bajo consumo de los recursos del sistema, a la vez que brinda una interfaz atractiva visualmente, fácil y amigable para el usuario.

Gestores de ventanas

Los gestores de ventanas son programas cliente de X cuyo propósito principal es controlar la forma en ventanas gráficas son posicionadas, redimensionadas o movidas. Los mismos pueden ser independientes (también llamados stand-alone) o parte de un entorno de escritorio Los gestores de ventanas controlan las barras de título, comportamiento del foco, y acciones del cursor, entre otros. RHEL dispone de los siguientes gestores de ventanas:

-KWin, que es el gestor por defecto para KDE (viene incluido en ese metapaquete). Eficiente y altamente personalizable.

-Metacity, que es gestor por defecto para GNOME. Simple, sencillo y eficiente. Soporta temas personalizados. Puede funcionar con cualquier otro entorno de escritorio, solo hace falta instalar el paquete metacity.

-Mwm, que es el gestor Motif. Es independiente y sencillo pero no debe ser usado en conjunción con GNOME o KDE (se instala a través del paquete openmotif.

-Twm,que es un gestor minimalista. Es independiente, sencillo y puede ser utilizado con GNOME o KDE (viene incluido en la suite X11R7.1).

Figura 4. Fluxbox es el gestor de ventanas ultraminimalista utilizado por los expertos.

Curiosidades: Fluxbox, el mejor escritorio

Aunque solo es un gestor de ventanas y no un entorno de escritorio en sí (como KDE o Gnome) Fluxbox es el más eficiente conocido hasta hoy. Altamente minimalista, proporciona un menú intuitivo y de uso sencillo. Altamente recomendable para hackers, administradores de servidores y gente que le prefiera la sencillez por sobre la usabilidad. Está basado en BlackBox que a su vez está basado en WindowMaker y disponible (en rpm) para instalar desde el repositorio EPEL.

El entorno X y los niveles de ejecución

En la mayoría de las instalaciones de RHEL el sistema gráfico está habilitado por defecto al inicio. Esto se debe a que luego de cargar el kernel se ejecuta el proceso init que da lugar al nivel de ejecución (runlevel) número 5. Sin embargo, es posible iniciar el modo multiusuario sin el entorno gráfico eligiendo el runlevel 3 como nivel de ejecución al inicio y luego invocarlo mediante el comando startx.

Cuando estamos en el runlevel 3 y ejecutamos startx, se ejecutará comando xinit, que a su vez lanzará el servidor X (Xorg) e interconectará las aplicaciones cliente necesarias. Al estar logueados con un usuario en el sistema, ya no será necesario un display manager (autenticador gráfico de usuarios). Cuando ejecutamos startx se inicia la búsqueda de la preferencia del entorno gráfico especificado en el archivo de configuración .xinitrc dentro del directorio home del usuario. Si este archivo no existe, en su lugar se utiliza la configuración predeterminada del archivo /etc/X11/xinit/xinitrc.

Acceso remoto y cifrado vía SSH

Antiguamente la única manera de conectarse remotamente a un equipo era mediante telnet (y los comandos r* basados en rlogin, similar a telnet). Este protocolo no cifraba los paquetes que se enviaban al conectarse los equipos y por lo tanto representaba una falla de seguridad ya que cualquier nodo que estuviese conectado a la red a la que pertenecen dichos equipos por medio de un sniffer (capturador de paquetes) podía detectar todo el tráfico y por ende espiar todas las conexiones. Por esa razón fue vital cifrar las conversaciones TCP/IP bajo un protocolo seguro, tarea que comenzó en el año 1995 a realizar un finlandés llamado Tatu Ylönen bajo el nombre de SSH (Secure SHell). Al comienzo, en su primera versión, tanto el protocolo como el programa eran libres pero esto luego fue cambiando ya que exigió el pago a empresas. Es por eso que a principios de 1999, el grupo de hackers de OpenBSD al mando del ingeniero de software Theo de Raadt) comenzaron a escribir una versión totalmente libre, denominada OpenSSH y que al poco tiempo se convirtió en la implementación de SSH por excelencia. Al instalar el paquete openssh-clients en RHEL se instalarán un conjunto de aplicaciones opensource para el protocolo SSH, como por ejemplo: scp, sftp, slogin y por supuesto ssh.

El comando ssh nos permite acceder a una shell remota, es decir, conectarnos a un servidor que está en otro lugar mediante un intérprete de comandos. La sintaxis del comando SSH es simple:

ssh [usuario@]host

Aquí usuario y host son el nombre de usuario y equipo del sistema objetivo respectivamente. Para copiar archivos de forma segura debemos utilizar el programa scp con la siguiente sintaxis:

scp [-rp] fuente destino

También es posible utilizar la aplicación SSH para ejecutar comandos remotamente el servidor destino, su sintaxis es:

ssh [user@]host 'comando'

Por ejemplo, si deseamos saber (mediante el comando ifconfig) la configuración de la primer placa de red (eth0) de un servidor llamado test y nuestro usuario es root, debemos escribir:

ssh root@test 'ifconfig eth0'

Figura 5. Wireshark es un programa gráfico que permite capturar paquetes de red.

Implementación de llaves RSA en SSH

SSH soporta autenticación basada en pares de claves. Los protocolos más conocidos son RSA y DSA siendo esté último el más lento y seguro. Para generar el par de llaves publica y privada RSA debemos ejecutar la instrucción:

$ ssh-keygen -t rsa

Luego, debemos copiar la llave pública al servidor remoto que seamos acceder sin escribir la contraseña:

$ ssh-copy-id -i .ssh/id_rsa.pub user@host

Para probarlo, simplemente debemos conectarnos como lo haríamos normalmente:

$ ssh user@host

Clientes X remotos

Muchas veces será necesario ejecutar una aplicación gráfica en un entorno X. Como el protocolo de comunicación de X es sin encriptar, podremos valernos del cifrado que proporciona el protocolo SSH para garantizar la seguridad en la comunicación. La sesiones pueden ser validados por host o por usuario. Para aceptar conexiones gráficas desde cualquier equipo sin importar el usuario bastará con ejecutar la instrucción:

$ xhost +

Naturalmente, esto representa un bug en la seguridad y no debería estar presente en ningún servidor productivo, ya que una persona con conocimientos medios podrá saber lo que hay en nuestra pantalla, las aplicaciones que estamos ejecutando en nuestra ventana e incluso manipularlas, por ejemplo para borrar un archivo. Para deshabilitar está acción debemos ejecutar:

$ xhost -

En caso de que quisiéramos que un equipo específico accediera, por ejemplo un equipo denominado rhel_cliente debemos escribir en el servidor:

$ xhost +rhel_cliente

Por el contrario, para desautorizarlo debemos cambiar el signo + por el -. La autenticación también puede ser por usuario a través del comando xauth. Para que el mismo funcione la variable de entorno $DISPLAY no debe apuntar al localhost ni a cualquier otros excepto el nombre real del servidor (export DISPLAY=:0.0). Al ejecutarlo por primera vez se creará el archivo $HOME/.Xauthority. Por ejemplo, supongamos que tenemos el equipo llamado cliente y otro llamado servidor. Al ejecutar xauth por primera vez, seleccionamos una contraseña de hasta 16 pares de dígitos hexadecimales (números del rango 0-9 y a-f), como se muestra a continuación.

En el equipo cliente:

$ xauth
xauth: creating new authority file $HOME/.Xauthority
Using authority file $HOME/.Xauthority
xauth> add Nombre_de_C:8 MIT-MAGIC-COOKIE-1 <clave>
xauth> exit

En el equipo servidor, el comando es el mismo, pero la sintaxis de adentro cambia como se muestra a continuación:

$ xauth
xauth: creating new authority file $HOME/.Xauthority
Using authority file $HOME/.Xauthority
xauth> add Nombre_de_D/unix:0 MIT-MAGIC-COOKIE-1 <clave>
xauth> add Nombre_de_D:0 MIT-MAGIC-COOKIE-1 <clave>
xauth> exit

Al iniciar el servidor X en el equipo servidor debemos agregar el parámetro -auth $HOME/.Xauthority, por ejemplo:

exec X -auth $HOME/.Xauthority
$*

Autenticación gráfica X

Existen 2 formas de conectarnos gráficamente a un servidor: XAuth vs XHost. El primero es el más seguro porque los clientes que intentan conectarse al servidor deben conocer un identificador secreto residente en la memoria de este último. A este identificador se le conoce como MIT-MAGIC-COOKIE. XHost es menos seguro porque al ser la autenticación por nombre de host es posible que alguien engañe al servidor haciendose pasar por un equipo que no es.

Iniciar una conexión gráfica segura

Como mencionamos es posible valernos de la riqueza y fortaleza del protocolo SSH para encriptar nuestras sesiones X o programas gráficos que ejecutemos. Esto es tan sencillo como agregar el parámetro -X al iniciar una conexión ssh contra el servidor remoto. La sintaxis es la siguiente:

$ ssh -X equiporemoto 'aplicacionX'

Compartiendo multiples sesiones de terminal con screen

Muchas veces al realizar una tarea en un servidor remoto es necesario desconectarnos y luego volver a conectarnos sin que se detenga la tarea (proceso) que hemos lanzado. Aunque existen diversas formas de lograr que un proceso se mantenga en ejecución en segundo plano, por ejemplo a través del comando nohup, la redirección o invocándolo como demonio; es recomendable utilizar el comando screen, ya que además de realizar esta tarea nos permitirá abrir múltiples terminales. Supongamos que en un servidor remoto estamos compilando un programa que lleva bastante tiempo, en vez de pasarnos el tiempo viendo pasar todas las líneas de compilación podremos iniciar una conexión screen abrir otro terminal y continuar trabajando, o simplemente cerrar la conexión e irnos, ya que la compilación no se detendrá. Para ejecutar este comando simplemente debemos escribir:

$ screen

Veremos como la pantalla actual como si se hubiese limpiado con el comando clear y el título de nuestra ventana cambiará a [screen 0: bash]. Debemos entender que esta aplicación se maneja mediante combinaciones de teclas, es decir, presionando varias teclas en combinación, como vemos en la siguiente tabla sobre las teclas rápidas del comando screen.

Teclas rápidas de screen
Combinación de teclas	Uso
CTRL + A, C	Crea/Abre otra terminal virtual (Create)
CTRL + A, N	Cambia de una terminal abierta a otra, en este caso a la próxima (Next)
CTRL + A, P	Cambia de una terminal abierta a otra, en este caso a la anterior (Previous)
CTRL + A, CTRL + D	Cierra el terminal actual pero sin detener los procesos en ejecución asociados al mismo (Detach)
CTRL + A, CTRL + \	Cierra la aplicación y todas sus terminales asociadas
CTRL + A, CTRL + ?	Muestras las combinaciones de teclas

Tabla 1. Teclas rápidas para acceder a los comandos de screen.

Como cada terminal virtual recibe un número, podremos conectarnos remotamente desde cualquier otro equipo e invocar de nuevo a cualquiera de ellas agregando el parámetro -r seguido del número de terminal asignado. En el caso de haber solo un terminal virtual bastará con solo indicar la opción -r (sin el número).

Figura 6. Terminal virtual en un sistema RHEL productivo.

Curiosidades: El polifacético screen

Las ventajas del programa screen es que se pueden iniciar desde una solo ventaba uno o más terminales, y cada uno de ellos será independiente con respecto al otro. Además, podremos ejecutar procesos en segundo plano y continuarlos incluso si cambiamos de ventana. Podremos desacoplar una ventana si detener sus procesos en ejecución, a la vez que podremos compartirla con otros usuarios, ya que está aplicación es altamente parametrizable.

Escalando privilegios

El comando su es utilizado para cambiar de usuario en el sistema. Generalmente se utiliza para escalar a root desde un usuario sin privilegios. Es importante destacar que solo se debe acceder como root en casos estrictamente necesarios ya que puede poner en riesgo la estabilidad y seguridad del sistema. Cualquier cambio que se haga en el sistema con el usuario root puede ser irreversible. En la mayoría de los sistemas, al utilizar este comando se dejará constancia en los registros del sistema. Al momento de su ejecución es conveniente acompañarlo del parámetro - que permitirá acceder con un nuevo intérprete de comandos (shell) y con las nuevas variables de entorno correspondientes al usuario que se cambia (por ejemplo: si es root, el entorno será de dicho usuario).

El comando sudo es utilizado para delegar privilegios de root en usuarios sin privilegios. Todo se maneja a través del archivo /etc/sudoers, que contiene las referencias a variables, usuarios, grupos de usuarios y comandos. Aunque el mismo puede ser editado manualmente mediante vi (editor de textos nativo en todos los UNIX/Linux) en conveniente que sea editado a través de la herramienta visudo, que guardará una copia del actual archivo y verificará que la sintaxis sea correcta al momento de guardar y/o salir del programa. También es aconsejable especificar que vi sea el editor por defecto del sistema editando la variable EDITOR (por ejemplo: export EDITOR=vi).

Diferencias entre su y sudo

Hay que destacar una diferencia importante entre los comandos su y sudo, en el primero la contraseña de root debe ser compartida, es decir, el usuario normal que quiera escalar al usuario administrador (root en los sistemas GNU/Linux) tendrá que conocer inexorablemente la contraseña del mismo; mientras que en el segundo, (si el usuario está agregado a la lista de usuario permitidos) no hará falta ingresar ninguna contraseña excepto la del propio usuario que ejecuta el comando.

En la práctica, al ejecutar su:

$ su -
password:

Y cuando nos solicita password debemos ingresar la contraseña de root. En cambio al ejecutar sudo (previamente configurado mediante el comando visudo):

$ sudo comando

En este caso, ingresaremos solo la nuestra contraseña. Hay que tener en cuenta que para que el comando sudo funcione necesita tener configurado el SETUID correcto. Si el mismo no está activado nos dará el siguiente mensaje de error:

[matias@redhat ~]$ sudo su -
sudo: must be setuid root

Al comprobar los permisos sobre el comando sudo, detectamos el problema:

[matias@redhat ~]$ ls -l /usr/bin/sudo
---x--x--x. 2 root root 219272 jul 19 06:41 /usr/bin/sudo

Esto se soluciona activando el SETUID, esto se debe hacer ejecutando como root (administrador) con cualquiera de estas instrucciones:

# chmod 4111 /usr/bin/sudo
# chmod u+s /usr/bin/sudo

Figura 7. Ejecución de los comandos su y sudo para ascender a root.

Al comprobar los permisos sobre el comando sudo, esta vez el problema se ha solucionado:

[matias@redhat ~]$ ls -l /usr/bin/sudo
---s--x--x. 2 root root 219272 jul 19 06:44 /usr/bin/sudo

Probamos de que efectivamente podamos ascender a root:

[matias@redhat ~]$ sudo su -
[root@redhat ~]# whoami
root

De esta manera el usuario matias ha ascendido al usuario root. El comando whoami sirve para saber que usuario somos. Vemos como atrás de la arroba (@) cambio el nombre de usuario. Generalmente en los sistemas RHEL la nomenclatura del interprete de comandos bash para todos los usuario excepto root, se compone de la siguiente manera:

[nombre_usuario@nombre_host ultimo_directorio]$

Para el usuario root la nomenclatura es:

[root@nombre_host ultimo_directorio]#

De igual modo, esto puede cambiarse o personalizarse cambiando la clave $PS1 en el archivo .bash_profile que por defecto es: PS1="[\u@\h:\l \W]\\$ ".

Cuando se inicia un proceso, este se ejecuta con los permisos de usuario que lo origina. Por ejemplo, si ejecutamos el programa vi y tratamos de editar un archivo del que no tenemos permisos de lectura o escritura, la operación fallará. Pero, si el SUID o el SGID están activos en un archivo ejecutable, este se ejecutará con los permisos del propietario o grupo propietario de dicho archivo respectivamente. Por ejemplo, al considerar el archivo que guarda las contraseña del sistema, vemos los permisos:

[matias@redhat ~]$ ls -l /etc/shadow
----------. 1 root root 1105 ago 22 09:11 /etc/shadow

Esto significa que el archivo será leído y modificado solo por el usuario root (el root todo lo puede). Ahora vemos el caso del programa passwd, que se utiliza para cambiar la contraseña de cada usuario, este poseé permisos de ejecución para todos y tiene el SUID activo:

[matias@redhat ~]$ ls -l /usr/bin/passwd
-rwsr-xr-x. 1 root root 30768 feb 17 2012 /usr/bin/passwd

Figura 8 Ejecución del comando passwd intentando cambiar la contraseña de un usuario.

El cuarto caracter es la letra s, que simboliza el SUID activo, en este caso significa que el programa será ejecutado como root aunque sea un usuario sin privilegios el que lo haya solicitado. De está forma, cualquier usuario puede modificar su propia contraseña con este comando, el cual modifica el archivo /etc/shadow que solo puede ser modificado por el root. Es decir, que el SUID nos permite realizar tareas que son de root sin serlo. Esta técnica, que aparece en muchos programas del sistema, representa un problema de seguridad y es aconsejable que reducir al mínimo la cantidad de archivos que tienen activo dicho permiso. Si un programa binario y compilado que tiene dicho permiso activo representa un potencial problema de seguridad, más lo es en el caso de los scripts, ya que estos pueden ser hackeados (es decir, modificados y manipulados para benificio del atacante).

Administrando sudo

Como hemos mencionado es una buena práctica configurar los accesos de root a través de sudo con la herramienta nativa visudo. Para ello debemos ejecutar dicho comando como se muestra a continuación:

# visudo
Cmnd_Alias KILL = /usr/bin/kill
%wheel ALL=(ALL) NOPASSWD: ALL
matias localhost=(ALL) KILL

El archivo sudoers sigue está sintaxis:

usuario EQUIPO = (EjecutarComo) PROGRAMA

En el ejemplo anterior, el usuario matias podrá ejecutar como root (ALL) en su propio equipo (localhost) el comando kill (KILL es una alias al comando /usr/bin/kill).

Para probarlos podemos ejecutar algún comando que antes no pudiesemos:

$ sudo kill -9 <pid_del_proceso>

Virtualización con virt-manager y virsh

Red Hat utiliza KVM a través de VMM (Virtual Machine Manager) como sistema de virtualización. La aplicación virsh permite la administración de los clientes pertenecientes a dominio de virtualización y el hypervisor (monitor/supervisor). Esto significa que puede ser utilizado para crear, pausa y detener equipos virtuales. También se puede usar para listar los equipos que se están virtualizando actualmente. Esta compilado en base a la librería libvirt, la cual permite interactuar con las capacidades de virtualización de versiones recientes de Linux además de otros sistemas de virtualización como son Xen y KVM en otros, ya que está programada en C y pensada como un conjunto de herramientas estándar.

Este comando debe ir acompañado del parámetro deseado. Por ejemplo, para ver información del hypervisor debemos agregar el parámetro nodeinfo como se muestra a continuación:

# virsh nodeinfo
CPU model: x86_64
CPU(s): 4
CPU frequency: 3059 MHz
CPU socket(s): 1
Core(s) per socket: 2
Thread(s) per core: 2
NUMA cell(s): 1
Memory size: 5917228 kB
dominfo, del huesped.

Si deseamos ver información sobre el dominio de un determinado cliente o húesped:

# virsh dominfo webdav
Id: 1
Nombre: webdav
UUID: be4fa9hf-2178-02fe-ddc2-6fcac4fd9nd8
Tipo de sistema operativo: hvm
Estado: ejecutando
CPU(s): 1
hora del CPU: 194395,4s
Memoria máxima: 1048576 kB
Memoria utilizada: 1048576 kB
Persistent: yes
Autoinicio: activar
Modelo de seguridad: selinux
DOI de seguridad: 0
Etiqueta de seguridad: system_u:system_r:svirt_t:s0:c399,c773 (permissive)

Para listar y monitorear las maquinas virtuales disponibles, debemos ejecutar:

# virsh list
Id Name State
----------------------------------
1 webdav running
2 rhel01 running

# virsh list --all
Id Name State
----------------------------------
1 webdav running
2 rhel01 running
- zeus1 shut off

Esto sería un equivalente del comando vzctl -a del sistema de virtualización OpenVZ (competencia del sistema de virtualización de RHEL). Para iniciar una maquina virtual debemos simplemente ejecutar:

# virsh start zeus1
Domain zeus1 started

En caso de que sea necesario conectarnos al hypervisor, la sintaxis será:

virsh connect <nombre_hypervisor>

Por su puesto, esto son solo los comandos básicos dentro de la gran lista de parámetros disponibles en este programa de virtualización. A continuación una lista de los comandos más utilizados:

Parámetro útiles al ejecutar virsh
Combinación de teclas	Uso
start id_dominio	Inicia maquina virtual
shutdown, reboot, destroy id_dominio	Apaga, reinicia y elimina una maquina virtual
suspend, resume id_dominio	Suspende y vuelve de la suspensión
save id_dominio archivo-estado	Guarda el estado actual de un dominio virtual
restore archivo-estado	Recupera el estado de una maquina virtual
autostart id_dominio	Permite que un dominio inicie automáticamente durante el booteo

Tabla 2. Parámetros de uso frecuente en el programa virsh.

La gestión de la virtualización en RHEL puede hacerse vía consola, como acabamos de ver, y vía gráfica mediante el comando virt-manager o ingresando al menú Applications/System Tools/Virtual Machine Manager. La aplicación virt-manager es una GUI para administrar maquinas virtuales equivalente a virsh, que permite entre otras cosas: iniciar, pausar, ejecutar, apagar, guardar, recuperar y acceder a maquinas virtuales. Además incluye un wizard (asistente) para facilitar la creación de maquinas virtuales.

Figura 9 Ejecución del programa Virtual Machine Manager en RHEL.

Resumen

Hasta aquí hemos visto como acceder y administrar desde la consola gráfica y de texto los sistemas RHEL, repasando conceptos de terminal o consola virtual hasta gestores gráficos. Aprendimos a acceder remotamente a los mismos con usuarios nominales y escalar al usuario administrador. Además, hemos accedido a sistemas virtualizados y visto como la virtualización de Red Hat es un conjunto de programas que colaboran estrechamente con el fin de organizar y administrar máquinas virtuales.

Actividades

Preguntas teóricas

1- ¿Que ventajas presenta el protocolo SSH?

2- ¿Que conviene tener en cuenta a la hora de elegir un servidor X?

3- ¿Es posible hace más seguro el acceso gráfico?

4- ¿Porque Fluxbox es la mejor alternativa gŕafica?

5- ¿Conviene instalar un sistema gráfico en un servidor productivo?

6- ¿Cómo puedo multiplicar las terminales que tengo en un servidor?

7- ¿Porque es conveniente utilizar el programa screen para procesos en segundo plano?

8- ¿Porque conviene utilizar sudo en vez de sudo?

9- ¿A que usuario corresponde la contraseña que se utiliza al utilizar por defecto el programa sudo?

10- ¿Cuales son los comandos para listar las maquinas virtuales en RHEL?

Ejercicios prácticos

1- Configurar un servidor X mediante el comando system-config-display.

2- Desde un cliente generar una conexión remota a un servidor mediante ssh user@host.

3- Incluir el parámetro -X en la conexión anterior para la habilitar aplicaciones gráficas.

4- Delegar privilegios a un usuario para que puede apagar el equipo a través de sudo.

5- Gestionar gráficamente las maquinas virtuales existentes mediante el programa virt-manager.

Plaquetas adicionales

El SUID y el SGID

A veces se necesita que un programa se ejecute con privilegios distintos (mayores o menores) que el usuario que lo lanza. Esto se soluciona activando el bit SUID del programa o archivo, así cuando se ejecute, el proceso correspondiente va a tener los privilegios del propietario del mismo, no del usuario que lo ejecutó. El SGID sigue el mismo concepto que el SUID, pero aplicado al grupo.

Variables de entorno

Las variables de entorno proporcionan un conjunto de valores dinámicos que afectan el comportamiento de los procesos. Se puede manipular el valor de cada variable, ya sea por medio de un script como desde la línea de comandos. En el caso de sistemas RHEL, depende del shell que se use, ya que éste será encargado del manejo de las variables de entorno.

Visualizando variables de entorno

Generalmente se utilizan env, set, y printenv como comandos para visualizar todas las variables de entorno junto con sus respectivos valores, aunque la dos primeras se pueden utilizar también para asignar valores a las variables de entorno.

El utilísimo comando screen

El comando screen no viene por defecto en las instalaciones de RHEL, pero puede descargarse e instalarse mediante el comando yum de la siguiente manera: yum install screen. Este programa no tiene dependencias y debe instalarse con el usuario root.

WinSCP, el equivalente al scp de Linux.

El programa WinSCP es un cliente SFTP (FTP seguro) gráfico para los sistemas operativos Windows. Esto significa que securiza el acceso FTP mediante el protocolo SSH, permitiendo la transferencia segura de archivos entre dos equipos o servidor, a la vez que facilitándonos el acceso a las carpetas de los mismos. El único requisito es que el servidor remoto esté ejecutando los servicios SSH (por ejemplo mediante OpenSSH).

¿Que es el hypervisor en la virtualización de RHEL?

El termino hypervisor, que se remota a principios de los años 1970, es una palabra inglesa que podría traducirse como supervisor/monitor de máquina virtual. Lo podríamos definir como una plataforma en la que un servidor mediante diversas técnicas de control de virtualización puede tener corriendo simultáneamente uno o más equipos virtualizados (conocidos como huéspedes), en los que estos últimos puede tener incluso sistemas operativos distintos.

Tipos de hypervisors

Los hipervisores pueden clasificarse en dos tipos: unhosted y hosted. El primero hace referencia a que el hypervisor (supervisor de recursos virtuales) se ejecuta directamente sobre el hardware, mientras que el segundo necesita de un sistema operativo anfitrión el medio (osea entre el hardware real y el software de virtualización.

¿Que es mingetty y getty?

mingetty es un pequeño programa getty para acceder a una consola. Por su parte, este último es una abreviatura de get teletype, es decir, es un programa que se ejecuta en una equipo remoto través de terminales virtuales. Cuando se detecta una conexión se solicita el nombre de usuario y se ejecuta el comando login.

Certificando RHCSA

Capítulo 2 - Acceso al sistema