El servicio ssh es excelente y lo es por las muchas posibilidades que brinda. Una de ellas es la sustitución del viejo y poco seguro servicio FTP. El servicio ssh ofrece un protocolo llamado SFTP que funciona parecido al FTP, pero de forma más segura. Aplicaciones como Filezilla tienen soporte para este protocolo.
Nada más instalar SSH en nuestro servidor Ubuntu, ya queda disponible para usar con nuestros usuarios y un cliente SFTP. Pero un problema que tiene esto es que el cliente SFTP puede navegar por todo el sistema de ficheros exponiendo el contenido del servidor. Esto lógicamente no nos gusta nada.
Pero podemos enjaular (chroot) los usuarios para que no puedan perderse entre los directorios del servidor. Y esto es magnífico, porque podemos así permitirles subir sus archivos a estos usuarios y que queden publicados en Internet.
Veamos como hacerlo.
Creamos un grupo nuevo.
Los usuarios de este grupo tendrán automáticamente restringido el sistema de directorios a su propio directorio enjaulado. No pudiendo salir y perderse más allá de su directorio raíz.
sudo groupadd hostusers
Creamos el usuario.
Este usuario tiene la particularidad que no podrá acceder a un terminal y sólo podrá acceder mediante un cliente sftp a sus directorios enjaulados.
sudo useradd -g hostusers -d /home -s /sbin/nologin testuser sudo passwd testuser
Verificamos que el usuario se creo con:
grep testuser /etc/passwd
Configuramos el servicio sftp enjaulado.
Tenemos que editar el fichero sshd_config donde se configura el servicio del servidor ssh. En este archivo preparamos ssh para funcionar como queramos. Cambiando el sftp-server que viene configurado por defecto por el internal-sftp.
sudo nano /etc/ssh/sshd_config
Comentamos la línea para deshabilitarla:
#Subsystem sftp /usr/lib/openssh/sftp-server
Al final del archivo de configuración añadimos una línea nueva para que use el sftp interno:
Subsystem sftp internal-sftp
Y después añadimos el siguiente texto para instruir al servicio ssh cual será el directorio enjaulado.
Match Group hostusers ChrootDirectory /hosting/%u ForceCommand internal-sftp
La primera línea indica que las siguientes sólo aplican a los usuarios del grupo hostusers. La segunda línea indica que los usuarios estarán enjaulados en un directorio con su propio nombre. Y la tercera indica que se debe forzar para estos usuarios el uso del sftp interno.
Creamos el directorio de la jaula.
sudo mkdir /hosting
Creamos los directorios para el usuario.
sudo mkdir /hosting/testuser sudo mkdir /hosting/testuser/home sudo mkdir /hosting/testuser/home/public_html
Para estos usuarios especiales /hosting/testuser será como / para el usuario testuser. Este usuario no podrá ver nada por encima de su directorio raíz El directorio public_html queda ahí para poder usarlo con Apache y orientar los dominios virtuales a ese directorio. De modo que cuando esté configurado Apache, lo que cada usuario suba ahí se publicará en Internet.
Aplicamos los permisos correctos.
Como estos directorios son creados por root debemos cambiarles el propietario para que el usuario testuser pueda usarlos.
sudo chown testuser:hostusers /hosting/testuser/home sudo chown testuser:hostusers /hosting/testuser/home/public_html
Podremos comprobar que los permisos son correctos con el alias ll (disponible en Ubuntu Server para ls -ld)
ll /hosting/testuser/home
Reiniciar el servicio SSH
Finalmente reiniciamos el servicio ssh para que los cambios aplicados tomen efecto.
sudo service ssh restart
Ahora deberíamos poder acceder con un cliente SFTP como Filezilla.
Más usuarios
Si queremos añadir mas usuarios enjaulados repetiremos para cada nuevo usuario. En cada comando sustituiremos testuser por el nombre del nuevo usuario que queremos crear en cada uno de los pasos siguientes:
- Creamos el usuario.
- Creamos los directorios.
- Aplicamos los permisos correctos
- Reiniciar el servicio SSH.
Con estas instrucciones podemos permitir que usuarios suban sus ficheros al servidor y no puedan comprometer la visibilidad de los contenidos en él. Estas instrucciones están probadas en Ubuntu Server 12.04 LTS.
Eskerrik asko por el tutorial. Tiene muy buena pinta, pero no consigo que funcione.
Si cambio el fichero /etc/ssh/sshd_config y reinicio ssh, ya no puedo entrar ni por ftp ni por ssh. Menos mal que me he dado cuenta antes de cerrar la conexion que tenia, sino me quedo sin acceso al servidor.
Alguna idea de porque puede ser?
Bienvenido NamekplanetaIulen.
No se la razón de que se cierre el acceso ya que tan solo se añade un nuevo comportamiento para los nuevos usuarios del grupo hostusers. Los demás usuarios no deberían verse afectados.
Ciertamente, los nuevos usuarios no podrán acceder ni por FTP ni por SSH. Deberán acceder por SFTP.
Si añado las lineas que comentas en el fichero de configuracion, no me conecto ni por ftp ni por sftp ni por ssh.
Este es mi fichero de configuracion, por si se te ocurre algo.
# Package generated configuration file
# See the sshd_config(5) manpage for details
# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes
# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768
# Logging
SyslogFacility AUTH
LogLevel INFO
# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys
# Don’t read the user’s ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don’t trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes
# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no
# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes
# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
#MaxStartups 10:30:60
#Banner /etc/issue.net
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
#Subsystem sftp internal-sftp
#Match Group hostusers
#ChrootDirectory /hosting/%u
#ForceCommand internal-sftp
# Set this to ‘yes’ to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of “PermitRootLogin without-password”.
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to ‘no’.
UsePAM yes
El config que tienes es como el mio salvo la clave PermitRootLogin que la tengo a no. Cosa que en todo caso te añadirá más problemas ya que no podrás usar root para hacer login en el servidor.
Voy a montar una máquina virtual para hacer pruebas.
Conseguido!!!
No entiendo el porque, pero buscando por internet y a base de pruebas lo he conseguido. Esto es lo que he hecho:
He comentado esta linea:
#Subsystem sftp /usr/lib/openssh/sftp-server
En la linea siguente he hañadido la que poneis arriba:
Subsystem sftp internal-sftp
Pero despues no he añadido nada mas. Solo al final del documento he puesto estas lineas:
Match Group hostusers
ChrootDirectory /hosting/%u
ForceCommand internal-sftp
X11Forwarding no
AllowTcpForwarding no
Hay dos lineas nuevas, que no se para que son, pero asi ya me funciona.
Gracias por todo!
Me alegra que encontraras la solución.
Saludos y gracias por tu visita.
Después de cacharrear con máquinas virtuales he podido encontrar un error que si bien no se si es el mismo que tenias, se manifiesta de la misma forma. Impidiendo la conexión.
Al parecer si insertamos la configuración:
Subsystem sftp internal-sftp
Match Group hostusers
ChrootDirectory /hosting/%u
ForceCommand internal-sftp
donde se encuentra la clave que anulamos:
#Subsystem sftp /usr/lib/openssh/sftp-server
es cuando no funciona.
Sin embargo si lo añadimos al final del fichero de configuración, es decir un poco más abajo, tras la cave UsePAM yes, si que funciona correctamente.
Editaré el texto para evitar esta ambigüedad y agradecerte que señalaras el problema que permite hacer más exacta la guía.
Saludos.
Hola,
Parece que estás dentro del bloque Match cuando interpreta la UsePAM, que es una directiva que no puede meterse dentro del bloque Match.
Saludos
Por cierto, a mi me contesta el sftp, pero en cambio cuando intenta entrar ocurre que:
Write failed: Broken pipe
Couldn’t read packet: Connection reset by peer
¿Alguna idea de por qué puede estar pasando? Gracias.
Revisa si tienes la clave:
TCPKeepAlive yes
Aupa,
me ha servido perfectamente. Lo único, ha habido una cosa que me ha comido mucha la cabeza hasta que he dado con ello, la carpeta /hosting/%u tiene que pertenecer a root, porque si no da error al conectar. (lo leí aquí: http://askubuntu.com/questions/134425/how-can-i-chroot-sftp-only-ssh-users-into-their-homes)
Kaixo Txurdi,
Agradezco tu aporte. Bienvenido.
Hola, estoy siguiendo el post pero me da problemas en varios puntos, os cuento para ver si me podéis ayudar:
He de comentar la parte de Match Group para que no me falle, si la descomento se queda esperando y no me sale ni la parte del login.
Creo otra parte que se llama Match User y pongo el usuario que quiero que entre, en este caso si que me pide la contraseña pero parece que nunca es la correcta, no se si será tema de permisos en las carpetas o que será.
Muchas gracias!!