Cambios en sudo-rs y los nuevos avisos de contraseña en Ubuntu

Si llevas tiempo usando Linux, seguro que estás acostumbrado a teclear la contraseña en el terminal y no ver absolutamente nada en pantalla. Ni puntos, ni guiones, ni asteriscos. Solo el cursor parpadeando y tú confiando en que no te equivocas. Pues bien, esa tradición empieza a tambalearse gracias a sudo-rs y a los cambios que ya se están probando en Ubuntu, donde la experiencia al introducir contraseñas en la terminal está viviendo un giro bastante simbólico.

Lo que se está moviendo no es solo un cambio cosmético. Detrás de esos aparentemente inocentes asteriscos hay debates sobre seguridad, usabilidad, la llegada masiva de usuarios desde Windows y la llamada “oxidación” de Linux, es decir, la reescritura de componentes críticos en Rust. Vamos a ver con calma qué está pasando con sudo, con sudo-rs, con Ubuntu 26.04 y por qué un detalle tan pequeño ha montado tanto ruido en la comunidad.

Qué es sudo y por qué nunca mostró la contraseña

El comando sudo es una de esas herramientas que usas casi sin pensarlo. Permite ejecutar tareas administrativas puntuales con permisos de superusuario sin tener que iniciar sesión como root, lo que encaja perfectamente con el principio de mínimo privilegio: trabajas con tu usuario normal y solo elevas permisos cuando es estrictamente necesario.

En sistemas Linux y Unix, sudo lleva décadas siendo la forma estándar de instalar paquetes, editar archivos del sistema, manipular servicios o acceder a directorios protegidos. Frente al modelo clásico de Windows, donde el usuario suele pertenecer al grupo de administradores y se apoya en el UAC, en Linux la aproximación siempre ha sido más conservadora: usuarios normales, permisos limitados y uso puntual de sudo cuando la situación lo requiere.

Hasta ahora, cuando ejecutabas un comando tipo sudo apt update, el sistema te pedía tu contraseña de usuario (siempre que pertenezca al grupo autorizado para usar sudo). El comportamiento tradicional ha sido que al teclear la contraseña no apareciera ni un solo carácter en pantalla. Ni puntos, ni asteriscos, nada. Solo la línea en blanco esperando a que pulses Intro.

Esta decisión no era un capricho. La idea original era que no mostrar ningún feedback visual impedía a un posible observador estimar la longitud de la contraseña contando símbolos. En teoría, cuanta menos información ofrezcas a quien mira por encima del hombro (el famoso “shoulder surfing”), mejor para la seguridad.

A lo largo de los años, ese comportamiento se convirtió casi en una seña de identidad del mundo Unix: si no ves nada al escribir la clave en la terminal, todo va bien. De hecho, muchos veteranos recuerdan cómo tuvieron que explicarle a usuarios novatos “tranquilo, escribe igual, aunque no veas nada, el sistema lo está registrando”.

La llegada de sudo-rs: reescribiendo sudo en Rust

Con el paso del tiempo, la comunidad empezó a mirar con lupa el código de las herramientas más críticas del sistema. sudo es una pieza extremadamente sensible, se ejecuta con privilegios elevados y cualquier vulnerabilidad en su implementación puede abrir la puerta a ataques muy serios. Tradicionalmente, sudo ha estado escrito en C, un lenguaje potente pero propenso a errores de memoria si no se programa con muchísimo cuidado.

Aquí entra en escena sudo-rs. Este proyecto es una reimplementación completa de sudo escrita en Rust, un lenguaje diseñado precisamente para minimizar riesgos de seguridad relacionados con el manejo de memoria: desbordamientos de búfer, uso de memoria no inicializada, dobles liberaciones, etc. La idea no es “reinventar” sudo, sino ofrecer el mismo comportamiento externo con una base de código moderna, más mantenible y, sobre todo, más robusta.

La llamada “oxidación” del sistema (por el color característico de Rust) va más allá de sudo. Canonical, por ejemplo, dio un paso importante con Ubuntu 25.10 al sustituir las coreutils clásicas por uutils coreutils en Rust y al introducir sudo-rs como parte de ese proceso de modernización. Eso significa reescribir comandos tan básicos como ls, cp, rm, mv, date o cat usando Rust, con el objetivo de ofrecer una experiencia consistente y más segura, incluso en otros sistemas como macOS o Windows.

Es importante entender que Rust no es una varita mágica que elimine todos los fallos. Aporta mucha seguridad en todo lo que tiene que ver con la memoria, pero los errores de lógica siguen siendo posibles: condiciones mal planteadas, cálculos incorrectos, opciones mal gestionadas… Eso se ha visto claramente con algunos problemas que surgieron tanto en uutils coreutils como en sudo-rs en Ubuntu 25.10.

Aun así, la apuesta por Rust sigue firme. La filosofía es clara: si vas a tener herramientas críticas corriendo con privilegios de root, mejor que estén construidas sobre cimientos lo más seguros posible. Y sudo-rs encaja de lleno en esa estrategia.

El cambio de pwfeedback: asteriscos por defecto al escribir la contraseña

Donde sudo-rs ha levantado más conversaciones (y alguna que otra bronca en los foros) es en un cambio que a primera vista parece menor: activar por defecto la opción de mostrar asteriscos al escribir la contraseña. Ese comportamiento se controla con un ajuste llamado pwfeedback, que en sudo clásico solía estar desactivado.

Con este cambio, cuando un usuario escribe su contraseña en sudo-rs, la terminal muestra un asterisco por cada tecla pulsada. Es decir, se parece mucho más a lo que sucede en un formulario web, en la pantalla de inicio de sesión de un sistema operativo moderno o en la típica caja de password de cualquier aplicación gráfica.

La justificación de los desarrolladores de sudo-rs es muy directa: la ausencia total de feedback resulta confusa para usuarios menos experimentados, especialmente para quienes vienen de Windows o de entornos donde casi siempre hay algún indicador visual. Ver que aparecen asteriscos transmite la sensación de que el sistema está respondiendo, de que no se ha quedado colgado y de que tus pulsaciones se están registrando.

Al mismo tiempo, explican que este feedback visual no revela información realmente útil sobre la contraseña más allá de una longitud aproximada. No se muestra el carácter real, no se desvela el contenido y, en la práctica, un atacante con un keylogger instalado no necesita ver los asteriscos: le basta con capturar las pulsaciones directamente.

La decisión ha sido polémica, sobre todo entre la “vieja guardia” de usuarios de Linux, muy acostumbrados al comportamiento clásico. Algunos consideran que se está sacrificando una pequeña capa de seguridad por pura comodidad, mientras que otros aplauden que por fin se priorice un poco la experiencia de usuario, algo que tradicionalmente se había dejado en segundo plano en el mundo de la terminal.

Ubuntu 26.04 y el cambio de comportamiento por defecto

Canonical no ha tardado en tomar nota de todo este movimiento. Con la llegada de Ubuntu 26.04 LTS, la compañía quiere hacer la vida un poco más fácil a la avalancha de usuarios que llegan desde Windows y que se encuentran con un entorno que, de entrada, les resulta más áspero. Uno de los gestos en esa dirección es precisamente cambiar el comportamiento por defecto de sudo para mostrar asteriscos al introducir la contraseña.

Hasta ahora, en versiones LTS como Ubuntu 22.04, la contraseña se escribía “a ciegas”, sin ningún símbolo en pantalla. Sin embargo, la funcionalidad pwfeedback ha estado disponible desde hace mucho tiempo: cualquiera podía activarla editando la configuración de sudo. Lo que va a cambiar es que, en la nueva LTS, esta opción vendrá encendida de serie.

De hecho, si quieres adelantarte en una versión actual de Ubuntu, puedes hacerlo fácilmente: abre la configuración de sudo con sudo visudo e incluye la línea Defaults pwfeedback. Guardas, sales, y a partir de ahí cada pulsación de tecla al introducir la contraseña se mostrará como un asterisco en el terminal.

Canonical ha explicado que el objetivo principal es mejorar la usabilidad sin degradar de forma significativa la seguridad. En la práctica, casi ninguna otra interfaz de introducción de contraseñas (ni siquiera en otros contextos de Linux) se comporta como sudo, así que alinear la experiencia con lo que la mayoría de usuarios ya conoce reduce confusión y errores tontos.

Para quien no quiera saber nada de asteriscos, la solución es igual de sencilla. Basta con abrir de nuevo /etc/sudoers (siempre usando visudo) y añadir Defaults !pwfeedback para desactivar ese feedback visual. En otras palabras, el sistema te dará a escoger: o experiencia más amigable o comportamiento clásico sin pistas de longitud.

¿Mostrar asteriscos es realmente menos seguro?

A nivel teórico, el argumento de quienes prefieren mantener la pantalla limpia tiene su lógica: si se muestran asteriscos, una persona que esté mirando de reojo puede contar cuántos símbolos aparecen y hacerse una idea aproximada de la longitud de la contraseña. Esa pista podría usarse en ataques de fuerza bruta o como parte de un escenario más complejo de ingeniería social.

Este tipo de situación se conoce como “shoulder surfing”: alguien que simplemente mira tu pantalla mientras escribes. En entornos compartidos, como oficinas abiertas o universidades, esta preocupación no es del todo descabellada. Saber si una contraseña tiene 6, 10 o 20 caracteres acota un poco la búsqueda para un atacante motivado.

Ahora bien, cuando aterrizamos en la realidad del día a día, el impacto suele ser bastante limitado, sobre todo en equipos domésticos o personales. La inmensa mayoría de sistemas, servicios online y aplicaciones muestran puntos o asteriscos al introducir contraseñas desde hace años, y no por ello se consideran radicalmente inseguros.

Lo único que se revela con los asteriscos es la longitud aproximada, no el contenido de la clave. Los riesgos de seguridad en torno a sudo están mucho más relacionados con vulnerabilidades en el código, configuraciones incorrectas o malas prácticas de administración que con el número de asteriscos que aparecen mientras tecleas.

Los propios desarrolladores de sudo-rs reconocen que, estrictamente hablando, la seguridad teórica es algo menor al exponer la longitud, pero consideran que esa desventaja es “mínima” frente a la mejora en experiencia de usuario. Y, sobre todo, recalcan que quien esté incómodo con el cambio puede desactivarlo sin complicaciones.

Usuarios nuevos, vieja guardia y la experiencia de usar la terminal

Este cambio ha puesto sobre la mesa una tensión que lleva años latente en el ecosistema Linux: cómo equilibrar la tradición y la filosofía Unix con la llegada de usuarios que no han crecido con la terminal. Para muchos veteranos, no ver nada al escribir la contraseña es lo normal. De hecho, recuerdan con cariño cuando tuvieron que explicar ese comportamiento a amigos o compañeros que se iniciaban.

Para un usuario recién aterrizado desde Windows, sin embargo, puede ser una fuente de frustración. Imagina que escribes tu contraseña, no ves nada, pulsas Intro y la terminal responde “contraseña incorrecta”. No sabes si te has equivocado, si el teclado está mal configurado, si el sistema no está registrando las pulsaciones… y lo único que ves es la misma línea en blanco.

Los asteriscos, por sí solos, no convierten la terminal en algo “amigable”, pero sí eliminan esa sensación de vacío y de duda cuando introduces una clave. Es un pequeño guiño a quienes están dando sus primeros pasos y a quienes no tienen por qué conocer de memoria las costumbres de Unix.

Distribuciones como Linux Mint hace ya tiempo que optaron por mostrar asteriscos al escribir la contraseña y el mundo no se ha venido abajo. Ahora que Ubuntu, una de las distros más populares y puerta de entrada para muchos usuarios, se suma a esta tendencia, es normal que el debate se avive.

En el fondo, estamos ante un choque de sensibilidades: los que priorizan cada milímetro de seguridad teórica y los que aceptan un pequeño compromiso a cambio de que el sistema sea más accesible. Dado que la opción clásica sigue ahí y se puede recuperar con una línea en sudoers, parece que hay margen para contentar a ambos bandos.

Más allá de los asteriscos: oxidación de Ubuntu, coreutils en Rust y problemas detectados

El cambio de pwfeedback no llega solo. Forma parte de un contexto mayor: la estrategia de “oxidación” de Ubuntu, que pasa por reescribir utilidades críticas en Rust para mejorar la seguridad y la mantenibilidad del sistema a largo plazo. Ubuntu 25.10, una versión intermedia, se utilizó como banco de pruebas para introducir tanto uutils coreutils como sudo-rs.

Las coreutils son ese conjunto de comandos básicos que usamos constantemente en la terminal: ls para listar archivos, cp para copiar, rm para borrar, mv para mover o renombrar, date para trabajar con fechas y horas, cat para mostrar el contenido de un archivo… Sin ellas, el sistema se queda prácticamente cojo. Tradicionalmente han sido implementadas en C bajo el paraguas de GNU.

Con uutils coreutils, la idea es ofrecer implementaciones en Rust portables y consistentes entre diferentes sistemas operativos. De esta forma, el mismo comportamiento se puede replicar en Linux, macOS y Windows, aprovechando las ventajas que aporta Rust en términos de seguridad de memoria.

Sin embargo, el estreno no fue perfecto. En Ubuntu 25.10 se detectó un bug importante en el comando date, concretamente en la opción date -r. Esta opción sirve para obtener la fecha y hora de la última modificación de un archivo, algo que se usa tanto en scripts de copias de seguridad como en el sistema de actualizaciones automáticas de Ubuntu.

El error hacía que, en lugar de devolver la fecha real de modificación, date -r devolviera siempre la hora actual. A primera vista puede parecer un fallo menor, pero en la práctica rompía dos cosas clave: algunos scripts de backup interpretaban que las copias ya estaban recién hechas (y dejaban de ejecutarse), y el sistema de actualizaciones desatendidas pensaba que la última comprobación se acababa de realizar, por lo que dejaba de buscar actualizaciones nuevas.

Vulnerabilidades en sudo-rs y respuesta de la comunidad

sudo-rs tampoco se libró de los sobresaltos. Se identificaron dos vulnerabilidades relevantes que afectaban a la forma en que la herramienta gestionaba las contraseñas y los tiempos de autenticación. Aunque se corrigieron con rapidez, sirven para recordar que ningún lenguaje está libre de errores de lógica.

La primera vulnerabilidad tenía que ver con el tiempo que sudo-rs espera a que el usuario termine de introducir la contraseña. Si el timeout expiraba mientras estabas escribiendo y aún no habías pulsado Intro, bajo ciertas configuraciones parte de la contraseña podía aparecer en claro en la consola justo antes de que el shell te devolviera el prompt.

Imagina que lanzas un sudo apt update, comienzas a teclear “micontra…” y te distraes. Si se agota el tiempo de espera en ese momento, la cadena parcial que habías escrito podía mostrarse de vuelta en la terminal, exponiendo así información sensible. Es, evidentemente, un fallo de seguridad inaceptable en una herramienta tan crítica.

La segunda vulnerabilidad estaba relacionada con la reutilización indebida de credenciales en algunas configuraciones. En resumen, un atacante local podía llegar a aprovechar el tiempo durante el cual un usuario ya autenticado no necesita volver a introducir la contraseña, evitando así el control esperado y saltándose parte del mecanismo de protección.

Ambos problemas se trataron mediante un proceso de Divulgación Coordinada de Vulnerabilidades (CVD). Esto significa que los fallos se reportaron de forma privada a los responsables del proyecto, se trabajó en los parches necesarios y solo después se hicieron públicos junto con las soluciones correspondientes.

Canonical reaccionó rápido, incorporando las correcciones en la versión sudo-rs 0.2.8-1ubuntu5.2 y publicando un Aviso de Seguridad específico (USN-7867-1) para informar a los usuarios. En paralelo, el bug de date se solucionó actualizando el paquete rust-coreutils (0.2.2-0ubuntu2.1 o posterior) en cuestión de horas, restaurando el correcto funcionamiento de las actualizaciones automáticas.

El papel de las versiones intermedias y qué nos dice todo esto del futuro de sudo

Lo que ha ocurrido con Ubuntu 25.10 es un ejemplo bastante claro de cómo debería funcionar un proceso de modernización en un sistema operativo grande. Las versiones intermedias, con soporte de solo nueve meses, están pensadas precisamente como campo de pruebas para cambios profundos, de forma que los errores se detecten y corrijan antes de aterrizar en una LTS que millones de personas usarán durante años.

En ese sentido, que se hayan encontrado fallos en uutils coreutils y en sudo-rs no es tanto un fracaso como una validación del propio proceso de pruebas. Se han identificado bugs delicados, se han solucionado con rapidez y, de paso, se han añadido tests de regresión que ni siquiera existían en las coreutils originales de GNU.

También se pone de manifiesto la importancia de la comunidad. Los problemas se detectaron gracias a usuarios que reportaron comportamientos extraños y a desarrolladores que reaccionaron de forma coordinada. Esa transparencia y esa capacidad de respuesta son una de las grandes bazas del software libre cuando se afrontan cambios de calado.

De cara a Ubuntu 26.04, todo apunta a que el camino hacia la adopción generalizada de sudo-rs continúa, aunque Canonical se lo esté tomando con calma. La prioridad es que, cuando llegue a una LTS, tanto el comportamiento como la seguridad estén a la altura de lo que se espera de una herramienta tan crítica.

Mientras tanto, el cambio de pwfeedback y la discusión en torno a los asteriscos sirven de termómetro: nos recuerdan que la seguridad no es solo cuestión de bits, sino también de cómo las personas usan las herramientas. Un sistema seguro que nadie entiende o que genera errores por pura confusión tampoco es ideal.

Otros ajustes curiosos de sudo: insultos y bloqueos tras intentos fallidos

Más allá de pwfeedback, sudo tiene otras opciones de configuración curiosas que muestran hasta qué punto se puede personalizar la experiencia. Una de las más conocidas es “insults”, que hace que sudo suelte frases sarcásticas o burlonas cuando introduces una contraseña incorrecta.

Activarlo es tan simple como abrir la configuración con sudo visudo y añadir la línea Defaults insults en cualquier parte del archivo. A partir de ahí, cada vez que te equivoques con la contraseña, sudo no solo rechazará el intento, sino que te regalará un comentario poco amable. No mejora la seguridad, pero sí le da un toque de humor al terminal.

Eso sí, conviene tener en cuenta otra pieza del puzle: los cambios recientes en PAM (Pluggable Authentication Modules) pueden provocar que, tras varios intentos fallidos de contraseña, el sistema bloquee el inicio de sesión durante un tiempo determinado. Por ejemplo, tras tres errores seguidos, podrías quedarte sin poder iniciar sesión durante 15 minutos.

Este bloqueo no depende de la opción insults, sino de la configuración de PAM en tu sistema. La idea es dificultar ataques de fuerza bruta, donde un atacante prueba contraseñas una y otra vez hasta acertar. A cambio, si eres tú el que comete los errores, te tocará esperar o reiniciar el equipo para volver a intentarlo, según cómo esté configurado.

Combinando todo esto, se ve claro que sudo y su ecosistema ofrecen mucho margen de configuración: desde ajustes serios de seguridad hasta pequeños detalles estéticos o de humor. pwfeedback y los asteriscos entran en esa misma categoría de decisiones: no cambian la esencia de sudo, pero sí la forma en la que interactuamos con él.

Todo este movimiento alrededor de sudo-rs, pwfeedback, la oxidación de Ubuntu y los debates sobre asteriscos refleja un momento de transición en el ecosistema Linux: se están reescribiendo piezas críticas en Rust para ganar seguridad de memoria, se afinan los procesos de prueba en versiones intermedias y, al mismo tiempo, se intenta que la experiencia del usuario sea menos críptica sin renunciar al control. Ver asteriscos al escribir la contraseña en sudo puede parecer una nimiedad, pero detrás hay una forma distinta de entender cómo debe sentirse un sistema seguro: no solo blindado por dentro, sino también comprensible y razonable para quienes lo usan cada día.