I diagnosed this exact fault three times last month alone. A user connects to a Linux server over SSH from Windows Command Prompt or Windows Terminal, goes to type their password, presses a number on the numeric keypad and instead of a single digit the cursor seems to eat 3 or 4 characters. The NumLock SSH password characters bug is genuinely confusing the first time you see it, because the password prompt doesn't echo anything anyway, so you're left guessing whether you've typed 8 characters or 32. Here's what's actually happening and how to stop it.
TL;DR
NumLock SSH password characters going wrong is a Windows terminal keypad mapping issue, not a Linux problem. The numeric keypad sends multi-character escape sequences instead of plain digits when the terminal is in application keypad mode. Fix it fast by toggling NumLock 3 times, or just use the top-row number keys. For a permanent fix, disable bracketed paste mode or set up SSH key authentication.
Key Takeaways
- NumLock SSH password characters appearing as 3-4 chars per keypress is a Windows terminal keypad bug, not a Linux or SSH server issue.
- The fastest fix is pressing NumLock 3 times to resync state, or switching to top-row digit keys entirely.
- Bracketed paste mode in Windows Terminal is a known trigger for this behaviour and can be disabled with a single command.
- SSH key authentication removes password prompts entirely and is the recommended long-term solution.
- The Linux password prompt never echoes characters. That silence is normal and expected.
At a Glance
- Difficulty: Easy to Medium
- Time Required: 5 to 20 mins
- Success Rate: 90% of users fixed with Tier 1 steps
What Causes NumLock SSH Password Characters to Multiply?
The root of this problem sits in how the numeric keypad communicates with terminal emulators. When you press the number 7 on the main keyboard, your system sends a simple ASCII code for the character '7'. But the numeric keypad is different. It has two modes: a normal mode (with NumLock on) that sends digits, and an application mode that sends escape sequences like ESC [ 2 ~ or ESC O w. These sequences are multi-character strings designed to signal cursor movement or function key presses to terminal applications.
Here's where it gets messy. When Windows Terminal or the legacy cmd.exe SSH client opens an SSH connection to a Linux host, there's a handshake about what kind of terminal is being emulated (usually xterm-256color or similar). Part of that negotiation can accidentally leave the terminal in application keypad mode. In that state, pressing 7 on your numpad sends something like ESC O w to the Linux side. That's three characters. The SSH password prompt silently accepts all three, which is why your password ends up being much longer than intended and login fails.
There are a few specific triggers worth knowing about. First, there's a long-standing NumLock synchronisation bug where the keypad state doesn't reset properly when you switch focus to a console or SSH window. Microsoft has documented this in Windows Terminal's issue tracker. Second, if you have multiple keyboard layouts installed on Windows, the active layout at the moment of connection can affect how keycodes are translated. Third, Windows Terminal's bracketed paste mode implementation has had bugs in certain builds that cause it to wrap even typed input in extra escape sequences. Any of these can produce the NumLock SSH password characters problem you're seeing.
One thing that catches people out: the Linux password prompt never shows any characters at all, not even asterisks. So if you're typing on the numpad and nothing appears, that's actually normal. The problem only becomes obvious when login fails repeatedly despite typing what you believe is the correct password. The real character count going through is wrong because of the escape sequences being injected.
Worth noting: this is entirely a client-side issue. Your Linux server is receiving exactly what Windows Terminal sends it. The server isn't broken, SSH isn't broken, and your password isn't wrong. The translation layer between your physical keypress and the SSH stream is the culprit.
NumLock SSH Password Characters Quick Fix
These two fixes take under a minute and solve the problem for most people. Try them before anything else.
Toggle NumLock Three Times Easy
- Press NumLock 3 times
Do this before you start typing your password. The key thing here is that you need to press it an odd number of times to end up in the same on/off state you started in, but the act of toggling forces the console to resync its internal NumLock tracking. Three presses is the number that consistently works in my experience. - Try the password again
Type your SSH password using the numeric keypad and press Enter. If you get a shell prompt, you're done. If login still fails, move to Solution 2 below.
Use Top-Row Number Keys Instead Easy
- Turn NumLock off
Press NumLock once so the indicator light goes off. - Type your password using the digit row above the letters
These are the 1 through 0 keys at the top of the main keyboard area. They always send plain ASCII digits regardless of terminal mode. No escape sequences, no extra characters. - Verify login succeeds
If it works now, you've confirmed the issue is 100% with keypad mapping. You can keep using the top-row keys as a permanent workaround, or follow the intermediate fixes below to sort the keypad properly.
More NumLock SSH Password Characters Solutions
If the quick fixes didn't stick, or you want to actually fix the environment rather than work around it, these intermediate steps address the underlying causes properly.
Disable Bracketed Paste Mode Easy
- Log into your Linux server
Use the top-row digit keys (from Solution 2) to get in if needed. - Run this command in your shell:
printf "\e[?2004l"
This sends a terminal control sequence that explicitly disables bracketed paste mode. Microsoft has flagged this as a workaround for Windows Terminal builds that mishandle input at sudo and SSH prompts. You'll see no output, but the mode change takes effect immediately. - Make it permanent
Add the same line to your~/.bashrcor~/.zshrcfile so it runs every time you open a shell:echo 'printf "\e[?2004l"' >> ~/.bashrc
Then runsource ~/.bashrcto apply it to the current session. - Test by reconnecting
Close the SSH session and reconnect. Try typing with the numeric keypad. Single digits should now come through correctly.
Normalise Keyboard Layouts on Both Systems Medium
- On Windows: remove extra keyboard layouts
Go to Settings > Time and Language > Language and Keyboard. Under your language, click on it and select Language Options. Remove any keyboard layouts you don't actively use. Keep one, ideally English (United States) or your primary layout. Extra layouts sitting in the list can cause Windows to send unexpected keycodes depending on which one is active when you open the SSH session. - On Linux: check and set the keyboard layout
Once logged in, run:setxkbmap -query
This shows the current layout. If it's not what you expect, set it explicitly:setxkbmap us
For UK layout usesetxkbmap gbinstead. - Reconnect and test
Close the SSH session, reopen it, and try the numeric keypad again. Layout mismatches are a less common cause of NumLock SSH password characters issues, but they do come up when users have multiple languages configured.
Set Up SSH Key Authentication Medium
- Generate a key pair on your Windows machine
Open Command Prompt or Windows Terminal and run:ssh-keygen -t ed25519 -C "your_email@example.com"
Accept the default file location. Add a passphrase if you want extra security (this passphrase is typed locally, not over SSH, so keypad issues don't affect it). - Copy the public key to your Linux server
If you have OpenSSH tools installed (they come with Windows 10 and 11 by default), run:ssh-copy-id user@your-server-ip
You'll need to authenticate with your password once more here. Use the top-row digit keys for this final password entry. - Test key-based login
Runssh user@your-server-ipagain. You should get a shell prompt with no password prompt at all, or just a passphrase prompt for your local key file. Either way, the NumLock SSH password characters problem is gone because there's no remote password to type.
If you'd rather skip the manual key setup route, Proton Pass handles credential storage and can generate strong passwords you copy-paste into prompts, which sidesteps the keypad issue completely while you sort the underlying fix.
For users who are also dealing with related terminal weirdness, our guide on Linux terminal keyboard input problems covers a broader set of console input faults that often appear alongside this one.
Advanced NumLock SSH Password Characters Fixes
Still not sorted? These steps go deeper into terminal mode debugging and are for users who are comfortable on the command line and want to understand exactly what's happening.
Inspect Keypad Keycodes Inside the SSH Session Advanced
- Log into Linux and run showkey
In a terminal (not at the password prompt), run:showkey -a
Press a numeric keypad key. You'll see the exact byte sequence it sends. A plain digit like 7 should show decimal 55. If you see sequences starting with 27 (which is ESC), your terminal is in application keypad mode and sending escape sequences instead of digits. - Check your TERM variable
Run:echo $TERM
Common values arexterm-256color,xterm, orvt100. If Windows Terminal is advertising a terminal type that doesn't match its actual behaviour, keypad sequences get misinterpreted. You can test with a simpler terminal type by connecting with:TERM=vt100 ssh user@server
from your Windows client to see if the keypad behaves differently. - Adjust shell startup files if needed
If you find that a shell startup script in~/.bashrcor~/.zshrcis enabling application keypad mode (look for\e[?1horsmkxreferences), comment those lines out and test again. Some terminal multiplexers like tmux or screen also toggle keypad mode on attach. - Test with a different SSH client
Try connecting from WSL (Windows Subsystem for Linux), PuTTY, or a native Linux or macOS machine. If the keypad works fine from those clients, the bug is specific to your Windows Terminal or cmd.exe build. Check for updates to Windows Terminal via the Microsoft Store, as keypad and paste handling bugs have been fixed in several recent releases. The Windows Terminal documentation lists known issues and workarounds for each version.
Configure sudo NOPASSWD for Specific Commands Advanced
- Open the sudoers file safely
Run:sudo visudo
This opens the sudoers configuration in a safe editor that validates syntax before saving. - Add a NOPASSWD rule for your user
Add a line like:youruser ALL=(ALL) NOPASSWD: /path/to/specific/command
This removes the sudo password prompt for that specific command only. For full NOPASSWD access (only do this on machines you control entirely), use:youruser ALL=(ALL) NOPASSWD: ALL
See the OpenSSH man page and standard Linux sudoers documentation for security implications before applying this broadly. - Verify it works
Run a sudo command. If it executes without prompting for a password, the rule is active. This removes the sudo password prompt from your workflow, making NumLock SSH password characters issues irrelevant for elevated commands.
If you're managing multiple Linux servers and this keypad issue is coming up across all of them, our article on managing SSH keys across multiple Linux servers covers a proper key-based workflow that scales well.
Preventing NumLock SSH Password Characters Problems
Most of these issues are avoidable once you know the patterns. Here's what actually makes a difference, in order of impact.
1. Switch to SSH key authentication now. This is the single biggest change you can make. Once keys are set up, you never type a remote password again. The NumLock SSH password characters problem simply doesn't exist in a key-based workflow. The OpenSSH documentation has a clear walkthrough for setting this up. It takes about 10 minutes and you only do it once per server.
2. Use top-row digits for any password you must type manually. Keep this as a habit. The top-row keys never trigger application keypad mode, never send escape sequences, and work correctly in every terminal I've tested. Reserve the numpad for spreadsheets and calculators.
3. Keep one keyboard layout active on Windows. Go to Settings > Time and Language and strip out any layouts you don't use. Multiple layouts sitting in the list introduce a variable that's hard to debug when things go wrong. One layout, consistently applied, removes an entire category of keycode translation bugs.
4. Toggle NumLock deliberately when opening SSH sessions. Make it a habit: open the SSH window, press NumLock once or twice to force a state sync. Takes two seconds and prevents the sync bug from biting you. Sounds trivial but it's stopped dozens of support calls.
5. Update Windows Terminal regularly. Microsoft has shipped fixes for keypad and paste handling bugs in several Windows Terminal releases. Keeping it current via the Microsoft Store means you're less likely to hit known issues. If you're on an older build and seeing weird input behaviour, that alone might be the fix.
A Note on Password Managers and This Problem
One pattern I see regularly: users with complex passwords stored in a manager try to paste them into the SSH prompt and end up with the same extra-character problem, because pasting can trigger bracketed paste mode sequences in the same way keypad input does. If you're using a password manager for SSH credentials, this is worth knowing about.
Several password managers handle this better than others. Tools like Proton Pass are worth considering here. Proton Pass is built by the team behind ProtonMail and ProtonVPN, with a privacy-first architecture that stores credentials end-to-end encrypted. For SSH workflows specifically, having credentials accessible via a browser extension or desktop app means you can copy-paste into prompts cleanly without the keypad being involved at all. Other options in this space include Bitwarden (open source, strong community support) and 1Password (polished cross-platform client). All three are credible choices. I lean toward Proton Pass for users who are already privacy-conscious and running Linux servers, because the open-source audit trail and zero-knowledge model align with that mindset. It's not the only option, but it's the one I'd recommend if you're starting fresh.
The key point: a good password manager gets you out of the habit of typing passwords manually over SSH, which sidesteps the NumLock SSH password characters issue as a side effect of better security practice generally.
For anyone also dealing with keyboard issues in other contexts, our guide on Windows keyboard input problems in terminal applications covers related faults including function key mapping and modifier key behaviour in console hosts.
NumLock SSH Password Characters: Summary
The NumLock SSH password characters bug is one of those problems that looks mysterious until you understand what the numeric keypad is actually sending. It's not Linux, it's not SSH, and it's not your password. It's a Windows terminal keypad mode issue where the numpad sends multi-character escape sequences instead of plain digits. Toggle NumLock 3 times or switch to top-row keys to fix it immediately. For a permanent fix, disable bracketed paste mode in your shell config or, better yet, set up SSH key authentication and remove the password prompt from your workflow entirely. That's the proper solution and it's what I'd recommend to anyone doing this regularly.