Para que un usuario normal se pueda convertir en el superusuario root, debe añadirlo al grupo wheel a mano. Esto se hace por motivos de seguridad, y se recomienda tener cuidado con los usuarios a los que se otorgue este acceso especial. En OpenBSD, los usuarios que pertenezcan al grupo wheel podrán usar el programa en modo usuario ("userland program") su(1) para convertirse en el usuario root. Los usuarios que no pertenezcan al grupo wheel no podrán usar su(1). A continuación puede ver el ejemplo de una entrada en /etc/group para asociar al usuario ericj al grupo wheel.
Si va a crear un usuario nuevo con adduser(8), puede asociarlo al grupo wheel desde el punto Invite user into other groups:, simplemente contestando wheel. Esto añadirá al usuario en la línea del grupo wheel, en el fichero /etc/group, que quedará del siguiente modo:
wheel:*:0:root,ericj
Si lo que busca un modo de permitir a los usuarios acceso limitado a los privilegios del superusuario, sin tener que asociarlos al grupo wheel, use sudo(8).
10.2 - ¿Cómo puedo duplicar un sistema de
archivo?
Para duplicar su sistema de archivo use dump(8) y restore(8). Por ejemplo, para duplicar todo en el directorio SRC al directorio DST, haga lo siguiente:
# cd /SRC; dump 0f - . | (cd /DST; restore -rf - )
dump está diseñado para ofrecer una gran variedad de posibilidades para copias de respaldo/seguridad, y puede resultar excesivo si sólo quiere duplicar un único sistema de archivo o parte de él. La orden tar(1) puede resultar más rápida para una operación de este tipo. El formato es muy parecido:
# cd /SRC; tar cf - . | (cd /DST; tar xpf - )
OpenBSD usa un inicio del estilo rc(8), para lo que necesita unos cuantos ficheros claves para iniciar.
Los ficheros más importantes para un administrador de sitemas son /etc/rc.conf, /etc/rc.local y /etc/rc.shutdown. Para que se pueda hacer una idea sobre cómo funciona el procedimiento de rc(8), mire este flujo:
La mayoría de dæmons y servicios que vienen predefinidos con OpenBSD pueden iniciarse con el arranque, editando el fichero de configuración /etc/rc.conf. Un ejemplo lo puede encontrar en el fichero /etc/rc.conf que viene por definición con el sistema, en donde verá líneas parecidas a la siguiente:
ftpd_flags=NO # for non-inetd use: ftpd_flags="-D"
Una línea como ésta nos indica que ftpd no se inicia con el sistema (al menos no mediante rc(8); lea la sección sobre FTP Anónimo para más información al respecto). En cualquier caso, cada línea va acompañada por un comentario que le mostrará los indicadores para el uso NORMAL de ese dæmon o servicio. Esto no significa que debe invocar el dæmon o servicio en cuestión con esos indicadores. Siempre puede usar man(1) para ver cómo puede iniciar de cualquier otro modo que prefiera ese dæmon o servicio. Por ejemplo, vea la línea predefinida para la entrada para httpd(8):
httpd_flags=NO # for normal use: "" (or "-DSSL" after reading ssl(8))
Aquí puede ver con claridad que no es necesario ningún indicador para iniciar httpd. Por lo tanto, sólo será necesaria una línea como:
httpd_flags=""Pero para iniciar httpd con ssl (lea la sección sobre SSL o la página de manual de ssl(8)), necesitará una línea como:
httpd_flags="-DSSL"
Para instalar otros dæmons en el sistema por medio de los portes o cualquier otro medio, debe usar el fichero /etc/rc.local. Por ejemplo, supongamos que se ha instalado un dæmon que se encuentre en /usr/local/sbin/daemonx, y que se desea iniciar durante el arranque del sistema. Para ello pondría una entrada como la siguiente en /etc/rc.local:
if [ -x /usr/local/sbin/daemonx ]; then
echo -n ' daemonx'; /usr/local/sbin/daemonx
fi
Desde este momento, el dæmon será invocado durante el arranque. También podrá ver cualquier error durante el arranque; un arranque normal sin errores sólo mostraría una línea como ésta:
Starting local daemons: daemonx.
/etc/rc.shutdown es un guión (script) que se invoca al cerrar el sistema. Cualquier cosa que quiera hacer antes de que se cierre el sistema, la debe añadir a este fichero. Si tiene apm, también puede configurar "powerdown=YES", que le dará un resultado equivalente a 'shutdown -p'.
Pruebe lo siguiente:
# cat /etc/mail/sendmail.cf | grep relay-domains
La salida será parecida a ésta:
FR-o /etc/mail/relay-domains
Si este fichero no existe, créelo. Necesitará introducir los huéspedes que estén enviando correo de forma remota con la siguiente sintaxis:
.dominio.com #Permitir reenvío para/a cualquier
#huésped en dominio.com
sub.dominio.com #Permitir reenvío para/a sub.dominio.com y
#cualquier huésped en ese dominio
10.2 #Permitir reenvío desde todos los
#huéspedes en la red IP 10.2.*.*
No olvide enviar una señal 'HangUP' a sendmail (una señal que hace que la mayoría de dæmons vuelvan a leer sus ficheros de configuración):
# kill -HUP `cat /var/run/sendmail.pid`
La mayoría de problemas relacionados con POP tienen que ver con ficheros temporales y ficheros de cerrojo. Si su servidor pop envía un mensaje de error como el siguiente:
-ERR Couldn't open temporary file, do you own it?
Intente configurar sus permisos así:
permisos en /var drwxrwxr-x 2 bin mail 512 May 26 20:08 mail permisos en /var/mail -rw------- 1 username username 0 May 26 20:08 username
Otra cosa que puede comprobar es que realmente el usuario sea el propietario de su propio fichero /var/mail. Por supuesto, esto debería ser así (como por ejemplo, el propietario de /var/mail/joe debería ser el usuario joe), pero si no está correctamente configurado podría ser el causante del problema.
Dejar /var/mail con permisos de escritura para el grupo mail abre algunos problemas de seguridad. Es probable que nunca tenga problemas con eso. ¡Pero podría tenerlos! (especialmente si su sitio es de alto rendimiento, como un ISP, ...) Pruebe a invocar 'cucipop' u otro dæmon de la colección de portes de OpenBSD. O podría ser que tuviera seleccionadas las opciones erróneas para su dæmon pop (como "dot locking"). O también es posible que necesitara cambiar el directorio que bloquea (aunque entonces, el bloqueo sólo sería de valor para el dæmon POP).
PD: Note que OpenBSD no tiene un grupo con el nombre "mail". Debe crearlo en su fichero /etc/group con una entrada como ésta:
mail:*:6:
Desde la versión 2.8, OpenBSD incluye httpd y RSA preparados para las bibliotecas SSL. Sin embargo, si está usando OpenBSD 2.6 ó 2.7, debe instalar Vd mismo los paquetes de SSL para que usen SSL. Para más información, man 8 ssl.
Para usarlas con httpd(8) primero debe haber generado un certificado, que se guardará en /etc/ssl/private/. Los pasos que aquí se muestran están tomados, en parte, de la página de manual de ssl(8). Para más información, lea esta página. En estas Preguntas Frecuentes tan sólo se resalta cómo generar un certificado RSA para servidores de web, no un certificado DSA para servidores. Para saber cómo hacerlo, por favor lea la página de manual ssl(8).
Para empezar, necesita generar su clave de servidor y su certificado. Para usar las características de RSA, tiene que haber actualizado antes libssl. Ahora ya puede generar su clave usando OpenSSL:
# openssl genrsa -out /etc/ssl/private/server.key 1024
O si desea puede cifrar la clave con una contraseña que tendrá que introducir cuando inicie los servidores:
# openssl genrsa -des3 -out /etc/ssl/private/server.key 1024
El próximo paso es generar un "Certificate Signing Request" (Requerimiento para Firmar el Certificado), que se usa para que una Autoridad Certificadora (CA) firme su certificado. Para ello use la orden:
# openssl req -new -key /etc/ssl/private/server.key -out /etc/ssl/private/server.csr
Este fichero server.csr se puede entregar a la Autoridad Certificadora que firmará la clave. Una de estas CAs es Thawte Certification, y la puede localizar en http://www.thawte.com/. Actualmente Thawte puede firmar sus claves RSA. Está en marcha un procedimiento para poder firmar las claves DSA.
Si no se lo puede permitir, o si quiere firmar Vd. mismo el certificado, puede usar lo siguiente:
# openssl x509 -req -days 365 -in /etc/ssl/private/server.csr \
-signkey /etc/ssl/private/server.key -out /etc/ssl/server.crt
Con /etc/ssl/server.crt y /etc/ssl/private/server.key en su sitio, ya puede iniciar httpd(8) con el indicador -DSSL, permitiendo transacciones https con su máquina por el puerto 443.
Si edita /etc/passwd, cualquier cambio que haga se perderá. OpenBSD genera el fichero /etc/passwd de forma dinámica con pwd_mkdb(8). El fichero principal de las contraseñas en OpenBSD es /etc/master.passwd. Según la página de manual de pwd_mkdb(8),
FILES
/etc/master.passwd fichero de contraseña actual
/etc/passwd fichero de contraseñ en formato Version 7
/etc/pwd.db fichero de base de datos de la contraseña
no seguro
/etc/pwd.db.tmp fichero temporal
/etc/spwd.db fichero de base de datos de la contraseña
seguro
/etc/spwd.db.tmp fichero temporal
En un fichero de contraseñas tradicional de Unix, como /etc/passwd, toda la información, incluida la contraseña cifrada del usuario, está disponible para cualquiera que pueda acceder al sistema (y es el primer objetivo para programas como Crack). 4.4BSD introdujo el fichero master.passwd, que tiene un formato extendido (con opciones adicionales que van más allá de las ofrecidas por /etc/passwd), y sólo puede ser leido por root. Para un acceso más rápido a los datos, las llamadas de las bibliotecas que acceden a estos datos leen los ficheros /etc/pwd.db y /etc/spwd.db.
OpenBSD viene con una herramienta para la edición de su fichero de contraseña, vipw(8). Vipw usa vi(1) (nuestro editor favorito, definido por $EDITOR) para editar el fichero /etc/master.passwd. Una vez haya terminado de editar, vuelve a crear los ficheros /etc/passwd, /etc/pwd.db, y /etc/spwd.db conforme con los cambios que haya llevado a cabo. Vipw también se encarga de bloquear estos ficheros, de modo que si alguna otra persona intentara cambiarlos al mismo tiempo, no le permitiría el acceso.
En OpenBSD 2.6, los usuarios diponen de la orden adduser(8) para añadir usuarios. A partir de OpenBSD 2.7, se ha añadido la orden user(8) para añadir y eliminar tanto usuarios como grupos.
En OpenBSD, la mejor manera para añadir un usuario es usando el guión adduser(8). Puede configurarlo para que funcione como mejor le convenga, editando /etc/adduser.conf. Puede añadir usuarios de forma manual, mediante vipw(8), pero adduser(8) es el modo en que se recomienda hacerlo. La orden adduser(8) permite llevar a cabo comprobaciones de consistencia sobre los ficheros /etc/passwd y /etc/group, y sobre las bases de datos del intérprete (shell). También generará por Vd. las entradas correspondientes y directorios $HOME. Incluso puede enviar un mensaje de bienvenida al usuario. Todo esto se puede modificar según se desee. Puede leer más información sobre cómo añadir usuarios en la página de manual adduser_proc(8).
Aquí tiene un ejemplo de cómo un usuario ficticio, testuser es añadido a un sistema. Su directorio $HOME se ubicará en /home/testuser, se le añadirá al grupo guest, y se le dará la shell /bin/ksh.
# adduser Use option ``-silent'' if you don't want to see all warnings and questions. Reading /etc/shells Check /etc/master.passwd Check /etc/group Ok, let's go. Don't worry about mistakes. I will give you the chance later to correct any input. Enter username [a-z0-9_]: testuser Enter full name []: Nombre Completo del Usuario Enter shell csh ksh nologin sh [ksh]: ksh Uid [1002]: <Intro> Login group testuser [testuser]: guest Login group is ``guest''. Invite testuser into other groups: guest no [no]: no Enter password []:introduzca una contraseñaEnter password again []:introduzca la contraseña otra vezName: testuser Password: **** Fullname: Nombre Completo del Usuario Uid: 1002 Gid: 31 (guest) Groups: guest HOME: /home/testuser Shell: /bin/ksh OK? (y/n) [y]: y Added user ``testuser'' Copy files from /usr/share/skel to /home/testuser Add another user? (y/n) [y]: n Goodbye!
Para eliminar usuarios debe usar la utilidad rmuser(8). Esto eliminará todo vestigio de un usuario. Eliminará cualquier entrada en crontab(1) relacionada con el usuario, su directorio $HOME (siempre que el propietario de éste sea el usuario en cuestión), y su correo. También eliminará sus entradas en los ficheros /etc/passwd y /etc/group.
A continuación sigue un ejemplo sobre cómo eliminar el usuario que se ha añadido en el ejemplo anterior. Verá que le pedirá el nombre, y si debe o no eliminar el directorio raíz ($HOME) del usuario.
# rmuser Enter login name for user to remove: testuser Matching password entry:introduzca la contraseñatestuser:$2a$07$ZWnBOsbqMJ.ducQBfsTKUe3PL97Ve1AHWJ0A4uLamniLNXLeYrEie:1002:31::0:0:Test FAQ User:/home/testuser:/bin/ksh Is this the entry you wish to remove? y Remove user's home directory (/home/testuser)? y Updating password file, updating databases, done. Updating group file: done. Removing user's home directory (/home/testuser): done.
A partir de la versión 2.7 de OpenBSD, se han añadido muchas órdenes para gestionar usuarios y grupos. Estas herramientas son menos interactivas que la orden adduser(8), que ayuda a facilitar el uso de éstas en un guión (script).
Dado que user(8) no es interactivo, la forma más fácil para añadir usuarios de modo eficiente es usar la orden adduser(8). La orden /usr/sbin/user es simplemente una interfaz para el resto de órdenes /usr/sbin/user*. Por lo tanto, las siguientes órdenes pueden ser adheridas usando user add o useradd; cómo lo vaya a hacer es su elección, y no altera en absoluto la función de la orden.
En este ejemplo, estamos añadiendo el mismo usuario con las mismas especificaciones que usamos para el nuevo usuario de los ejemplos anteriores. La orden useradd(8) es más fácil de usar si conoce la configuración predefinida antes de crear el usuario. Estas configuraciones se encuentran en el fichero /etc/usermgmt.conf, y se pueden ver del siguiente modo:
$ user add -D group users base_dir /home skel_dir /etc/skel shell /bin/csh inactive 0 expire Null (unset) range 1000..60000
Las configuraciones de arriba son las que se activarán a menos que especifique otra cosa con opciones en la línea de órdenes. Por ejemplo, en nuestro caso, queremos que el usuario pertenezca al grupo guest, no al grupo users. Un pequeño obstáculo más al crear usuarios, es que las contraseñas se deben especificar desde la línea de órdenes. Las contraseñas son cifradas, así que tendrá que usar la utilidad encrypt(1) para crearla. OpenBSD, por definición usa 6 veces el algoritmo Blowfish para crear la contraseña.
He aquí una línea de ejemplo para crear una contraseña que espicificar a useradd(8).
$ encrypt -p -b 6 Enter string: $2a$06$YOdOZM3.4m6MObBXjeZtBOWArqC2.uRJZXUkOghbieIvSWXVJRzlq
Ahora que ya tenemos nuestra contraseña cifrada, estamos preparados para añadirla al usuario:
# user add -p '$2a$06$YOdOZM3.4m6MObBXjeZtBOWArqC2.uRJZXUkOghbieIvSWXVJRzlq' -u 1002 \ -s /bin/ksh -c "Test FAQ User" -m -g guest testuser
Nota: Asegúrese de usar comillas simples (') a ambos lados de la cadena de la contraseña, y no comillas dobles (") ya que éstas serían interpretadas por la shell antes de enviar la cadena a user(8). Además de eso, asegúrese de especificar la opción -m si quiere que el directorio raíz del usuario sea creado y que los ficheros de /etc/skel se copien en él.
Para verificar que se ha creado el usuario correctamente, podemos usar muchas utilidades diferentes. A continuación hay unas cuantas órdenes que puede usar para verificar rápidamente que se ha creado todo correctamente.
$ ls -la /home total 14 drwxr-xr-x 5 root wheel 512 May 12 14:29 . drwxr-xr-x 15 root wheel 512 Apr 25 20:52 .. drwxr-xr-x 24 ericj wheel 2560 May 12 13:38 ericj drwxr-xr-x 2 testuser guest 512 May 12 14:28 testuser $ id testuser uid=1002(testuser) gid=31(guest) groups=31(guest) $ finger testuser Login: testuser Name: Nombre Completo del Usuario Directory: /home/testuser Shell: /bin/ksh Last login Sat Apr 22 16:05 (EDT) on ttyC2 No Mail. No Plan.
Aparte de estas órdenes, user(8) provee su propia utilidad para mostrar las características del usuario, llamada userinfo(8).
$ userinfo testuser login testuser passwd * uid 1002 groups guest change Wed Dec 31 19:00:00 1969 class gecos Test FAQ User dir /home/testuser shell /bin/ksh expire Wed Dec 31 19:00:00 1969
Para eliminar usuarios con la jerarquía de órdenes user(8), deber usar userdel(8). Ésta es una orden muy simple, pero muy útil. Para eliminar el usuario creado en el ejemplo anterior, simplemente ejecute:
# userdel -r testuser
Note que la opción -r, que debe ser especificada si quiere que el directorio raíz del usuario sea también eliminado. De forma alternativa, puede especificar -p y no -r y esto bloqueará la cuenta del usuario, pero no eliminará ninguna información.
Existen varios modos de hacerlo, pero una manera muy común es añadir /usr/bin/false en el fichero /etc/shells. Así, cuando cree el usuario, configure su «intérprete de órdenes» ("shell") como /usr/bin/false y de este modo no podrá ingresar de forma interactiva, pero podrá usar ftp. adduser(8) les dará un directorio $HOME que será, por definición, /home/<usuario>. Si le parece bien de esta forma, no necesita cambiarlo; sin embargo, puede configurarlo a cualquier otro directorio que Vd. desee. Puede forzar que el usuario sólo pueda ver los ficheros en su directorio $HOME, añadiendo su nombre de usuario al fichero /etc/ftpchroot. Mediante el uso de la opción -A para ftpd(8), puede restringir los ingresos (login) para que sólo sean posibles por ftpchroot.
Las cuotas se usan para limitar el espacio del que disponen los usuarios en sus discos. Puede ser muy útil en situaciones en las que Vd. disponga de recursos limitados. Las cuotas se pueden configurar de dos maneras diferentes:
El primer paso para configurar cuotas es asegurarse de que la
opción QUOTA se encuentra activada en la
configuración del núcleo de su sistema. Esta
opción está configurada en el núcleo GENERIC.
Después necesita marcar los sistemas de archivo para los que
vaya a configurar las cuotas en /etc/fstab. Debe usar las
palabras clave userquota y groupquota para
marcar cada sistema de archivo en el que usará las cuotas. Por
definición, los ficheros quota.user y
quota.group se crearán en la raíz de ese
sistema de archivo que tendrá la información sobre las
cuotas. Esto se puede anular con la siguiente orden:
userquota=/var/quotas/quota.user ... o cualquier otro
fichero en el que quiera almacenar la información sobre cuotas.
He aquí un ejemplo de /etc/fstab con un sistema de
archivo con cuotas de usuario activadas:
/dev/wd0a / ffs rw,userquota=/var/quotas/quota.user 1 1
Ahora ya puede configurar las cuotas de usuario. Para ello use la utilidad edquota(8). Una forma simple de usarlo es edquota <usuario>. La orden edquota(8) usar´ vi(1) para editar las cuotas a menos que la variable de entorno EDITOR indique un editor diferente. Por ejemplo:
Esto dará un resultado parecido al siguiente:
Quotas for user ericj: /: blocks in use: 62, limits (soft = 0, hard = 0) inodes in use: 25, limits (soft = 0, hard = 0)
Para añadir límites, debe quedar algo como esto:
Quotas for user ericj: /: blocks in use: 62, limits (soft = 1000, hard = 1050) inodes in use: 25, limits (soft = 0, hard = 0)
Aquí el límite "soft" es de 1.000 bloques, y el límite "hard" de 1.050 bloques. El límite "soft" es en el que el usuario sólo recibe un aviso cuando lo sobrepasa, y tiene hasta su periodo de gracia para rebajar su uso del disco por debajo de su límite. Los periodos de gracia se pueden configurar usando la opción -t con la orden edquota(8). Después de que el periodo de gracia haya pasado, el límite "soft" se toma como límite "hard". El resultado es un fallo de ubicación ("allocation failure").
Una vez que las cuotas ya están configuradas, tiene que activarlas. Para ello use quotaon(8). Por ejemplo:
# quotaon -a
De este modo repasará /etc/fstab para activar los sistemas de archivo con opciones de cuota. En cuanto las cuotas estén funcionando, puede verlas con quota(1). Si usa la orden quota <usuario> obtendrá la información sobre el usuario que especifique. Al ser invocada sin argumentos, la orden quota(8) le dará sus estadísticas de cuotas. Por ejemplo:
# quota ericj
Dará como resultado algo como esto:
Disk quotas for user ericj (uid 1001):
Filesystem blocks quota limit grace files quota limit grace
/ 62 1000 1050 27 0 0
Las cuotas que estén configuradas en /etc/fstab iniciarén durante el arranque por definición. Para desactivarlo use:
# quotaoff -a
Como usuario o administrador de sistemas OpenBSD, tiene suerte de que KerberosIV sea un componente preinstalado del sistema. Ésta es una guía para configurar el servidor Kerberos así como el cliente.
Un punto *IMPORTANTÍSIMO* a recordar es que los clientes y servidores Kerberos deben tener sincronizados sus relojes del sistemas. Si existe un lapsus de más de 5 minutos, recibirá errores extraños que no le revelarán que han sido causados por un lapsus de tiempo, como:
kinit: Can't send request (send_to_kdc)Otro error más exacto es:
kauth: Time is out of bounds (krb_rd_req)
Una forma fácil para sincronizar los relojes del sistema es con xntpd, disponible desde el árbol de portes en /usr/ports/sysutils/xntpd/.
Este documento asume que tiene unos conocimientos anterior de los conceptos detrás de Kerberos. Para una buena referencia, simple de entender, lea:Configuraremos el campo de acción de CIARASYSTEMS.COM con avalanche.ciarasystems.com como servidor principal.
Para empezar, tendremos que editar nuestros ficheros de configuración. Estos ficheros están ubicados en /etc/kerberosIV/. Los dos ficheros que nos interesan son krb.realms y krb.conf. Empecemos con krb.conf.
[root@avalanche kerberosIV] cat krb.conf CIARASYSTEMS.COM CIARASYSTEMS.COM avalanche.ciarasystems.com admin server
Como puede ver, esto indica a kerberos que el dominio es CIARASYSTEMS.COM (o campo de acción lógico) y que dentro de ese dominio, avalanche es el servidor de administración. A continuación veremos krb.realms. Para más información lea la página de manual de krb.conf.
[root@avalanche kerberosIV] cat krb.realms avalanche.ciarasystems.com CIARASYSTEMS.COM .ciarasystems.com CIARASYSTEMS.COM
krb.realms provee una traducción del nombre del huésped al nombre del campo de acción de Kerberos para los servicios provistos por ese huésped. Cada línea del fichero de traducción es de una de las siguientes formas (el nombre del dominio debería ser del tipo .XXX.YYY). Así, en este ejemplo, avalanche es el nombre de huésped de una máquina en el campo de acción CIARASYSTEMS.COM, y .ciarasystems.com es el nombre del dominio en el campo de acción CIARASYSTEMS.COM. Para más información lea la página de manual de krb.realms.
A continuación ejecutaremos kdb_init(8) para crear una base de datos inicial de Kerberos.
[root@avalanche kerberosIV] kdb_init Realm name [default NO.DEFAULT.REALM ]: CIARASYSTEMS.COM You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter Kerberos master password: not shown Verifying password - Enter Kerberos master password:
Lo siguiente que tendremos que usar es kstash(8), que se utiliza para guardar clave maestra de la base de datos, del centro de distribución de claves (KDC), en el fichero de caché de la clave maestra.
[root@avalanche kerberosIV] kstash Enter Kerberos master password: Current Kerberos master key version is 1. Master key entered. BEWARE! Wrote master key to /etc/kerberosIV/master_keyDe este modo se guarda la contraseña maestra cifrada en /etc/kerberosIV/master_key.
A continuación necesitaremos añadir a la base de datos dos entradas "principal" por cada uno de los sistemas que será asegurado con Kerberos. Sus nombres son kpasswd y rcmd. Estas dos entradas "principal" se harán para cada sistema, siendo la entrada "instance" el nombre de cada sistema. Estos dæmons, kpasswd y rcmd, permiten que otros sistemas cambien las contraseñas de Kerberos y ejecuten órdenes como rcp, rlogin y rsh.
# kdb_edit
Opening database...
Enter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.
Principal name: passwd
Instance: avalanche
<Not found>, Create [y] ? y
Principal: passwd, Instance: avalanche, kdc_key_ver: 1
New Password: <----- Use 'RANDOM' como contraseña
Verifying password -
New Password:
Random password [y] ? y
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 1999-12-31 ] ? 2001-12-31
Max ticket lifetime (*5 minutes) [ 255 ] ?
Attributes [ 0 ] ?
Edit O.K.
Principal name: rcmd
Instance: avalanche
<Not found>, Create [y] ? y
Principal: rcmd, Instance: avalanche, kdc_key_ver: 1
New Password: <----- Use 'RANDOM' como contraseña
Verifying password -
New Password:
Random password [y] ? y
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 1999-12-31 ] ? 2001-12-31
Max ticket lifetime (*5 minutes) [ 255 ] ?
Attributes [ 0 ] ?
Edit O.K.
Principal name: <----- Pulse <INTRO> para acabar
Un fichero srvtab es un fichero de la clave de servicio. Estas claves deben extraerse de la base de datos del centro de distribución de claves de Kerberos para que los servicions autentiquen usando Kerberos. Por cada uno de los nombres de huésped ("hostname") especificados en la línea de órdenes, ext_srvtab(8) genera el fichero de la clave de servicio hostname-new-srvtab, que contiene todas las entradas en la base de datos con un campo "instance" del nombre del huésped.
[root@avalanche kerberosIV] ext_srvtab avalanche Enter Kerberos master password: Current Kerberos master key version is 1. Master key entered. BEWARE! Generating 'avalanche-new-srvtab'.... [root@avalanche kerberosIV] mv avalanche-new-srvtab srvtab [root@avalanche kerberosIV] chmod 600 srvtab
Ahora podemos añadir usuarios a nuestra base de datos.
[root@avalanche kerberosIV] kdb_edit
Opening database...
Enter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.
Principal name: jeremie
Instance:
<Not found>, Create [y] ? y
Principal: jeremie, Instance: , kdc_key_ver: 1
New Password: <---- introduzca una contraseña segura aquí
Verifying password
New Password: <---- vuelva a introducir la contraseña
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
Max ticket lifetime (*5 minutes) [ 255 ] ?
Attributes [ 0 ] ?
Edit O.K.
Principal name: <---- una entrada vacía aquí causará que abandone
Ahora ya están configurados todos los "particular". Todo lo que queda por hacer es activar la carga del servidor Kerberos durante el arranque y activar los dæmons «kerberizados».
Escriba en /etc/rc.conf:
telnet stream tcp nowait root /usr/libexec/telnetd telnetd -k klogin stream tcp nowait root /usr/libexec/rlogind rlogind -k kshell stream tcp nowait root /usr/libexec/rshd rshd -k kauth stream tcp nowait root /usr/libexec/kauthd kauthdY reinicie o:
[root@avalanche /] kill -HUP `cat /var/run/inetd.pid` [root@avalanche /] /usr/libexec/kerberos >> /var/log/kerberos.log & [root@avalanche /] /usr/libexec/kadmind -n >> /var/log/kadmind.log &
Nota: ésta es una configuración del servidor bastante simple. Generalmente se configuran servidores redundantes (y servidores esclavos) para que si un servidor cayera, todos los servicios que dependen de Kerberos se mantuvieran. También podemos añadir privilegios de 'su' a un "principal" específico; vea el FreeBSD Handbook para más información.
Configuraremos la estación de trabajo llamada gatekeeper para que esté en el campo de acción de CIARASYSTEMS.COM, con avalanche.ciarasystems.com como el servidor principal.
Para empezar, necesitamos configurar los ficheros krb.conf y krb.realms como para la máquina anterior. Esto es para que gatekeeper sepa qué servidor es el KDC y en qué dominio se encuentra. He aquí el contenido de los ficheros:
[root@gatekeeper kerberosIV] cat krb.conf CIARASYSTEMS.COM CIARASYSTEMS.COM avalanche.ciarasystems.com admin server [root@gatekeeper kerberosIV] cat krb.realms avalanche.ciarasystems.com CIARASYSTEMS.COM .ciarasystems.com CIARASYSTEMS.COM
Eso ha sido la configuración, ahora necesitamos iniciar kerberos. Para obtener un ticket usaremos kinit(1).
xyz:jeremie% kinit The OpenBSD Project (gatekeeper) Kerberos Initialization Kerberos name: jeremie Password:
Ahora que nos hemos identificado, podemos ver una lista de nuestros tickets con klist(1).
xyz:jeremie$ klist Ticket file: /tmp/tkt1000 Principal: jeremie@CIARASYSTEMS.COM Issued Expires Principal Jun 28 01:03:25 Jun 28 11:03:25 krbtgt.CIARASYSTEMS.COM@CIARASYSTEMS.COM
Parece que ya está todo. Lo único que queda por hacer es probarlo. En los siguientes ejemplos lo probaremos con rlogin(1) y telnet(1).
xyz:jeremie% telnet avalanche Trying 192.168.0.38... Connected to avalanche. Escape character is '^]'. [ Trying mutual KERBEROS4 ... ] [ Kerberos V4 accepts you ] [ Kerberos V4 challenge successful ] Last login: Sun Jun 27 22:52:25 on ttyp1 from gatekeeper Warning: no Kerberos tickets issued. OpenBSD 2.5 (AVALANCHE) #5: Tue Apr 6 01:18:16 EDT 1999y
xyz:jeremie% rlogin avalanche Last login: Sun Jun 27 22:53:39 on ttyp1 from gatekeeper Warning: no Kerberos tickets issued. OpenBSD 2.5 (AVALANCHE) #5: Tue Apr 6 01:18:16 EDT 1999
Se ve claro que está usando Kerberos para autenticar la sesión de rlogin. Para eliminar los tickets de la sesión usaremos kdestroy(1). Por ejemplo:
xyz:jeremie% kdestroy Tickets destroyed. xyz:jeremie% rlogin avalanche krcmd: No ticket file (tf_util) rlogin: warning, using standard rlogin: can't provide Kerberos auth data. avalanche: Connection refused
No se preocupe por el mensaje 'Warning: no Kerberos tickets issued'. Esto es debido a que sólo estamos haciendo autenticación con kerberos, no pases de tickets. Si quiere pases de tickets, use OpenSSH que tiene soporte para ello. KerberosIV de serie tampoco tiene soporte para pases tgt, sólo la implementación de krb4 de kaserver AFS, ya que KerberosIV normal comprueba con kdc las direcciones IP de los clientes en la lista del ticket.
FTP Anónimo permite a los usuarios que carecen de cuentas en el sistema, acceder a ficheros en su máquina mediante el «Protocolo de Transferencia de Ficheros» (FTP, "File Transfer Protocol"). Esta sección ofrece un resumen sobre cómo configurar el servidor de ftp anónimo, su ingreso, etc...
Para empezar, necesita tener una cuenta "ftp" en su sistema. Esta cuenta no debe tener una contraseña utilizable. Aquí configuraremos el directorio de ingreso como /home/ftp, pero puede ponerlos donde quiera. Cuando use ftp anónimo, el dæmon de ftp ejecutará chroot sobre sí mismo para cambiar la directorio del usuario de ftp. Puede leer más sobre esto en las páginas de manual de ftp(8) y chroot(2). He aquí un ejemplo sobre cómo añadir el usuario ftp. Para ello usaremos adduser(8). También necesitamos añadir /usr/bin/false a nuestro fichero /etc/shells, que será la shell que configuraremos para el usuario ftp. Así no tendrán permiso para ingresar, aunque les daremos una contraseña vacía. Para ello puede hacer simplemente lo siguiente:
echo /usr/bin/false >> /etc/shellsTambién, si quiere que esa shell se muestre durante las preguntas de la orden adduser, necesita modificar /etc/adduser.conf.
oshibana# adduser Use option ``-silent'' if you don't want see all warnings & questions. Reading /etc/shells Check /etc/master.passwd Check /etc/group Ok, let's go. Don't worry about mistakes. I will give you the chance later to correct any input. Enter username [a-z0-9_]: ftp Enter full name []: anonymous ftp Enter shell csh false ksh nologin sh tcsh zsh [sh]: false Uid [1002]: Login group ftp [ftp]: Login group is ``ftp''. Invite ftp into other groups: guest no [no]: no Enter password []: Use an empty password? (y/n) [y]: y Name: ftp Password: **** Fullname: anonymous ftp Uid: 1002 Gid: 1002 (ftp) Groups: ftp HOME: /home/ftp Shell: /usr/bin/false OK? (y/n) [y]: y Added user ``ftp'' Copy files from /usr/share/skel to /home/ftp Add another user? (y/n) [y]: n Goodbye!
Además del usuario, ha creado el directorio /home/ftp. Es lo que queremos, pero hay algunos cambios que tendremos que hacer para tenerlo preparado para ftp anónimo. Estos cambios se explican en la página de manual de ftp(8).
Note que el propietario de todos estos directorios debería ser ``root''. He aquí una lista de cómo deberían ser los directorios después de ser creados:
oshibana# pwd /home oshibana# ls -laR ftp total 5 dr-xr-xr-x 5 root ftp 512 Jul 6 11:33 . drwxr-xr-x 7 root wheel 512 Jul 6 10:58 .. dr-x--x--x 2 root ftp 512 Jul 6 11:34 etc dr-xr-xr-x 2 root ftp 512 Jul 6 11:33 pub ftp/etc: total 43 dr-x--x--x 2 root ftp 512 Jul 6 11:34 . dr-xr-xr-x 5 root ftp 512 Jul 6 11:33 .. -r--r--r-- 1 root ftp 316 Jul 6 11:34 group -r--r--r-- 1 root ftp 40960 Jul 6 11:34 pwd.db ftp/pub: total 2 dr-xr-xr-x 2 root ftp 512 Jul 6 11:33 . dr-xr-xr-x 5 root ftp 512 Jul 6 11:33 ..
Con ftpd(8) puede escoger entre invocarlo desde inetd(8) o lo pueden iniciar los guiones de configuración de rc(8). En estos ejemplos se verá cómo se inicia nuestro dæmon desde inetd.conf. Primero debemos familiarizarnos con algunas de las opciones de ftpd. La línea por definición de /etc/inetd.conf es:
ftp stream tcp nowait root /usr/libexec/ftpd ftpd -US
En este caso ftpd se invoca con -US. Así se grabarán las conexiones anónimas a /var/log/ftpd, y las sesiones concurrentes a /var/run/utmp. De este modo, podremos ver estas sesiones con la orden who(1). Es posible que algunos sólo quisieran tener un servidor anónimo, y desactivar ftp para usuarios. Para ello debe invocar ftpd con la opción -A. He aquí una línea que inicia ftpd para conexiones anónimas sólo. También usa -ll para grabar cada conexión a syslog, junto con las órdenes de ftp 'get', 'retrieve', etc.
ftp stream tcp nowait root /usr/libexec/tcpd ftpd -llUSA
Nota: Para aquéllos que usen servidores de ftp de MUCHO tráfico, es conveniente que no invoquen ftpd desde inetd.conf. La mejor opción es comentar la línea de ftpd de inetd.conf e iniciar ftpd desde rc.conf junto con la opción -D. De este modo iniciarán ftpd como un dæmon, y será más simple que iniciarlo desde inetd. A continuación viene un ejemplo de cómo iniciarlo desde rc.conf:
ftpd_flags="-DllUSA" # for non-inetd use: ftpd_flags="-D"
Esto sólo funcionará si ha desactivado ftpd en /etc/inetd.conf.
En OpenBSD, ftpd(8) está configurado por definición para poder gestionar esto de modo muy fácil. Se hace por medio del fichero /etc/ftpchroot. Como los usuarios no son siempre fiables, puede ser necesario restringir su entrada en otros directorios que no sean el propio. Esto NO está activado por definición. He aquí un ejemplo de cómo responde por definición:
$ ftp localhost Connected to localhost. 220 oshibana FTP server (Version 6.4/OpenBSD) ready. Name (localhost:ericj): ericj 331 Password required for ericj. Password: ********* 230- OpenBSD 2.6 (GENERIC) #690: Fri Oct 29 16:32:17 MDT 1999 230- 230- Welcome to OpenBSD: The proactively secure Unix-like operating system. 230- 230- Please use the sendbug(1) utility to report bugs in the system. 230- Before reporting a bug, please try to reproduce it with the latest 230- version of the code. With bug reports, please try to ensure that 230- enough information to reproduce the problem is enclosed, and if a 230- known fix for it exists, include that as well. 230- 230 User ericj logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> cd / 250 CWD command successful. ftp> ls 227 Entering Passive Mode (127,0,0,1,60,7) 150 Opening ASCII mode data connection for 'file list'. altroot bin dev etc home mnt root sbin stand tmp usr var bsd sys boot 226 Transfer complete. ftp> quit 221 Goodbye.
Como puede ver, el acceso está permitido para todo el servidor. En un mundo perfecto esto debería ser así, deberíamos poder fiarnos de todos los usuarios, pero no es así. Para limitar un usuario, añada su nombre al fichero /etc/ftpchroot. He aquí un ejemplo que muestra cómo restringir al usuario "ericj":
$ cat /etc/ftpchroot # $OpenBSD: faq10.html,v 1.10 2000/12/28 22:00:23 jufi Exp $ # # list of users (one per line) given ftp access to a chrooted area. # read by ftpd(8). ericj
Esto es suficiente para evitar que el usuario "ericj" se escape de su propio directorio. Como puede ver en el siguiente ejemplo, el directorio / ha cambiado de repente a su directorio de usuario.
$ ftp localhost Connected to localhost. 220 oshibana FTP server (Version 6.4/OpenBSD) ready. Name (localhost:ericj): ericj 331 Password required for ericj. Password: ********* 230 User ericj logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> cd / 250 CWD command successful. ftp> ls 227 Entering Passive Mode (127,0,0,1,92,171) 150 Opening ASCII mode data connection for 'file list'. .login .mailrc .profile .rhosts .ssh .cshrc work mail src 226 Transfer complete. ftp> quit 221 Goodbye.
El árbol de fuentes de OpenBSD experimenta cambios y mejoras continuamente, y al mismo tiempo se ponen a disponibilidad pública parches para problemas comunes con bastante frecuencia. Estos parches aparecen en la página web de erratas, que puede encontrar en http://www.openbsd.org/es/errata.html, y se encuentran separados por categorías. Estas categorías corresponden a los parches que se deberían aplicar a las diferentes arquitecturas, o a parches independientes de la arquitectura.
Sin embargo, no se producen parches para las nuevas funcionalidades añadidas al sistema, y sólo se producen para solucionar problemas de fiabilidad o de seguridad que deban ser atajados inmediatamente, aunque la última palabra sobre si se deben aplicar o no la tiene siempre el administrador del sistema.
A modo de ejemplo parchearé talkd(8) con un parche de seguridad obtenido de errata.html.
Todos los parches que se envían a http://www.openbsd.org/es/errata.html son parches que se aplican directamente al árbol de fuentes de la versión oficial más reciente. Los parches que se aplican al árbol de CVS más reciente también incluyen otros cambios que no son deseables en un sistema con la versión oficial.
Los parches para el Sistema Operativo OpenBSD se distribuyen como ficheros diff, que son ficheros de texto en los que se encuentran las diferencias con el código fuente original. NO se distribuyen en formato binario. Esto quiere decir que para aplicar un parche al sistema, antes es necesario disponer del código fuente de la versión RELEASE de OpenBSD. Esto no significa que debe disponer de TODO el código fuente del sistema operativo, sino que debe tener todo el código para el programa al que vaya a aplicar el parche. Por ejemplo, si va a aplicar un parche al núcleo del sistema, debe tener a mano todo el código fuente para el núcleo.
cvs(1) es una herramienta muy útil que puede usar para obtener el código fuente que necesite por medio de los servidores anónimos de cvs ubicados alrededor del mundo. Puede ver un listado de estos servidores en http://www.openbsd.org/es/anoncvs.html.
Para obtener obtener el código fuente de la versión 2.7 usando cvs(1), debe hacer lo siguiente:
$ cvs -danoncvs@anoncvs5.usa.openbsd.org:/cvs co -rOPENBSD_2_7_BASE src/libexec/talkd/ cvs server: Updating src/libexec/talkd U src/libexec/talkd/announce.c U src/libexec/talkd/talkd.c U src/libexec/talkd/talkd.h
Para encontrar en el CVS el camino hasta el código que necesita, puede verlo en la línea Index: del parche. En este caso el camino en el CVS era src/libexec/talkd/. Compruebe siempre el número de revisión de OPENBSD_version_number_BASE. Sin "BASE" obtendrá el código de la rama estable, y ésta puede contener otros cambios que sin duda interferirán. Si ya está siguiendo la rama de parches, los parches ya deberían estar en ese código fuente, pero por si acaso debería comprobarlo y asegurarse. Siempre puede mirar en http://www.openbsd.org/es/plus.html para ver qué parches se han aplicado a la rama de parches. Si los parches todavía no han sido aplicados, tendrá que obtener el código fuente de la última versión usando la orden anterior.
Los usuarios que hayan adquirido los CDs oficiales de OpenBSD pueden obtener el código fuente directamente desde el CD. Mire en la carátula del CD para saber cómo extraer el código fuente desde el mismo. En este caso no será necesaria la obtención del código fuente por medio de anoncvs.
Aplicar del siguiente modo:
cd /usr/src
patch -p0 < 026_talkd.patch
cd libexec/talkd
make obj && make depend && make && make install
Index: libexec/talkd/announce.c <------ Camino a los fuentes
===================================================================
RCS file: /cvs/src/libexec/talkd/announce.c,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- libexec/talkd/announce.c 1998/08/18 03:42:10 1.8
+++ libexec/talkd/announce.c 2000/07/06 00:01:45 1.9
@@ -160,6 +160,6 @@
*(bptr++) = '\n';
}
*bptr = '\0';
- fprintf(tf, big_buf);
+ fprintf(tf, "%s", big_buf);
fflush(tf);
}
Una vez que haya obtenido el código fuente correcto, puede obtener el parche y ponerlo en src/.
$ cd /usr/src $ patch -p0</path/to/026_talkd.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |Aplicar del siguiente modo: | cd /usr/src | patch -p0 < 026_talkd.patch | cd libexec/talkd | make obj && make depend && make && make install | |Index: libexec/talkd/announce.c |=================================================================== |RCS file: /cvs/src/libexec/talkd/announce.c,v |retrieving revision 1.8 |retrieving revision 1.9 |diff -u -r1.8 -r1.9 |--- libexec/talkd/announce.c 1998/08/18 03:42:10 1.8 |+++ libexec/talkd/announce.c 2000/07/06 00:01:45 1.9 -------------------------- Patching file libexec/talkd/announce.c using Plan A... Hunk #1 succeeded at 160. <------------ Parche con éxito done $ cd /usr/src/libexec/talkd/ $ ls CVS announce.c print.c table.c talkd.c Makefile announce.c.orig process.c talkd.8 talkd.h $ make obj && make depend && make making /home/ericj/lsrc/src/libexec/talkd/obj mkdep -a /home/ericj/lsrc/src/libexec/talkd/talkd.c /home/ericj/lsrc/src/libexec/talkd/announce.c /home/ericj/lsrc/src/libexec/talkd/process.c /home/ericj/lsrc/src/libexec/talkd/table.c /home/ericj/lsrc/src/libexec/talkd/print.c cc -O2 -c /home/ericj/lsrc/src/libexec/talkd/talkd.c cc -O2 -c /home/ericj/lsrc/src/libexec/talkd/announce.c cc -O2 -c /home/ericj/lsrc/src/libexec/talkd/process.c cc -O2 -c /home/ericj/lsrc/src/libexec/talkd/table.c cc -O2 -c /home/ericj/lsrc/src/libexec/talkd/print.c cc -o ntalkd talkd.o announce.o process.o table.o print.o nroff -Tascii -mandoc /home/ericj/lsrc/src/libexec/talkd/talkd.8 > talkd.cat8 $ sudo make install install -c -s -o root -g bin -m 555 ntalkd /usr/libexec install -c -o root -g bin -m 444 talkd.cat8 /usr/share/man/cat8/talkd.0 /usr/share/man/cat8/ntalkd.0 -> /usr/share/man/cat8/talkd.0
Una vez hecho esto, reinicie ese servicio.
[Volver al índice principal] [Sección 9.0 - Consejos para usuarios de Linux] [Sección 11.0 - Afinar el rendimiento]