Bcrypt hash přenesený neuvozeným heredocem přes SSH ztratí $2b$12$ prefix

import { Aside } from ‘@astrojs/starlight/components’;

Bcrypt hashe nikdy nevkládat do neuvozeného heredocu ani ssh argumentu — přenášet přes stdin pipe, base64 (decode na cílové straně), nebo quoted heredoc 'EOF'.

Symptom

Skript vytvoří testovací účty vzdáleným SQL INSERTem přes SSH — INSERT proběhne bez chyby, účet v DB existuje, ale přihlášení vrací 401 „nesprávné heslo”. Hash v DB má správnou délku „na pohled”, ale nezačíná $2b$12$.

Root cause

Bcrypt hash začíná $2b$12$…. Při přenosu přes neuvozený heredoc (<<EOF místo <<'EOF') nebo přímo v ssh argumentu shell interpoluje $2b a $12 jako (neexistující) proměnné → z hashe zmizí prefix a vznikne zkomolená hodnota, kterou bcrypt compare nikdy nevaliduje:

# ŠPATNĚ — $2b a $12 sežere shell:
ssh server psql ... <<EOF
INSERT INTO "User" (password) VALUES ('$HASH');
EOF

Zákeřné je, že INSERT uspěje — chyba se projeví až u loginu, o několik kroků dál.

Fix

Přenést hash kanálem, který shell neinterpoluje. Nejrobustnější je base64:

B64=$(printf '%s' "$HASH" | base64)
ssh server psql ... <<EOF
INSERT INTO "User" (password)
VALUES (convert_from(decode('$B64', 'base64'), 'UTF8'));
EOF

Alternativy: stdin pipe (printf '%s' "$SQL" | ssh server psql), nebo quoted heredoc <<'EOF' (pozor — pak se neinterpoluje nic, včetně proměnných, které interpolovat chcete).

Poučení

• Dolarové prefixy v datech ($2b$…, $argon2…, Stripe klíče sk_…$) jsou klasické oběti shell interpolace — kdykoli data putují přes shell hranici (ssh, heredoc, -c argument), volit neinterpolující kanál.
• Test „INSERT prošel” nestačí — ověřit funkčně (login) nebo aspoň porovnat hash v DB s originálem.