mirror of
https://github.com/MacRimi/ProxMenux.git
synced 2026-07-26 18:38:30 +00:00
docs(pbs): promote /web from develop — keyfile UX refresh
- Explicit yes/no escrow choice reinforced ("nothing gets uploaded to PBS
until the operator answers Yes") in intro + recoveryTitle + recoveryBody
- Wrong-key detection: recoverBody extended to describe the structured
amber panel that Monitor shows on View contents / Download / Restore
when the installed keyfile doesn't match the backup's manifest, with
the required fingerprint rendered prominently
- New encryption.monitorManagement section: describes the Download /
Upload / Delete inline actions in each PBS destination row, plus the
Yes/No + passphrase + contextual Apply escrow toggle
- ES: "operador" → "usuario" throughout (glossary rule)
- page.tsx: renders the new subsection and passes {code, em, strong} to
the extended recoveryBody
This commit is contained in:
MacRimi
@@ -217,7 +217,7 @@ export default async function PbsDestinationPage({
|
||||
</h3>
|
||||
|
||||
<p className="mb-4 text-gray-800 leading-relaxed">
|
||||
{t.rich("encryption.recoveryBody", { code })}
|
||||
{t.rich("encryption.recoveryBody", { code, em, strong })}
|
||||
</p>
|
||||
|
||||
<h3 className="text-lg font-semibold mt-6 mb-3 text-gray-900">
|
||||
@@ -271,6 +271,14 @@ export default async function PbsDestinationPage({
|
||||
{t.rich("encryption.recoverBody", { code })}
|
||||
</p>
|
||||
|
||||
<h3 className="text-lg font-semibold mt-6 mb-3 text-gray-900">
|
||||
{t("encryption.monitorManagementTitle")}
|
||||
</h3>
|
||||
|
||||
<p className="mb-6 text-gray-800 leading-relaxed">
|
||||
{t.rich("encryption.monitorManagementBody", { code, em })}
|
||||
</p>
|
||||
|
||||
<h2 className="text-2xl font-semibold mt-10 mb-4 text-gray-900">
|
||||
{t("restoreAccess.heading")}
|
||||
</h2>
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Proxmox Backup Server destination — repository, encryption, recovery | ProxMenux",
|
||||
"description": "The PBS destination writes ProxMenux host backups as PBS backups. Documents repository auto-discovery from /etc/pve/storage.cfg, manual PBS configuration, the .pxar upload command, the client-side keyfile encryption model, the recovery passphrase escrow blob, and the fresh-install keyfile recovery from PBS.",
|
||||
"description": "The PBS destination writes ProxMenux host backups as PBS backups. Documents repository auto-discovery from /etc/pve/storage.cfg, manual PBS configuration, the .pxar upload command, the client-side keyfile encryption model with optional passphrase-wrapped escrow, and the multi-source keyfile recovery on a fresh host.",
|
||||
"ogTitle": "ProxMenux Backup — Proxmox Backup Server destination",
|
||||
"ogDescription": "How ProxMenux writes host backups to Proxmox Backup Server with client-side keyfile encryption and recovery escrow.",
|
||||
"twitterTitle": "PBS backup destination | ProxMenux",
|
||||
@@ -9,7 +9,7 @@
|
||||
},
|
||||
"header": {
|
||||
"title": "Proxmox Backup Server",
|
||||
"description": "The PBS destination uploads the staging root as a single .pxar backup to a Proxmox Backup Server datastore, with optional client-side keyfile encryption and an automatic recovery passphrase escrow for fresh-install disaster recovery.",
|
||||
"description": "The PBS destination uploads the staging root as a single .pxar backup to a Proxmox Backup Server datastore, with optional client-side keyfile encryption and an optional passphrase-wrapped keyfile escrow uploaded next to each backup.",
|
||||
"section": "Backup & Restore"
|
||||
},
|
||||
"recommendedBadge": "Recommended destination",
|
||||
@@ -50,28 +50,30 @@
|
||||
},
|
||||
"encryption": {
|
||||
"heading": "Client-side encryption",
|
||||
"glossaryHint": "This section uses the terms <em>keyfile</em>, <em>passphrase</em> and <em>recovery envelope</em>. If it ever gets hard to keep them apart, the <glosarioLink>glossary</glosarioLink> summarises the differences in one sentence per term.",
|
||||
"intro": "PBS client-side keyfile encryption encrypts chunks on the source host before upload. ProxMenux enables the feature with one added constraint: a recovery passphrase is mandatory when encryption is enabled. The passphrase does not protect the local keyfile; it protects the escrow copy of the keyfile that ProxMenux uploads to PBS for disaster recovery.",
|
||||
"keyfileTitle": "Keyfile",
|
||||
"keyfileBody": "The encryption prompt is a two-step yes/no. Step one asks whether to encrypt the backup: <em>No</em> continues without encryption; <em>Yes</em> moves to step two. Step two depends on whether a keyfile is already installed at <code>/usr/local/share/proxmenux/pbs-key.conf</code>. If it is, the installed keyfile is reused silently and the backup proceeds. If it is not, a two-option menu asks how to set one up. <em>Generate a new keyfile</em> runs <code>proxmox-backup-client key create --kdf none</code> — the resulting keyfile has no passphrase, so the scheduled runner can use it under systemd without any interactive prompt. <em>Import an existing keyfile</em> takes a path the operator supplies and copies it into place with <code>chmod 600</code>; ProxMenux does not inspect the contents (any keyfile the operator accepts as valid on their PBS is accepted here, including scrypt-encoded keyfiles that could not be validated non-interactively). When importing, the flow also asks for the keyfile's own passphrase — the one that <code>proxmox-backup-client key create --kdf scrypt</code> asked for at creation. That passphrase is persisted at <code>/usr/local/share/proxmenux/pbs-key.pass</code> (chmod 600) and reused by every encrypted job on this host as <code>PBS_ENCRYPTION_PASSWORD</code>. Leaving it blank means the keyfile is <code>--kdf none</code> (no passphrase). Both branches run only after the recovery passphrase has been confirmed — cancelling any dialog before that point leaves the disk unchanged.",
|
||||
"glossaryHint": "This section uses the terms <em>keyfile</em>, <em>passphrase</em> and <em>recovery envelope</em>. The <glosarioLink>glossary</glosarioLink> summarises the differences in one sentence per term.",
|
||||
"intro": "PBS client-side keyfile encryption encrypts chunks on the source host before upload. In ProxMenux encryption is optional; when enabled, whether to also upload a passphrase-wrapped copy of the keyfile to PBS as a recovery escrow is an explicit yes/no choice the operator makes at setup time (and can revisit later from the Monitor). The keyfile itself always lives at one canonical path on the host — <code>/usr/local/share/proxmenux/pbs-key.conf</code> — and is reused silently by every subsequent encrypted backup.",
|
||||
"keyfileTitle": "Setting up the keyfile",
|
||||
"keyfileBody": "The encryption prompt runs at the first encrypted backup on the host. Step one asks whether to encrypt the backup: <em>No</em> continues without encryption; <em>Yes</em> moves to step two. Step two depends on whether a keyfile is already installed at <code>/usr/local/share/proxmenux/pbs-key.conf</code>. If it is, the installed keyfile is reused silently and the backup proceeds — subsequent backups never re-ask. If it is not, a two-option menu asks how to set one up. <em>Generate a new keyfile</em> runs <code>proxmox-backup-client key create --kdf none</code>. <em>Use an existing keyfile</em> auto-detects a PVE-managed keyfile: when the selected PBS repository is registered in Proxmox with an encryption key at <code>/etc/pve/priv/storage/<NAME>.enc</code>, that file is copied to the ProxMenux canonical path silently and the flow continues. When no PVE-managed keyfile matches the repository, an input prompts for the absolute path where the operator has already placed the keyfile on this host. Either way, the file lands at the canonical path with <code>chmod 600</code>.",
|
||||
"modesTitle": "Per-host or shared keyfile",
|
||||
"modesIntro": "Both operating models are supported and neither is enforced — the choice belongs to the operator based on how their fleet is organised.",
|
||||
"modesPerHostTitle": "Per-host keyfile (default)",
|
||||
"modesPerHostBody": "Each host generates its own keyfile the first time it enables PBS encryption. Isolation is maximum: compromising the keyfile of one host does not expose the backups of any other. Each host has its own paired recovery blob on PBS, restorable with the recovery passphrase of that host. Recommended for production fleets and for environments where hosts have different owners or compliance boundaries.",
|
||||
"modesPerHostBody": "Each host generates its own keyfile the first time it enables PBS encryption. Isolation is maximum: compromising the keyfile of one host does not expose the backups of any other. Recommended for production fleets and for environments where hosts have different owners or compliance boundaries.",
|
||||
"modesSharedTitle": "Shared keyfile (import on every host)",
|
||||
"modesSharedBody": "One master keyfile generated once and installed on every host via the <em>Import</em> option. Management is simpler: a single secret to safeguard, a single recovery blob works for every host, and any host can decrypt the archives of any other (useful for consolidation, cross-host restore drills, or centralised backup verification). The trade-off is that a leak of the shared keyfile exposes every host at once. Recommended for homelabs and for fleets where all hosts have the same owner and trust boundary.",
|
||||
"recoveryTitle": "Recovery passphrase and escrow blob",
|
||||
"recoveryBody": "The recovery passphrase is asked BEFORE any keyfile is written to disk. ProxMenux prompts twice with match validation; then, only if the operator confirms, the keyfile is created (or imported) and <code>openssl</code> produces <code>pbs-key.recovery.enc</code> — the keyfile encrypted with the passphrase. A copy is written to <code>/root/pbs-key.recovery-HOSTNAME-YYYYMMDD.enc</code> for offsite storage. Cancelling the passphrase dialog leaves the disk untouched — no keyfile is created and no cleanup is needed.",
|
||||
"modesSharedBody": "One master keyfile generated once and installed on every host via the <em>Use an existing keyfile</em> option. Management is simpler: a single secret to safeguard, and any host can decrypt the archives of any other (useful for consolidation, cross-host restore drills or centralised backup verification). The trade-off is that a leak of the shared keyfile exposes every host at once. Recommended for homelabs and for fleets where all hosts have the same owner and trust boundary.",
|
||||
"recoveryTitle": "Upload key to PBS — the operator decides",
|
||||
"recoveryBody": "Right after the keyfile is chosen, ProxMenux asks a single explicit question — <em>Upload key to PBS?</em> — with two answers. <strong>Nothing gets uploaded to PBS until the operator answers Yes.</strong> The default is <em>No, keep local only</em>: the keyfile stays only at the canonical local path, ProxMenux never touches PBS with any recovery artefact, and the operator handles the offsite copy themselves (the Monitor's <em>Download keyfile</em> button in the PBS destination row provides one on demand). Choosing <em>Yes, upload</em> prompts for a recovery passphrase — twice, with match validation — and ProxMenux wraps the keyfile with that passphrase using AES-256-CBC and PBKDF2 (600 000 iterations, random salt) to produce <code>pbs-key.recovery.enc</code>. Every subsequent encrypted backup uploads that envelope to PBS as a paired backup group. Neither the passphrase nor a plaintext copy of the keyfile ever leaves the host. The choice can be changed later from the Monitor at any time — the escrow toggle inline in the PBS destination row flips Yes/No and applies immediately (Start uploading, Stop uploading, or Update passphrase, matching the current state).",
|
||||
"blobUploadTitle": "Paired backup group on PBS",
|
||||
"blobUploadBody1": "After a backup that used the keyfile, ProxMenux uploads the recovery envelope to PBS as a second, paired backup group with the same name as the host group but ending in <code>-keyrecovery</code>. The two groups sit next to each other in the datastore listing — one for host backups, one for recovery envelopes. <strong>The envelope never leaves the host in plaintext</strong>: before upload, ProxMenux encrypts it on the host itself with AES-256-CBC, using a key derived from the recovery passphrase via PBKDF2 with 600 000 iterations and a random salt (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS receives only the already-encrypted envelope, and the upload happens only when the main backup was encrypted.",
|
||||
"blobUploadBody1": "When the escrow mode is <em>Yes, upload</em>, ProxMenux uploads the recovery envelope to PBS after every encrypted backup as a second, paired backup group with the same name as the host group but ending in <code>-keyrecovery</code>. The two groups sit next to each other in the datastore listing — one for host backups, one for recovery envelopes. <strong>The envelope never leaves the host in plaintext</strong>: encryption happens on the host itself with AES-256-CBC and PBKDF2 before any bytes go on the wire (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS receives only the already-encrypted envelope.",
|
||||
"envelopeSecurityTitle": "Is uploading the keyrecovery file to PBS a security risk?",
|
||||
"envelopeSecurityBody": "The keyrecovery file is encrypted in transit and at rest. The recovery passphrase never leaves the host: encryption happens locally before the upload, and PBS only ever sees the already-encrypted result. A PBS administrator — or anyone with access to the datastore — can download the keyrecovery file, but without the recovery passphrase they cannot read the keyfile inside: it is opaque ciphertext. Reconstructing the keyfile requires both pieces at once, the keyrecovery file and the passphrase, and only the operator holds both.",
|
||||
"blobUploadConstraintTitle": "Why two groups instead of a single encrypted one",
|
||||
"blobUploadConstraintBody": "A single <code>proxmox-backup-client backup</code> invocation encrypts every one of its archives with the same keyfile, or none at all — there is no in-between. The host backup has to be encrypted with the host keyfile, but the recovery envelope cannot ride along in that same upload, because it would end up encrypted with the very keyfile it contains: on a freshly reinstalled host there would be no way to open it (you would need the keyfile to decrypt the keyfile). That is why the two artefacts are uploaded independently and appear as two separate groups: the host backup is encrypted by PBS with the keyfile, and the recovery envelope is encrypted by ProxMenux with the passphrase before upload. Two different encryption layers protecting two different assets.",
|
||||
"blobUploadImageAlt": "PBS UI showing the hostcfg-HOSTNAME and hostcfg-HOSTNAME-keyrecovery backup groups adjacent in the datastore listing.",
|
||||
"blobUploadImageCaption": "PBS UI — the paired backup groups. The main group holds the host backups; the -keyrecovery group holds the escrow blob.",
|
||||
"recoverTitle": "Fresh-install recovery",
|
||||
"recoverBody": "On a host without a local keyfile, the restore flow calls <code>hb_pbs_try_keyfile_recovery</code>. The function lists keyrecovery groups on the configured PBS, downloads the newest and prompts for the passphrase. On success, <code>pbs-key.conf</code> is written to the ProxMenux state directory and the encrypted backup can be restored. Without both the keyfile and the passphrase, the encrypted backup is not recoverable."
|
||||
"blobUploadImageCaption": "PBS UI — the paired backup groups. The main group holds the host backups; the -keyrecovery group holds the passphrase-wrapped keyfile.",
|
||||
"recoverTitle": "Recovery on a fresh host",
|
||||
"recoverBody": "When the local keyfile is missing at the canonical path — on a freshly reinstalled host, or after an explicit removal — the restore flow tries three sources in order and stops at the first one that produces a usable keyfile. First, when the selected PBS repository has a matching PVE-managed keyfile at <code>/etc/pve/priv/storage/<NAME>.enc</code>, that file is copied to the canonical path silently. Second, when a <code>-keyrecovery</code> group is available on PBS, the newest snapshot is downloaded and the operator is asked for the recovery passphrase to decrypt it. Third, when neither of the above works or the operator declines them, an input prompts for the absolute path where the keyfile lives on this host and copies it to the canonical path. The Monitor exposes the same import flow inline in the backup detail modal — an amber panel appears at the top of the modal when Restore, Download or View contents would need a keyfile that is not installed. When a keyfile is installed but does not match the one that encrypted the backup, PBS returns a <code>wrong key — manifest's key XX does not match provided key YY</code> error; the same three actions display a structured amber panel with the required manifest fingerprint prominently rendered, so the operator can identify which keyfile to import to open that specific backup.",
|
||||
"monitorManagementTitle": "Managing the keyfile from the Monitor",
|
||||
"monitorManagementBody": "The Monitor exposes the keyfile controls inline in each PBS destination row of the backup configuration page. The row shows three actions: <em>Download</em> exports the current keyfile to the operator's browser, <em>Upload</em> replaces the installed keyfile with one supplied by the operator (the previous file is overwritten only after the new one lands successfully at the canonical path), and <em>Delete</em> removes the keyfile from the host. The recovery-escrow toggle is a single inline control next to those actions: a Yes/No radio for <em>Upload key to PBS?</em>, a passphrase field when Yes is selected, and a contextual Apply button that reads <em>Start uploading</em>, <em>Stop uploading</em> or <em>Update passphrase</em> depending on the current state. Every action goes through the same Flask endpoints that the shell TUI uses, so the on-disk effect and the state on PBS are identical whichever surface the operator picks."
|
||||
},
|
||||
"restoreAccess": {
|
||||
"heading": "Retrieval on the restore side",
|
||||
|
||||
@@ -50,28 +50,30 @@
|
||||
},
|
||||
"encryption": {
|
||||
"heading": "Cifrado del lado del cliente",
|
||||
"glossaryHint": "En esta sección aparecen los términos <em>clave</em>, <em>passphrase</em> y <em>sobre de recuperación</em>. Si en algún momento cuesta seguir cuál es cuál, el <glosarioLink>glosario</glosarioLink> resume las diferencias en una frase por término.",
|
||||
"intro": "PBS puede cifrar las copias con una clave que reside únicamente en el host de origen: los datos se cifran en el propio host antes de subirse, y en PBS solo se guardan cifrados. Sin esa clave, las copias no pueden descifrarse. ProxMenux añade una salvaguarda: cuando se activa el cifrado obliga a definir una <strong>passphrase de recuperación</strong>. Esa passphrase no protege la clave local (que ya vive en el host), sino una copia cifrada de la clave que ProxMenux sube al propio PBS, para poder recuperarla si el host se pierde o se reinstala.",
|
||||
"keyfileTitle": "La clave de cifrado (keyfile)",
|
||||
"keyfileBody": "El diálogo pregunta primero si se quiere cifrar la copia. Si se responde <em>No</em>, la copia continúa sin cifrado. Si se responde <em>Sí</em>, ProxMenux comprueba si el host ya tiene una clave instalada: en ese caso la reutiliza sin más preguntas; si no la tiene, ofrece dos opciones. <em>Generar una clave nueva</em> crea una clave sin contraseña, para que las copias programadas puedan ejecutarse automáticamente sin diálogos. <em>Importar una clave existente</em> permite indicar la ruta de una clave ya generada —por ejemplo la clave común de una flota de hosts—; en ese caso el diálogo pide también la contraseña de esa clave y la guarda cifrada en el host para reutilizarla en cada copia. Cualquiera de las dos opciones se ejecuta solo después de confirmar la passphrase de recuperación; cancelar el diálogo antes de ese punto no deja nada en disco.",
|
||||
"modesTitle": "Keyfile por host o compartido",
|
||||
"glossaryHint": "En esta sección aparecen los términos <em>clave</em>, <em>passphrase</em> y <em>sobre de recuperación</em>. El <glosarioLink>glosario</glosarioLink> resume las diferencias en una frase por término.",
|
||||
"intro": "PBS puede cifrar las copias con una clave que reside únicamente en el host de origen: los datos se cifran en el propio host antes de subirse, y en PBS solo se guardan cifrados. En ProxMenux el cifrado es opcional; al activarlo, subir también a PBS una copia de la clave envuelta con una passphrase (el sobre de recuperación) es una decisión sí/no explícita que toma el usuario durante la configuración inicial (y que puede revisar más tarde desde el Monitor). La clave siempre vive en una única ruta canónica del host — <code>/usr/local/share/proxmenux/pbs-key.conf</code> — y se reutiliza en silencio en todas las copias cifradas siguientes.",
|
||||
"keyfileTitle": "Configuración inicial de la clave",
|
||||
"keyfileBody": "El diálogo aparece en la primera copia cifrada del host. Primero pregunta si se quiere cifrar la copia: <em>No</em> continúa sin cifrado; <em>Sí</em> pasa al segundo paso. El segundo paso depende de si ya hay una clave instalada en <code>/usr/local/share/proxmenux/pbs-key.conf</code>. Si la hay, se reutiliza en silencio y la copia continúa — las copias posteriores no vuelven a preguntar. Si no la hay, aparece un menú con dos opciones. <em>Generar una clave nueva</em> ejecuta <code>proxmox-backup-client key create --kdf none</code>. <em>Usar una clave existente</em> autodetecta una clave gestionada por PVE: si el repositorio PBS seleccionado está registrado en Proxmox con encryption-key en <code>/etc/pve/priv/storage/<NAME>.enc</code>, ese fichero se copia a la ruta canónica de ProxMenux en silencio y el flujo continúa. Cuando ninguna clave PVE coincide con el repositorio, aparece un input pidiendo la ruta absoluta donde el usuario ha colocado la clave en este host. En cualquier caso, el fichero acaba en la ruta canónica con <code>chmod 600</code>.",
|
||||
"modesTitle": "Clave por host o compartida",
|
||||
"modesIntro": "Ambos modelos operativos están soportados y ninguno se impone — la decisión pertenece al usuario según cómo esté organizada su flota.",
|
||||
"modesPerHostTitle": "Keyfile por host (por defecto)",
|
||||
"modesPerHostBody": "Cada host genera su propia clave la primera vez que se activa el cifrado. Es el modo con mayor aislamiento: si la clave de un host se ve comprometida, no afecta a las copias de ningún otro. Cada host guarda además su propio sobre de recuperación en PBS, que se abre con la passphrase de recuperación de ese host. Recomendado para entornos de producción y para escenarios donde cada host tiene su propio responsable o requisitos distintos.",
|
||||
"modesPerHostTitle": "Clave por host (por defecto)",
|
||||
"modesPerHostBody": "Cada host genera su propia clave la primera vez que se activa el cifrado. Es el modo con mayor aislamiento: si la clave de un host se ve comprometida, no afecta a las copias de ningún otro. Recomendado para entornos de producción y para escenarios donde cada host tiene su propio responsable o requisitos distintos.",
|
||||
"modesSharedTitle": "Clave compartida (importar la misma en cada host)",
|
||||
"modesSharedBody": "Se genera una única clave y se importa en todos los hosts mediante la opción <em>Importar</em>. La gestión es más sencilla: hay un solo secreto que proteger, un solo sobre de recuperación válido para todos los hosts, y cualquier host puede leer las copias de cualquier otro (útil para verificar copias desde una máquina distinta o para ejercicios de restauración cruzada). A cambio, si la clave compartida se filtra queda expuesto todo el conjunto de hosts a la vez. Recomendado para laboratorios personales y entornos donde todos los hosts pertenecen al mismo responsable y comparten el mismo nivel de confianza.",
|
||||
"recoveryTitle": "Passphrase de recuperación y sobre cifrado",
|
||||
"recoveryBody": "La passphrase de recuperación se pide ANTES de generar o importar ninguna clave. ProxMenux la solicita dos veces y comprueba que coincidan; solo entonces crea la clave y produce el sobre de recuperación, que consiste en la propia clave cifrada con esa passphrase. Se guarda además una copia local del sobre en <code>/root/</code>, con el nombre del host y la fecha, pensada como respaldo externo (para llevarla a otro medio). Si se cancela el diálogo de la passphrase, no se crea nada: el host queda exactamente como estaba.",
|
||||
"modesSharedBody": "Se genera una única clave y se importa en todos los hosts mediante la opción <em>Usar una clave existente</em>. La gestión es más sencilla: hay un solo secreto que proteger, y cualquier host puede leer las copias de cualquier otro (útil para verificación centralizada, ejercicios de restauración cruzada o consolidación). A cambio, si la clave compartida se filtra queda expuesto todo el conjunto de hosts a la vez. Recomendado para laboratorios personales y entornos donde todos los hosts pertenecen al mismo responsable y comparten el mismo nivel de confianza.",
|
||||
"recoveryTitle": "¿Subir la clave a PBS? — el usuario decide",
|
||||
"recoveryBody": "Justo después de elegir la clave, ProxMenux hace una única pregunta explícita — <em>Upload key to PBS?</em> — con dos respuestas. <strong>No se sube nada a PBS hasta que el usuario responde Sí.</strong> La opción por defecto es <em>No, keep local only</em>: la clave se queda únicamente en la ruta canónica local, ProxMenux no toca PBS con ningún artefacto de recuperación, y el usuario gestiona su propia copia offsite (el botón <em>Download keyfile</em> en la fila de destino PBS del Monitor la genera bajo demanda). Al elegir <em>Yes, upload</em>, ProxMenux pide una passphrase de recuperación —dos veces, comprobando que coincidan— y envuelve la clave con esa passphrase usando AES-256-CBC y PBKDF2 (600 000 iteraciones, sal aleatoria) para producir <code>pbs-key.recovery.enc</code>. Todas las copias cifradas siguientes suben ese sobre a PBS como grupo emparejado. Ni la passphrase ni una copia en claro de la clave salen nunca del host. La elección se puede cambiar más adelante desde el Monitor en cualquier momento — el interruptor de escrow inline en la fila del destino PBS conmuta Sí/No y se aplica en el acto (Start uploading, Stop uploading o Update passphrase, según el estado actual).",
|
||||
"blobUploadTitle": "Grupo emparejado en PBS",
|
||||
"blobUploadBody1": "Tras una copia cifrada, ProxMenux sube el sobre de recuperación a PBS como un segundo grupo de copia, con el mismo nombre que el del host pero terminado en <code>-keyrecovery</code>. Así aparecen los dos juntos en el listado del datastore, uno con las copias del host y otro con los sobres de recuperación. <strong>El sobre nunca sale del host en claro</strong>: antes de subirse, ProxMenux lo transforma en el propio host en un fichero cifrado con AES-256-CBC, usando una clave derivada de la passphrase de recuperación mediante PBKDF2 con 600 000 iteraciones y sal aleatoria (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS recibe únicamente el sobre ya cifrado, y solo se sube cuando la copia principal ha ido cifrada.",
|
||||
"blobUploadBody1": "Cuando el modo elegido es <em>Yes, upload</em>, ProxMenux sube el sobre de recuperación a PBS después de cada copia cifrada como un segundo grupo emparejado, con el mismo nombre que el del host pero terminado en <code>-keyrecovery</code>. Los dos grupos aparecen juntos en el listado del datastore, uno con las copias del host y otro con los sobres. <strong>El sobre nunca sale del host en claro</strong>: el cifrado ocurre en el propio host con AES-256-CBC y PBKDF2 antes de que se envíe un solo byte (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS recibe únicamente el sobre ya cifrado.",
|
||||
"envelopeSecurityTitle": "¿No es un riesgo subir el archivo keyrecovery a PBS?",
|
||||
"envelopeSecurityBody": "El keyrecovery viaja y se almacena cifrado en todo momento. La passphrase de recuperación nunca abandona el host: el cifrado ocurre localmente antes de la subida y PBS solo recibe el resultado ya cifrado. Aunque un administrador de PBS —o cualquiera con acceso al datastore— descargue el keyrecovery, sin la passphrase de recuperación no puede leer la clave que contiene: son solo bytes cifrados. Para reconstruir la clave hacen falta las dos cosas al mismo tiempo, el keyrecovery y la passphrase, y solo el operador dispone de ambas.",
|
||||
"envelopeSecurityBody": "El keyrecovery viaja y se almacena cifrado en todo momento. La passphrase de recuperación nunca abandona el host: el cifrado ocurre localmente antes de la subida y PBS solo recibe el resultado ya cifrado. Aunque un administrador de PBS —o cualquiera con acceso al datastore— descargue el keyrecovery, sin la passphrase de recuperación no puede leer la clave que contiene: son solo bytes cifrados. Para reconstruir la clave hacen falta las dos cosas al mismo tiempo, el keyrecovery y la passphrase, y solo el usuario dispone de ambas.",
|
||||
"blobUploadConstraintTitle": "Por qué dos grupos y no uno solo cifrado",
|
||||
"blobUploadConstraintBody": "Una misma subida de <code>proxmox-backup-client backup</code> cifra todos sus archivos con la misma clave, o no cifra ninguno — no hay opción intermedia. La copia del host tiene que ir cifrada con la clave del host; el sobre de recuperación no puede ir en esa misma subida, porque quedaría cifrado con la clave que precisamente contiene: en un equipo recién reinstalado no habría manera de abrirlo (haría falta la clave para descifrar la clave). Por eso se hacen dos subidas independientes y aparecen como dos grupos separados: la copia del host va cifrada por PBS con la clave, y el sobre de recuperación va cifrado por ProxMenux con la passphrase antes de subirse. Son dos capas de cifrado distintas que protegen dos activos distintos.",
|
||||
"blobUploadImageAlt": "Interfaz de PBS mostrando los grupos hostcfg-HOSTNAME y hostcfg-HOSTNAME-keyrecovery adyacentes en el listado del datastore.",
|
||||
"blobUploadImageCaption": "Interfaz de PBS — los grupos de copia emparejados. El grupo principal contiene las copias del host; el grupo -keyrecovery contiene el blob de escrow.",
|
||||
"blobUploadImageCaption": "Interfaz de PBS — los grupos de copia emparejados. El grupo principal contiene las copias del host; el grupo -keyrecovery contiene la clave envuelta con la passphrase.",
|
||||
"recoverTitle": "Recuperación en un equipo recién instalado",
|
||||
"recoverBody": "Si se intenta restaurar en un equipo que no tiene todavía la clave de cifrado —por ejemplo tras reinstalar el host desde cero—, ProxMenux consulta los grupos de recuperación del PBS configurado, descarga el sobre más reciente y pide la passphrase de recuperación. Al confirmarla, la clave queda instalada en el host y la copia cifrada ya puede restaurarse con normalidad. Sin la clave y sin la passphrase, la copia cifrada no puede recuperarse."
|
||||
"recoverBody": "Cuando falta la clave en la ruta canónica —tras reinstalar el host desde cero o después de eliminarla explícitamente— el flujo de restauración prueba tres fuentes en orden y se queda con la primera que produce una clave usable. Primero, si el repositorio PBS seleccionado tiene una clave gestionada por PVE en <code>/etc/pve/priv/storage/<NAME>.enc</code>, ese fichero se copia a la ruta canónica en silencio. Segundo, si hay un grupo <code>-keyrecovery</code> disponible en PBS, se descarga el snapshot más reciente y se pide al usuario la passphrase de recuperación para descifrarlo. Tercero, si ninguna de las dos vías anteriores funciona o el usuario las declina, aparece un input pidiendo la ruta absoluta donde vive la clave en este host, y el fichero se copia a la ruta canónica. El Monitor expone el mismo flujo de importación de forma inline en el modal de detalle de la copia — aparece un panel ámbar en la parte superior cuando Restaurar, Descargar o Ver contenido necesitarían una clave que no está instalada. Cuando la clave sí está instalada pero no coincide con la que cifró la copia, PBS devuelve un error <code>wrong key — manifest's key XX does not match provided key YY</code>; las mismas tres acciones muestran un panel ámbar estructurado con el fingerprint del manifest destacado en primer plano, para que el usuario pueda identificar qué clave importar para abrir esa copia concreta.",
|
||||
"monitorManagementTitle": "Gestionar la clave desde el Monitor",
|
||||
"monitorManagementBody": "El Monitor expone los controles de la clave de forma inline en cada fila de destino PBS de la página de configuración de copias. La fila muestra tres acciones: <em>Descargar</em> exporta la clave actual al navegador del usuario, <em>Subir</em> reemplaza la clave instalada por una que aporta el usuario (el fichero anterior solo se sobrescribe cuando el nuevo llega correctamente a la ruta canónica), y <em>Eliminar</em> retira la clave del host. El interruptor del sobre de recuperación es un único control inline junto a esas acciones: un radio Sí/No para <em>Upload key to PBS?</em>, un campo de passphrase cuando se selecciona Sí, y un botón Apply contextual que dice <em>Start uploading</em>, <em>Stop uploading</em> o <em>Update passphrase</em> según el estado actual. Todas las acciones pasan por los mismos endpoints Flask que usa el TUI del shell, así que el efecto en disco y en PBS es idéntico independientemente de qué superficie elija el usuario."
|
||||
},
|
||||
"restoreAccess": {
|
||||
"heading": "Recuperación del lado de la restauración",
|
||||
|
||||
Reference in New Issue
Block a user