Nunca he pretendido ser un fiera en eso de la seguridad que el hecho de que haya gente que se dedica en exclusiva al tema demuestra lo complejo y difícil que es. Mi vida laboral se mueve en otros ecosistemas menos abstrusos y más cotidianos. Esta es mi forma complicada de decir que es algo en lo que soy bastante novato. Me limito a no instalar cosas raras, abronco duramente a los usuarios que no son cuidadosos con sus claves y poco más.
Pues bien, en estos días me ha tocado configurar un servidor de internet desde cero (es decir a partir de la instalación básica que te da el hosting) para servir como servidor web, de aplicaciones y otros tejemanejes. Todo más o menos bien, un ubuntu 16.04 con Plesk Onix como software de administración, pero cual ha sido mi sorpresa cuando al intentar enjaular a los usuarios que necesitan, para cosas concretas, operar en el SO, me encuentro con que no puedo hacer login vía SSH. Si el usuario tiene una shell /bin/bash, todo correcto. Incluso si les pongo una rbash pero si les creo una jaula de root el sistema me pide la clave y me contesta con un:

Welcome to Ubuntu 16.04.3 LTS (GNU/Linux 4.4.0-97-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

0 packages can be updated.
0 updates are security updates.


Last login: Tue Oct 17 19:21:46 2017 from 185.194.26.216
setreuid() to root failed
system error: Operation not permitted
Connection to <nombre-del-servidor> closed.

Es decir, acepta la clave y luego me tira fuera. No es que la cosa sea muy grave, pero me fastidia enormemente. No puedo reinstalar, porque el servidor ya está en marcha.
He mirado por internet todo lo que he podido, que no hay mucho, pero sólo encuentro referencias a un bug en LDAP, que no es el caso
¿Alguien sabe qué puede estar ocurriendo? ¿Por dónde debería mirar?

(Dios mío, con mensajes así me siento como si estuviera escribiendo al "Locutorio Sentimental de la Señorita Francis")

===================
No podemos regresar

No termino de comprender el problema.
Ubuntu para servidor no te lo recomiendo.
Nunca habilites el usuario root en un servidor, usa sudo.
Nunca dejar el puerto por defecto, el 22 poner otro
Nunca usar protocolo 1, siempre usar 2
etc. etc.
Usa debian estable no ubuntu.
Para el acceso SSH controlalo desde el archivo /etc/ssh/sshd_config
donde basicamente tenes que comentar todo con # y una lineas para controlarlo todo.


Es importante no habilitar al usuario darthvader ya sabes lo que pasa  

Luego guarda el archivo y reinicia el servicio SSH
sudo systemctl restart ssh.service

Saludos.

tincho escribió: [Ver mensaje]

No termino de comprender el problema.
Ubuntu para servidor no te lo recomiendo.
Nunca habilites el usuario root en un servidor, usa sudo.
Nunca dejar el puerto por defecto, el 22 poner otro
Nunca usar protocolo 1, siempre usar 2
etc. etc.
Usa debian estable no ubuntu.
Para el acceso SSH controlalo desde el archivo /etc/ssh/sshd_config
donde basicamente tenes que comentar todo con # y una lineas para controlarlo todo.

Código: [Descargar] [Ocultar] [Seleccionar]

Código: [Descargar] [Mostrar]

### Configurar SSH server
/etc/ssh/sshd_config

Port XXXX
Protocol 2
ListenAddress IP_DEL_SERVIDOR
HostKey /etc/ssh/ssh_host_key
LoginGraceTime 600
PermitRootLogin no
IgnoreRhosts yes
IgnoreUserKnownHosts yes
StrictModes yes
X11Forwarding no
PrintMotd yes
SyslogFacility AUTH
LogLevel INFO
PasswordAuthentication yes
PermitEmptyPasswords no
AllowUsers kirk spock obiwan

Es importante no habilitar al usuario darthvader ya sabes lo que pasa  

Luego guarda el archivo y reinicia el servicio SSH
sudo systemctl restart ssh.service

Saludos.

Debian estable no era ofrecida por el hosting... me temo.
Ofrecían (hablo de memoria) Centos, ubuntu o Arch y ubuntu es lo que mejor conozco (aunque la experiencia en servidores, es decir, sin interfaz gráfica y demás es muy parecida la posibilidad de instalar .debs en el servidor hechos por mí para cosas concretas era muy tentadora (Centos y Arch usan .rpm).

Todo lo que indicas ya está hecho y funcionando, no es el problema. El tema es cuando a un usuario le estableces que al hacer login entre a una jaula de root (chroot). Es una forma de impedir que un usuario se salga de su home. Consiste en crear en su home una serie de carpetas del sistema limitadas (bin, usr, dev, etc..), y establecer esa carpeta como / . La shell entonces no puede hacer nada que no esté en esas carpetas y sólo dentro de su home hacia abajo. Una técnica con mucha solera, es antigua, pero muy efectiva. Si alguien consigue destriparte una clave y colarse... se encuentra enjaulado en su home con una shell capadita de todo.

Sin embargo hay algún problema, sospecho que de permisos aunque le he dado mil vueltas y no veo nada mal, a la hora de establecer la shell...

===================
No podemos regresar

shordi escribió: [Ver mensaje]

...Debian estable no era ofrecida por el hosting... me temo. Ofrecían (hablo de memoria) Centos, ubuntu o Arch...Centos y Arch usan .rpm.

Menudo hosting que no ofrece debian ¿Cual es?.
Por otra parte Arch no usa el formato de paquetes rpm, usa .tar.xz

Encontré este cursillo de chroot con la herramienta jailkit
http://redes-privadas-virtuales.blo...sshsftpscp.html
Por si te sirve de algo.

Saludos.

Shordi:

Enjaular a los usuarios. ¿ Te refieres a esto ?.  

 

Si miráis algo fijo la jaula puede que esta se mueva. Divertidos modos de jugar de la humanidad.

Dicho así. Una versión de Ubuntu algo antigua ya, ¿ no ?.

Saludos

===================
Gambas Básico
"No es un bug, es una característica no documentada"

Shell escribió: [Ver mensaje]

...Una versión de Ubuntu algo antigua ya, ¿ no ?...

Es la version LTS mas actual que hay y tiene soporte hasta 2021. Las versiones 17.xx tienen soporte hasta 2018 solamente.

Saludos.

Citar:

Menudo hosting que no ofrece debian ¿Cual es?.
Por otra parte Arch no usa el formato de paquetes rpm, usa .tar.xz

Me corrijo (ya dije que hablaba de memoria), sí ofrece Debian 8 y 9. Es 1and1. Quizá debí elegirlo en lugar de dejarme llevar por el viejo vicio de tirarte a lo conocido... pero ya está hecho y no hay vuelta atrás.

Citar:

Encontré este cursillo de chroot con la herramienta jailkit
http://redes-privadas-virtuales.blo...sshsftpscp.html
Por si te sirve de algo.

Haré experimentos pues quizá me sirva una vez visto que la herramienta por defecto falla...
En realidad no fallaba en origen. Lo que ocurrió, por pasos fue:

1-Creé un dominio y le dí el acceso enjaulado al usuario del sistema que lo sujeta.
2-Luego creé un subdominio, que es el que necesita el acceso shell para recrear el repositorio de aplicaciones y ví que el acceso enjaulado era el mismo que el de el usuario prinicipal, por lo que si alguien se conseguía colar tendría acceso a los ficheros de la web del dominio principal.
3-Eliminé el acceso a la shell del usuario del dominio principal y creé otro usuario y lo asocié en el subdominio a una shell enjaulada. Entonces ví que el software (Plesk Onix) había asociado el usuario nuevo al dominio principal también con lo que no había solucionado nada.
4-Eliminé entonces, éste último usuario y lo volví a asociar al usuario anterior asignándole el acceso enjaulado otra vez.
5-Al intentar entrar vía ssh a la jaula me daba un error muy extraño sobre permisos erróneos. Revisé los ficheros y me encontré con que el fichero /op/psa/bin/chrootsh tenía un espectro de permisos y propietarios muy extraño.
6- Lo cambié a lo mismo que tenían todos los ficheros de esa carpeta propietario root, grupo root y permiso de ejecución
7- Desde entontes, al intentar entrar da el error ese de "reuid" y te tira fuera.

Un rollazo lo que cuento, pero es lo que hasta ahora he visto mal...


Saludos.

===================
No podemos regresar