You protect ~/.bashrc.secret with chmod 444 so nothing accidentally overwrites your API keys and passwords. Then your token-refresh script needs to write a new session cookie somewhere — and hits Permission denied.
The fix isn't adding a second writable secrets file. It's stop persisting short-lived tokens entirely.
Refactor the refresh script to output TOKEN HASH on stdout and let the caller capture it:
# refresh_token — reads credentials, prints session token to stdout
CREDENTIALS=$(bash ~/bin/refresh_token 2>/dev/null)
TOKEN=$(echo "$CREDENTIALS" | awk '{print $1}')
HASH=$(echo "$CREDENTIALS" | awk '{print $2}')
No file writes. No second secrets layer. The token lives in the process environment for the duration of the operation and disappears when it's done.
This works because session tokens are cheap to re-obtain — one HTTP call with stored credentials. The only reason to persist them is avoiding that call, which is almost never worth the complexity of managing a writable token store alongside a read-only credential store.
The rule: if you can regenerate it from long-lived credentials in under a second, don't persist it.
If curl throws SSL certificate problem: unable to get local issuer certificate every time in WSL, it's usually a stale CA bundle — especially common on corporate networks running SSL inspection (Zscaler, etc.).
First, refresh the bundle:
sudo apt-get update && sudo apt-get install -y ca-certificates
sudo update-ca-certificates
That fixes most cases. If not, try a full reinstall:
sudo apt-get install --reinstall ca-certificates
sudo update-ca-certificates --fresh
On corporate networks, you likely need your company's root CA certs. You probably already have them somewhere in your Windows filesystem (.crt or .cer files). Copy them all into the trusted store:
sudo cp /c/Certificates/*.crt /usr/local/share/ca-certificates/
sudo cp /c/Certificates/*.cer /usr/local/share/ca-certificates/
sudo update-ca-certificates
Skip .pfx files — those contain private keys and are a different format.
If you don't have the certs handy, export them from Windows:
# PowerShell — list all root certs, look for your company name
Get-ChildItem Cert:\LocalMachine\Root | Select-Object Subject, Issuer | Sort-Object Subject
Or use certmgr.msc (Win+R → certmgr.msc) → Trusted Root Certification Authorities → find your company's cert → right-click → Export → Base-64 encoded X.509.
Test with curl https://google.com after each step.
Most EC2 Windows Server instances don't expose nested virtualization to the guest OS. WSL2 requires Hyper-V extensions, so it simply won't start. WSL1 works fine — it's a translation layer, not a VM.
Enable the WSL feature and reboot in an Admin powershell window:
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
Restart-Computer
After reboot, pin the default version to 1:
wsl --set-default-version 1
On Windows Server, Add-AppxPackage is often broken or unavailable, so the standard wsl --install route fails. Use wsl --import with a rootfs tarball instead:
Now use a non-admin powershell:
mkdir $HOME\WSL
mkdir $HOME\WSL\Ubuntu
Then:
wsl --import Ubuntu $HOME\WSL\Ubuntu .\ubuntu.tar.gz --version 1
What you lose with WSL1: no Docker, no real Linux kernel, no systemd, weaker filesystem compatibility. Fine for CLI tooling, scripting, and build environments. If you need a real kernel, spin up a native Linux EC2 instance instead.
AWS console offers three ways to duplicate an EC2 instance, differing in whether disk data is carried over.
Create AMI (recommended, full clone) — preserves the system disk, installed software, and all configuration.
In the EC2 console, select the target instance → Actions → Image and templates → Create image. Wait for the AMI status to become available (a few minutes to tens of minutes), then go to AMIs → select it → Launch instance from AMI. Adjust instance type, subnet, Security Group as needed.
Launch More Like This (fastest, no data) — copies only instance configuration (type, SG, subnet, tags). The system disk is brand new.
Actions → Image and templates → Launch more like this. The Launch page opens with config pre-filled; confirm and launch. Good for stateless instances, e.g. web servers initialized via userdata.
Launch Template — if the original instance had a Launch Template saved, launch directly from it. EC2 → Launch Templates → select template → Actions → Launch instance from template.
Use AMI for most cases. Use Launch More Like This when you only need the same specs with a clean disk.
AWS 控制台里有三种复制 EC2 的方式，区别在于是否携带磁盘数据。
创建 AMI（推荐，完整克隆） — 保留系统盘数据、已安装软件和所有配置。
EC2 控制台选中目标实例 → Actions → Image and templates → Create image。等 AMI 状态变为 available（几分钟到几十分钟），再到 AMIs 页面选中它 → Launch instance from AMI，按需调整 instance type、subnet、Security Group 即可。
Launch More Like This（最快，但不含数据） — 只复制实例规格配置（type、SG、subnet、tags），系统盘是全新的。
Actions → Image and templates → Launch more like this，进入 Launch 页面时配置已预填好，确认启动就行。适合无状态实例，比如用 userdata 初始化的 web server。
Launch Template — 如果原实例之前保存过 Launch Template，可以直接从模板启动。EC2 → Launch Templates → 选模板 → Actions → Launch instance from template。
大多数场景用 AMI，只需要同规格全新系统时用 Launch More Like This。