How to Find Saved Wi-Fi Passwords on Linux

Method 1: nmcli (Ubuntu, Fedora, Mint, Pop!_OS)

NetworkManager is the default network stack on the overwhelming majority of mainstream Linux distributions. Its command-line tool, nmcli, was updated in version 1.30 (released 2021) to include a direct device wifi show-password subcommand that prints the password for the currently connected network along with a Wi-Fi QR code ready for phones. On any Ubuntu 22.04, Fedora 36, or Mint 21 or later system this is the one command you need.

# for the currently connected Wi-Fi
sudo nmcli device wifi show-password
# output:
# SSID:       MyHomeNetwork
# Password:   correct horse battery staple
# QR code:    ...
# to list every saved network
nmcli connection show
# to see the password of a specific saved network
sudo nmcli --show-secrets connection show "MyHomeNetwork" \
    | grep 802-11-wireless-security.psk

The --show-secrets flag works on all saved connections, not just the active one, and unlocks both PSKs and EAP-TLS private key passphrases. On older nmcli versions (1.20 and earlier) the flag is unavailable and you must fall back to reading the keyfile directly.

Method 2: Read the NetworkManager keyfile directly

NetworkManager stores every saved connection as an INI-style keyfile under /etc/NetworkManager/system-connections/. Permissions are strict: root-readable only, mode 600. Inside each file you will find a [wifi-security] section with a psk= line.

sudo ls /etc/NetworkManager/system-connections/
# MyHomeNetwork.nmconnection
# StarbucksWiFi.nmconnection
# Office5G.nmconnection

sudo cat /etc/NetworkManager/system-connections/MyHomeNetwork.nmconnection
# [connection]
# id=MyHomeNetwork
# type=wifi
# [wifi]
# mode=infrastructure
# ssid=MyHomeNetwork
# [wifi-security]
# key-mgmt=wpa-psk
# psk=correct horse battery staple
# [ipv4]
# method=auto

# one-liner to dump every SSID + PSK on the box
sudo grep -E '^(ssid|psk)=' /etc/NetworkManager/system-connections/*.nmconnection

On older Debian and Ubuntu releases the files lack the .nmconnection extension. On systems with agent-owned secrets (psk-flags=1) the keyfile will not contain the psk line; instead it is stored in GNOME Keyring or KWallet and you must use method 5 below.

Method 3: wpa_supplicant.conf (Raspberry Pi, minimal Arch, embedded)

Systems that use wpa_supplicant without NetworkManager — most notably Raspberry Pi OS Lite, Alpine, Gentoo minimal installs, and older embedded distributions — store Wi-Fi credentials in /etc/wpa_supplicant/wpa_supplicant.conf. The file is plaintext and every network has a network={ ... } block with SSID and psk lines.

sudo cat /etc/wpa_supplicant/wpa_supplicant.conf
# ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
# update_config=1
# country=US
#
# network={
#     ssid="MyHomeNetwork"
#     psk="correct horse battery staple"
#     key_mgmt=WPA-PSK
# }
#
# network={
#     ssid="Office5G"
#     # note: this PSK is the pre-computed PMK, not the passphrase
#     psk=a1b2c3d4e5f6...0xF8
#     key_mgmt=WPA-PSK
# }

# some setups use per-interface files
sudo cat /etc/wpa_supplicant/wpa_supplicant-wlan0.conf

One subtle gotcha: wpa_supplicant allows the psk value to be stored either as a quoted passphrase (the human-readable password) or as a 64-hex-character pre-computed PMK. If you see 64 hex characters with no quotes, the original passphrase has been discarded and the PMK cannot be converted back. In that case the remaining option is to treat the PMK as a cracking input (hashcat mode 12000) or to retrieve the passphrase from another device that still has it.

Method 4: GNOME Keyring (seahorse)

On GNOME-based desktops (default Ubuntu, Fedora Workstation), network passwords can optionally be stored in the user's login keyring instead of the system keyfile. This is the case when NetworkManager is configured with psk-flags=1 (agent-owned). The graphical tool is seahorse, also known as "Passwords and Keys".

# install if missing
sudo apt install seahorse
# launch
seahorse
# navigate to: Login > Network Secrets > expand your SSID
# right-click entry, Properties, check "Show password"

# headless / scripted access via libsecret
secret-tool search --all xdg:schema org.freedesktop.NetworkManager.Mobile
# for Wi-Fi the schema is usually org.freedesktop.NetworkManager.Wireless

Method 5: KDE KWallet

Kubuntu, KDE Neon and Manjaro KDE store network secrets in KWallet. The GUI tool is kwalletmanager5 or kwalletmanager6. Open it, unlock the default wallet with your login password, expand Passwords, and look for entries under Network Management.

# CLI read via kwallet-query
kwallet-query -l kdewallet
# list entries
kwallet-query -l "NetworkManagement" kdewallet
# dump a specific SSID
kwallet-query -r "MyHomeNetwork" -f "Passwords" kdewallet

Raspberry Pi one-liner

Raspberry Pi OS is a common case because a lot of Pis end up dusty in closets with a Wi-Fi password nobody remembers. SSH in (default user pi / raspberry if you changed nothing) or mount the SD card on another Linux machine.

# on the Pi itself
sudo grep -E '^\s*(ssid|psk)=' /etc/wpa_supplicant/wpa_supplicant.conf

# from an SD card mounted on another machine
sudo grep -E '^\s*(ssid|psk)=' /media/$USER/rootfs/etc/wpa_supplicant/wpa_supplicant.conf

If you cannot boot the Pi and cannot mount the SD card on another machine, the handshake recovery path is still open: capture the handshake from the Pi's access point using any of the methods in our aircrack-ng tutorial and submit the .cap file.

Chromebook Crostini and crouton

Chromebooks running ChromeOS with Crostini (Linux container) or crouton (chroot) have a more complicated story. The Linux side does not have direct access to the ChromeOS network stack; it sees only a virtualised interface. To read the Wi-Fi password on a Chromebook you must either use the ChromeOS UI (Settings, Wi-Fi, known networks, gear icon, Show Password — available only on managed accounts with developer mode) or enable developer mode and use the shell.

# Ctrl+Alt+T opens crosh
crosh> shell
# profile file contains saved network secrets
sudo cat /home/chronos/user/shill/shill.profile
# look for "Passphrase" entries inside [wifi_*] sections

On a managed Chromebook (corporate or school), the Passphrase field may be stripped server-side before sync. In that case the only recovery path is to have IT unlock the network or to use the handshake recovery service.

Recovering passwords from an offline disk image

A surprisingly common scenario: a laptop has died (motherboard failed, screen cracked beyond repair, boot loop of unknown origin) and the owner wants the saved Wi-Fi passwords off it before the machine goes to the recycler. Take the drive out — SATA, NVMe, whatever — plug it into a working Linux machine via a USB-to-SATA adapter or an NVMe enclosure, and mount the filesystem read-only. The password files are in their usual locations; no login shell, no password unlock, no TPM dance required, because NetworkManager and wpa_supplicant store the keyfiles in plaintext on disk.

# identify partitions on the attached disk
lsblk
# typically /dev/sdb2 or /dev/nvme1n1p2 is the root partition
sudo mkdir -p /mnt/oldroot
sudo mount -o ro /dev/sdb2 /mnt/oldroot
# dump every stored NetworkManager PSK
sudo grep -E '^(ssid|psk)=' \
    /mnt/oldroot/etc/NetworkManager/system-connections/*.nmconnection
# and every wpa_supplicant entry
sudo grep -E '^\s*(ssid|psk)=' \
    /mnt/oldroot/etc/wpa_supplicant/wpa_supplicant.conf 2>/dev/null
# clean up
sudo umount /mnt/oldroot

If the drive is encrypted with LUKS, you obviously need the LUKS passphrase to unlock it first. If the Linux install used home-directory encryption (fscrypt, ecryptfs) the system-level /etc keyfiles are still accessible because they live outside the encrypted home. Full-disk encryption wins the whole question; without the passphrase there is no path to the saved Wi-Fi credentials short of cracking the LUKS header, which is a completely different (and much harder) problem.

Bash one-liners for every scenario

# Dump every SSID + PSK from NetworkManager
sudo awk -F= '/^ssid=/{s=$2} /^psk=/{print s": "$2}' \
    /etc/NetworkManager/system-connections/*.nmconnection

# Dump every network from wpa_supplicant.conf
sudo awk '/ssid=/{s=$0} /psk=/{print s" / "$0}' \
    /etc/wpa_supplicant/wpa_supplicant.conf

# Find any file on disk that might contain a PSK
sudo grep -rInE 'psk ?= ?"[^"]+"' /etc 2>/dev/null

# Copy the password of the current network to clipboard (X11)
sudo nmcli device wifi show-password | grep Password | cut -d: -f2- | xclip -sel clip

Permissions, security and what not to do

The Wi-Fi keyfiles on Linux are plaintext by design. NetworkManager chose this over on-disk encryption because the cryptographic unlock key would have to be kept somewhere accessible to the network-manager daemon at boot, which simply shifts the plaintext problem up a layer. The practical consequence is that anyone with root (or physical access to the unencrypted disk) can read every Wi-Fi password the system has ever stored. If the threat model includes someone stealing the laptop, the defence is full-disk encryption, not an attempt to hide the keyfiles.

A common mistake is to commit a dotfiles repository that includes /etc/NetworkManager/system-connections/ symlinked into the user's home directory for portability. The resulting public GitHub repo then contains every Wi-Fi password from every network the user has ever joined, indexed by search engines and grepped by scrapers. Before committing anything that touches NetworkManager state, run git grep -E 'psk ?=' on the staged tree and make sure nothing is leaking. Similarly, shell history (~/.bash_history, ~/.zsh_history) often contains nmcli commands with inline passwords that were passed via --ask replacements — prefix sensitive commands with a space to skip history on most shells, or use the HISTCONTROL=ignorespace setting.

Finally: a legitimate Wi-Fi password recovery from your own system is always an acceptable use. Running these same methods against a laptop that is not yours, even one you have physical access to, crosses an entirely separate line. The techniques in this article work because the owner of the Linux machine allowed Wi-Fi credentials to be stored on it in plaintext; the usual civil and criminal rules about accessing data that belongs to someone else still apply.

Frequently asked questions