Introducción

Estou engadindo un sistema de copias de seguridade na Raspberry. Deste xeito protexerei a miña información en caso de accidente, por erros dos equipos ou erros humanos. O caso é que quero usar a Raspberry como un dos almacéns destas copias, pero por seguridade non quero que os equipos que conecten con ela o fagan co usuario principal. De xeito que quero un usuario que tan só poida acceder ao cartafol onde se almacenen as copias e que non teña nin sudo, nin nada. Este sería o primeiro paso. Por suposto, unha vez creado o usuario e comece coas copias, teño que engadir novos destinos. De nada me vale ter as copias tan só na Raspberry e que o disco se estrague. Por seguridade preciso como mínimo doutro sitio onde ter as copias. E idealmente un tercer sitio xa fora do lugar físico onde estean as primeiras copias.
Digamos que temos as nosas cousas nunha tenda, ou empresa, e en ningún sitio máis. Se acontecese algo, como que se nos estrague un servidor, poderíamos recuperar a copia dende o disco da Raspberry. Pero no caso de que ocorrese algo máis grave, coma un incendio, non só perderíamos os datos do servidor, senón tamén as copias. Isto que de entrada parece pouco probable, pode acontecer. Se ben é certo que a priori en caso de incendio os datos non serán o que máis nos preocupen, si que poden supor a diferenza entre ser capaces de retomar unha actividade ou non.
Por isto sempre é recomendable ter máis dunha copia e polo menos unha noutra localización.

Crear un usuario restrinxido en GNU/Linux

Ter copias de seguridade é un paso de cara a mellorar a nosa seguridade. Neste caso tendo copias para recuperar a información en caso de perda. Pero non por isto podemos descoidar outras casuísticas. Por exemplo, para almacenar a información na Raspberry, o cliente conectarase por ssh. Se permitimos que se faga co usuario principal, non só vai poder gardar as copias, senón que poderá facer de todo. Por este motivo é recomendable, ter distintos usuarios, con distintos permisos na nosa máquina.

Neste caso quero crear un usuario que permita conectar por ssh, pero que non teña permisos administrativos e que tan só poida acceder aos cartafoles nos que se gardarán as copias.

Creando o usuario

Para crear o usuario precisaremos permisos de administración. Para isto podemos usar sudo ou o propio root. Persoalmente prefiro sudo.

sudo useradd -m -s /bin/bash nome_usuario
sudo passwd nome_usuario
sudo chmod 700 /home/nome_usuario

En secuencia o que estamos a facer é o seguinte:

  1. Creamos o usuario. O modificador -m indica que queremos que se cree o directorio home do usuario, neste caso será /home/nome_usuario. A continuación co modificador -s indica que o shell do usuario será bash.
  2. Establecemos o contrasinal do usuario. Despois da orde, pediranos o novo contrasinal.
  3. Modificamos os permisos do directorio home do usuario. Có 7, dicimos que terá todos os permisos. Mentres que os dous 0, din que usuarios do mesmo grupo, ou outros usuarios, non terán ningún tipo de permiso.

Alpine

No caso de Alpine Linux o comando cambia. No meu caso non teño usuarios con acceso administrativo. Para este tipo de tarefas uso root directamente. Polo que a orde non levará sudo.

adduser [-g "nome completo"] usuario

Ao correr este comando en Alpine, o que fará será preguntarnos pola contrasinal do usuario. Asignaralle a sua home e a mesma shell ca o root. Por defecto en Alpine é ash, unha terminal abreviada semellante a bash. senón usamos a opción -g, tamén nos preguntará o nome completo do usuario. É posible asignar permisos administrativos ao usuario, tal como pon na wiki de Alpine, pero non o preciso para este usuario.

Restrinxindo ao usuario

Unha vez temos o usuario, neste caso non queremos que teña acceso a outras partes do sistema. Así que imos restrinxilo ao seu propio entorno chroot.
Primeiro crearemos o directorio /home/nome_usuario/chroot. Isto farémolo co comando sudo mkdir /home/nome_usuario/chroot.
A continuación copiamos os arquivos necesarios para este entorno. sudo cp -v /bin/{bash,ls,cp,rm} /lib64/ld-linux-x86-64.so.2 /home/nome_usuario/chroot.
E para rematar ao final do arquivo /etc/ssh/sshd_config, engadimos o seguinte contido.

Match User nome_usuario
    ChrootDirectory /home/nome_usuario/chroot
    ForceCommand internal-sftp
    AllowTCPForwarding no
    X11Forwarding no

NOTA: é importante que o directorio chroot teña permisos 755 e o propietario sexa o root. É dicir só o root terá permiso de escritura. Tamén o ficheiro lib64/ld-linux-x86-64.so.2 temos que cambialo polo da distro que esteamos usando.

E reiniciamos o servicio sshd sudo systemctl restart sshd.

Asignando as claves público-privadas para acceso ssh

O primeiro como vou usar a clave cun novo usuario, prefiro xerar unha nova clave específica para el. Non compartir claves con outros servizos.
Deste xeito, dende o equipo cliente executamos ssh-keygen -t rsa -b 4096 que nos xerará unha nova clave RSA de 4096 bits. ED25519 é máis novo, pero non todo-los clientes son compatibles aínda.

Con isto no directorio /home/usuario/.ssh/ aparecerán dous novos arquivos, coa clave pública e privada. O que debemos facer é copiar o contido da nosa clave pública, no servidor ao que queremos acceder. Para facelo, iremos á ruta /home/usuario/.ssh/ e no ficheiro authorized_keys pegamos a nosa clave, con coidado de pegala enteira e sen engadir outros caracteres. É importante lembrar que estes arquivos de claves, so deben ser accesibles polo propio usuario, así que asignaremos os permisos con chmod 600 authorized_keys id_rsa id_rsa.pub. Asegurándonos que o propietario sexa o propio usuario.

Con isto se temos configurado ssh como vimos no artigo dedicado a isto, xa deberíamos ter acceso.

Conclusión

Con isto teremos un novo usuario que terá uns permisos moi concretos, o que reduce a superficie de ataque e o dano que alguén podería causar, no caso de conseguir acceder a través del. Ademáis ao crear o usuario e utiliar as claves público privadas, tamén facemos que ninguén poida adiviñar o contrasinal. Con manter seguras as claves, non teremos problema.

Pero cabe recordar sempre botar un ollo aos logs para detectar intentos de acceso non autorizado, ou mesmo crear algún tipo de alerta que nos notifique en base a algún patrón. Xa sexa por mail, Slack, Telegram, ou calquer outro sistema. Deste xeito será máis doado previr futuros problemas.