Linuxのシェル履歴をクリアする方法とその応用

Bash historyには現在shell memory上のlistとHISTFILE上の永続fileがあり、複数terminalがそれぞれmemoryを持ちます。history -cだけ、history fileだけのtruncate、terminalを閉じるだけでは期待どおりにならない場合があります。削除目的と組織のaudit policyを先に確認します。

結論は「誤入力一件ならhistory -dで対象番号だけを除き、全削除が正当な目的で必要なら他sessionを確認してhistory -c後にhistory -wでcurrent HISTFILEへ反映します。機密情報はhistory以外のlogにも残り得ます」です。

目次

memory historyとHISTFILEを区別する

Bashはcommandをhistory listへ保持し、HISTFILEへsession終了時またはhistory -a/-w等で書きます。HISTCONTROL、HISTIGNORE、HISTSIZE、HISTFILESIZE、histappend optionが保存動作へ影響します。別terminalが古いmemoryを後からappend/writeすると、削除済み行が再びfileへ入る可能性があります。

  • 対象shellがBashか、HISTFILEのpathとowner
  • 一件だけかsession全体か削除範囲
  • 他のBash sessionが開いていないか
  • histappendとPROMPT_COMMAND等の保存設定
  • 会社のaudit・retention・incident policy

最初にecho $BASH_VERSION、printfでHISTFILE、shopt -p histappend、historyの末尾を確認します。history自体にtokenやpasswordがある場合、screenshotやbackup copyを不用意に作りません。shell history削除はsystem audit、sudo log、terminal recording、remote service logを消しません。

どのshellとどの履歴を対象にするかを最初に確認します。Bashでは現在sessionのmemory上のhistoryとHISTFILE上の履歴が別で、複数terminalが同じファイルへ追記する場合があります。echo $HISTFILE、shopt -p histappend、set -o history、historyの末尾、ファイルのowner・mode・mtimeを読みます。zshやfishへBashのhistory commandを流用しません。

一件削除と全削除を選ぶ

誤入力一件ならhistoryの番号を確認しhistory -dで対象だけを除き、history -wで現在listを書きます。全削除が許可され必要なら他sessionを閉じるか各sessionの状態を確認し、history -cとhistory -wを同じBashで実行します。その後、新しいBashでhistory listとHISTFILEを確認します。

history設定を読み取る

printf 'bash=%s\nHISTFILE=%s\n' "$BASH_VERSION" "$HISTFILE"
shopt -p histappend
history 20

末尾だけを表示し、機密commandをscreen shareへ出さないようにします。

一件を番号で削除

history -d 123

123はhistory表示で確認した対象番号です。実行前に隣接行も見て誤削除を防ぎます。

current listをfileへ書く

history -w

現在memory listでHISTFILEを書き直すため、他sessionの未反映historyとの関係を確認します。

current sessionの全historyをclear

history -c
history -w

正当なprivacy/cleanup目的とpolicyを確認し、同じBashでmemory clear後にfileへ反映します。

新しいsessionで確認

bash --noprofile --norc
printf 'HISTFILE=%s\n' "$HISTFILE"
history 5

test shellのstartup設定差を記録し、通常sessionでも再確認します。

一件だけ誤入力したならhistory -d 番号でmemoryから除外し、必要に応じてhistory -wで現在の一覧をファイルへ書く方法を検討します。session全体のmemoryを消すhistory -c、ファイルを書き直す-w、未書込行を追記する-a、ファイルから読む-rの違いを理解し、無関係な履歴を一括消去しません。複数terminalを閉じる順序で古い履歴が再度書かれるため、全sessionの状態を管理します。

history builtinと複数shellの書き戻しを理解する

history -cはcurrent history listをclearします。history -d offsetは指定entryを削除し、-wはcurrent listをhistory fileへ書きます。-aはnew linesをappendし、-nはfileの未読行を読みます。複数sessionとhistappendの設定により、同じHISTFILEへ書く順序が結果を変えます。

  • Bash historyはmemory listとHISTFILEの二層を持つ
  • history -dはoffset指定entryを削除する
  • history -cはcurrent shellのhistory listをclearする
  • history -wはcurrent listをHISTFILEへ書き込む
  • shell history削除はsudo・audit・terminal・service logを削除しない

Bashは起動時にHISTFILEを読み、対話中はmemoryへ履歴を保持し、終了時に上書きまたは追記します。history -cは主に現在sessionのmemoryを消すもので、別sessionや監査ログ、terminal recording、sudo、application logまで消しません。HISTCONTROLのignorespace等も秘密を安全に扱う仕組みではなく、設定やshell差で記録される可能性があります。

audit回避に使わずsecretを入力しない

security incidentや監査対象の証跡を隠す目的で履歴を削除しません。会社端末はretention policyと管理者指示を優先します。passwordやtokenをcommand lineへ入力した場合は、history削除だけで終えずsecret rotation、process list、CI log、clipboard等の露出をincident ownerと確認します。

  • history -cだけでfileも必ず消えたと思う
  • HISTFILEだけを変えてcurrent memoryを残す
  • 複数sessionが古い履歴を再保存する
  • leading spaceならsecretが安全に残らないと考える
  • shell history削除で全system logも消えると思う

秘密をcommand lineへ入力した場合、history削除だけで事故対応を完了しません。API token、password、keyを失効・rotationし、process list、job log、CI log、terminal multiplexer、auditd、backupへの露出をsecurity担当と確認します。監査保持が必要な環境で履歴を消すとpolicy違反や証跡破壊になるため、先に承認を得ます。履歴ファイルをrootで編集してownerを変えないよう注意します。

新しいsessionで削除結果を確認する

全terminalを整理した後、新しい通常Bashでhistoryの末尾とHISTFILEのsize/mtimeを確認します。一件削除なら前後行を保ち対象だけがないこと、全削除なら新commandだけが記録されることを確認します。secret incidentならrotation完了を別checklistで確認します。

  1. Bash、HISTFILE、histappend、active sessionを確認した
  2. 必要最小限の一件または許可された範囲だけを処理した
  3. 新しいsessionでhistory fileの状態を再確認した
  4. secretやaudit対応をhistory削除と分けて完了した

対象sessionでhistoryの該当行がなく、HISTFILEの内容・size・mtime・ownerが期待どおりか確認します。そのsessionを正常終了し、新しいBashを開いて該当行が戻らないかを見ます。別terminalとtmux/screen sessionも確認し、新しい無害なcommand一件が正常に記録されることを試します。秘密事故ならcredential rotationと不正利用監視の完了を別項目で確認します。

履歴削除とcredential対応を分けて判断する

単純な誤入力は一件削除、共有端末のprivacy cleanupはpolicyに沿った全削除を選びます。機密値を入力した場合は履歴cleanupだけで安全とはせず、credentialをrevoke/rotateします。audit preservationが必要なら削除せずsecurity担当へ連絡します。

誤入力一件なら限定削除、個人端末のprivacy cleanupなら保持方針に沿った期間削除、監査環境なら自己削除せず管理者対応を選びます。履歴へ秘密が残る問題は、secret manager、標準入力、環境注入、専用credential helperなど入力経路を直して再発防止します。HISTFILE=/dev/null等の常時無効化は、運用診断と監査の価値を失うため目的とpolicyを明確にします。

公式情報・参考資料

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次