Basura de systemd OSC 3008 en terminales SSH: dos soluciones sencillas

Tue, 23 Jun 2026 16:30:26 +0800

Al conectar por SSH a Ubuntu, Kubuntu u otros sistemas Linux recientes basados en systemd, a veces aparecen caracteres de control extraños cerca del prompt. Las pistas habituales incluyen OSC 3008, systemd context y __systemd_osc_context_*. Normalmente no impiden ejecutar comandos, pero ensucian la salida del terminal y pueden colarse al copiar logs.

Este problema no se limita a un único cliente SSH. WindTerm, terminales integrados, emuladores de terminal antiguos o clientes con soporte incompleto de OSC pueden mostrar directamente secuencias de control que deberían ser interpretadas por el terminal.

La causa habitual es que el sistema remoto carga los hooks de contexto OSC de systemd en el entorno Bash, mientras que el cliente SSH actual no procesa correctamente esas secuencias. La solución es directa: confirmar que existen esas funciones hook, sobrescribirlas con funciones vacías y limpiar PS0.

Abajo tienes dos enfoques. El primero va en el ~/.bashrc remoto y sirve cuando quieres tratar todas las sesiones SSH de forma consistente. El segundo va en el comando posterior al inicio de sesión del cliente SSH y es mejor cuando solo quieres afectar a un cliente o una sesión.

Opción 1: interceptar sesiones SSH en .bashrc

La lógica es simple: si la sesión actual es una sesión SSH y realmente existen las funciones OSC inyectadas por systemd, se sobrescriben las funciones relacionadas con no-ops y se limpia PS0.

Añade este bloque al final del ~/.bashrc del servidor remoto:

# Detectar sesiones SSH y bloquear basura de secuencias de control systemd OSC 3008
if [[ -n "$SSH_CLIENT" || -n "$SSH_TTY" || -n "$SSH_CONNECTION" ]]; then
    # Reescribir solo si el sistema cargó realmente las funciones OSC de systemd
    if declare -f __systemd_osc_context_precmdline >/dev/null; then
        __systemd_osc_context_precmdline() { :; }
        __systemd_osc_context_common() { :; }
        __systemd_osc_context_escape() { :; }
        PS0=""
    fi
fi

Después de guardar, vuelve a iniciar sesión por SSH, o ejecuta esto en el shell actual:

`1`	`source ~/.bashrc`

Si la salida basura venía de los hooks OSC de systemd, normalmente desaparece al entrar en un nuevo shell.

Si también quieres cubrir un cliente específico

Algunos clientes establecen sus propias variables de entorno. Por ejemplo, WindTerm puede definir TERM_PROGRAM=WindTerm. Si quieres conservar esa comprobación, puedes usar una versión algo más amplia:

# Detectar WindTerm o sesiones SSH y bloquear basura de secuencias de control systemd OSC 3008
if [[ "$TERM_PROGRAM" == "WindTerm" || -n "$SSH_CLIENT" || -n "$SSH_TTY" || -n "$SSH_CONNECTION" ]]; then
    # Reescribir solo si el sistema cargó realmente las funciones OSC de systemd
    if declare -f __systemd_osc_context_precmdline >/dev/null; then
        __systemd_osc_context_precmdline() { :; }
        __systemd_osc_context_common() { :; }
        __systemd_osc_context_escape() { :; }
        PS0=""
    fi
fi

Para el uso SSH normal, comprobar SSH_CLIENT, SSH_TTY y SSH_CONNECTION basta. Añadir TERM_PROGRAM solo cubre clientes que exponen su propio identificador.

Por qué este enfoque es relativamente seguro

Esta configuración tiene dos barreras.

La primera es la comprobación de sesión:

`1`	`[[ -n "$SSH_CLIENT" \|\| -n "$SSH_TTY" \|\| -n "$SSH_CONNECTION" ]]`

Estas variables suelen aparecer en sesiones de inicio por SSH, por lo que el cambio afecta principalmente a inicios remotos y no modifica sin más el terminal local de escritorio.

La segunda es la comprobación de existencia de la función:

`1`	`declare -f __systemd_osc_context_precmdline >/dev/null`

Es el seguro. La sobrescritura solo ocurre si el shell actual ya cargó __systemd_osc_context_precmdline. Si el sistema no tiene esta lógica OSC de systemd, el bloque no hace nada extra.

Lo que se sobrescribe realmente es:

__systemd_osc_context_precmdline() { :; }
__systemd_osc_context_common() { :; }
__systemd_osc_context_escape() { :; }
PS0=""

Esto evita que los hooks relacionados emitan contenido. PS0 es una variable de prompt de Bash que se expande después de leer un comando y antes de ejecutarlo. Algunas secuencias OSC se insertan mediante PS0 o mecanismos similares, por eso también se limpia.

Opción 2: usar un comando posterior al inicio de sesión en el cliente SSH

Si no quieres editar el ~/.bashrc del servidor remoto, pon la corrección en el comando posterior al inicio de sesión del cliente SSH. Muchos terminales o clientes SSH tienen una función parecida, con nombres como:

Command executed after authentication
Post-login command
Remote command after login
Comando posterior al inicio de sesión

Usa esta línea:

`1`	`__systemd_osc_context_precmdline() { :; }; __systemd_osc_context_common() { :; }; __systemd_osc_context_escape() { :; }; PS0=""`

Si el cliente necesita un salto de línea explícito tras ejecutar automáticamente el comando, añádelo con la sintaxis de ese cliente. Por ejemplo, en Command executed after authentication de WindTerm puedes usar:

`1`	`__systemd_osc_context_precmdline() { :; }; __systemd_osc_context_common() { :; }; __systemd_osc_context_escape() { :; }; PS0="" \n \n`

Los dos \n hacen que el cliente ejecute el comando de limpieza y luego pase a una línea de prompt nueva. Esto sirve para clientes como WindTerm que permiten comandos automáticos después de la autenticación, y se ha probado en un entorno Kubuntu 24.04.

Este enfoque tiene menos alcance: la limpieza solo se ejecuta al conectar con ese cliente y esa sesión. No hace falta cambiar la configuración shell del servidor.

Qué opción elegir

Si el servidor es principalmente tuyo, o quieres que todos los clientes SSH eviten esta salida basura, usa la opción 1. Una vez en ~/.bashrc, WindTerm, Windows Terminal, Tabby, Xshell y otros clientes SSH pueden beneficiarse del mismo tratamiento.

Si el servidor es compartido, o solo quieres que un cliente evite el problema, usa la opción 2. No modifica la configuración remota ni afecta a los entornos shell de otros usuarios.

También puedes probar primero con la opción 2. Si confirma el problema, decide después si la opción 1 debe ir en el ~/.bashrc del servidor.

Notas

Ambas opciones solo suprimen los hooks de salida OSC de systemd. No modifican servicios systemd y no afectan al inicio de sesión SSH.

Sin embargo, si usas un terminal moderno compatible con OSC 3008 y dependes de él para mostrar contexto de comandos, directorio de trabajo o estado del sistema, esas indicaciones mejoradas pueden desaparecer al suprimirlo. Para operaciones SSH normales, inicios en máquinas de desarrollo y administración de servidores, suele estar bien.

Además, no empieces escribiendo estas sobrescrituras en el /etc/bash.bashrc global. Salvo que sepas que todos los usuarios de la máquina necesitan este comportamiento, prefiere ~/.bashrc para entornos personales y el comando posterior al inicio de sesión del cliente para correcciones dirigidas.

Conclusión breve

Si aparece basura de systemd OSC 3008 después de conectar a Linux por SSH, sigue este orden:

Si no quieres cambiar el servidor, configura un comando de limpieza posterior al inicio de sesión en el cliente SSH.
Si es tu propio servidor, pon el bloque de interceptación de sesiones SSH en ~/.bashrc.
Si es un servidor compartido, verifica primero con la solución del cliente y luego decide si conviene llevarlo a la configuración del shell.

La idea central es sencilla: solo en sesiones SSH, comprobar si existen las funciones hook OSC de systemd; si existen, sobrescribirlas con funciones vacías y limpiar PS0. Así se suprime la salida basura sin tocar demasiado el entorno normal del terminal.

SSH on KnightLi Blog