On Thu, May 10, 2007 at 12:03:10AM +0200, Iñaki Baz Castillo wrote: > El Miércoles, 9 de Mayo de 2007, Luis Rodrigo Gallardo Cruz escribió: > > > Y otra: El uso de llaves publicas para el ingreso permite crear > > 'personalidades' limitadas, en las que el acceso sólo permite ejecutar > > un comando en particular. > > ¿Podrías detallar más a qué te refieres?
En tu .ssh/authorized_keys pones algo como: command="/usr/sbin/imapd",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-dss AAAAB3... Entonces, quien entra usando la llave privada correspondiente a esa es forzado a ejecutar /usr/sbin/imapd en vez de un shell de login. En ese ejemplo, además, no se le permite hacer forwarding de puertos, conexiones X, etc. Así limitas a quien tiene esa llave a hacer sólo una (o unas pocas) cosas. Otro ejemplo: Subversion permite el acceso a repositorios vía ssh. Pero a veces no quieres añadir un usuario unix por cada usuario subversion. Lo que haces es que instalas el repositorio bajo un usuario 'svn'. Para cada usuario subversion creas un par de llaves. La pública la añades en ~svn/.ssh/authorized_keys con una entrada parecida a command="/usr/bin/svn -u <usuario-subversion>",otras-opciones, ssh-dss AAA... Al usuario le das la parte privada de la llave y ¡listo! Acceso automático para ese usuario a subversion, registrado siempre bajo su propio nombre, sin crearle una cuenta Unix y sin darle permisos de shell en la máquina. ¡Bonito, ¿no?! -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28
signature.asc
Description: Digital signature
