Using Devcon to Clear Putty’s “Access Is Denied” Message Without a Reboot

Issue:

Occasionally, after connecting to a USB to UART bridge, you may encounter an "Access is denied" error when launching PuTTY after a successful previous session. Restarting Windows can temporarily resolve this issue, but the error tends to recur. I believe it's happening because the port is still being hung open despite the closing of PuTTY.

Interesting read:
https://stackoverflow.com/questions/20058542/is-it-possible-to-generate-a-deadlock-with-single-lock

Resolution:

Disabling and enabling the device in Device Manager doesn't seem to resolve the issue. However, you can fix it by running the following command in devcon, as long as you know the specific device you're targeting.

1. List all USB devices that are currently connected to the machine:

devcon.exe find *USB*

2. Identify the device you're looking to toggle:

USB\VID_10C4&PID_EA60\0001                                  : Silicon Labs CP210x USB to UART Bridge (COM3)

3. Make sure PuTTY is closed at this point!

4. Disable the device using devcon.exe:

devcon.exe disable "USB\VID_10C4&PID_EA60*"

5. Unplug the device in question from the USB port.

6. Wait a second or two then reinsert the device and run:

devcon.exe enable "USB\VID_10C4&PID_EA60*"

7. Open PuTTY and try connecting to COM3 again.

👽

Copy Saved PuTTY Sessions from One Computer to Another

Intro:

I needed to move all my saved sessions from my main PC to my laptop. Instead of recreating them one by one I decided to dig around and see where PuTTY saves it's sessions to.

Fortunately they are saved in the Windows Registry and a quick export and import on the new machine is all that's needed.

Fix:

1. Press the Windows key and search for "regedit.exe" on the source machine.
2. If you're on Windows 10 you can paste the following link into regedit, "HKEY_CURRENT_USER\Software\SimonTatham\PuTTY".
3. Right click on the tree named, "PuTTY" and select "Export".
4. Save the file with a memorable name and to a location that you can use later to recall the saved .reg file.
5. On the target computer recall that .reg file.
6. Make sure PuTTY is not open. If it is, close it.
7. Double click on that .reg file and select "Yes" to merge the file with the current registry.
8. One that file has been imported open PuTTY and check that everything looks as it should.
9. IMPORTANT - If you have saved certificates they will point to a location on the previous machine. You should copy them over with the same file name and folder structure as on the source machine.

👽

How to Kill Inactive or Forgotten SSH Sessions in Linux

Intro:

From time to time I'll have a slew of terminal windows already open and I'll randomly open another one to the same host. I usually forget that I'm already logged in to another shell via PuTTY. Normally when I'm done with one instance, I'll exit the session and close PuTTY. Then a few minutes goes by and I'll come across another PuTTY window on the screen still logged in. D'oh.

Problem:

Well, that's where killing inactive SSH sessions comes in. Read on for a quick and easy way to identify other sessions.

Fix:

First off, by typing 'w' at the command prompt you can see who else is logged into said computer. You can learn more about this command here and here. (Basic list of Unix commands on Wiki)

Run the following command:

pstree -p

In the following output look for the line that starts with "sshd(XXX)". This seems rather obvious in the following example but in the real terminal there will be other program instances running and you'll see them above and below the following two lines. "sshd(468) is the process you're looking for in the sea of processes. Yours will have a different number after it.

*If you see a line that has "sftp-server" instead of "bash" just know that this is more than likely a connection via "WinSCP" or the likes.

 ├─sshd(468)─┬─sshd(1696)───sshd(1704)───bash(1705)

 │           └─sshd(1943)───sshd(1958)───bash(1959)───pstree(2251)

In the above example look for "pstree" at the end of the line. PID 1943 refers to your current session. The remaining sshd session with a PID of 1696 (first line) indicates another session. You can have multiple sessions to the same computer via SSH, however if your terminal window is closed accidentally or you have a session that is inactive, you would want to kill this session.

Run the following command to kill existing sessions by PID number (replace 1696 with your PID number):

sudo kill 1696

Recheck with the "w" command. You should only see one session, which is your current one.

Extras:

You can also modify the config files for SSH here using "nano" to either disconnect inactive clients after a timeout period or disable a timeout which isn't suggested in a production environment:

"sudo nano /etc/ssh/sshd_config"

Look for the following lines:

ClientAliveInterval 600

ClientAliveCountMax 3

"ClientAliveInterval" is the number of seconds that the server will wait before sending a null packet to the client (to keep the connection alive). If you set this to zero the server will never send the null packet.

"ClientAliveCountMax" is the number of times the server will send the null packet and wait for a response defined by "ClientAliveInterval" before terminating the session.

Example: If you set "ClientAliveInterval" to 400 seconds and set "ClientAliveCountMax" to a count of 5, then the server will send a null packet (through the encrypted channel) every 400 seconds for a count of 5 times waiting to hear back from the client. If the server receives no response from the client after that, then the server will terminate the session after about 33 minutes in this example.

400 * 5 = 2000

2000/60 (minutes)

33.33 minutes

** Remember, a setting of zero means it's disabled. Therefore you should set these values high enough to avoid the "broken pipe error" which means that the data stopped flowing to and the client/server is unable to start the flow back up.

More information can be found here about the above commands:

https://linux.die.net/man/5/sshd_config

👽

PuTTY - Partial Garbled Text in Serial Terminal

Intro:

Incorrect terminal encoding, incorrectly set options, and or terminal speed settings can cause garbled or missing text in a terminal window.

For reference I'm using a USB to Serial, 8 pin RJ45 adapter, between my laptop and a console port on a network appliance. This particular appliance is set to use VT100 and UTF-8 encoding.

The "q" and "x" characters displayed below should be horizontal and/or vertical lines made up from block or line type ASCII characters.

Problem:

The first three images below show what happens when the wrong encoding settings are applied in PuTTY while using a serial connection.

As you can see above, if you're used to speeding through menus, this will immediately slow you down. Fortunately there is a simple fix for this.

Fix:

Load in your previously saved session.

** Verify that your serial speed is correct. In this example it is '115200'.

Under 'Translation' make sure 'Enable VT100 line drawing even in UTF-8 mode' is checked.

Go back to 'Session' and verify the 'Serial Line' and 'Speed' are correct. Click 'Save'. If your previous terminal window is open in the background, do not click on 'Open' on the PuTTY configuration tab. Check the next image.

If your terminal window is still open, verify to the right of the word PuTTY that it does not say 'Inactive'. If it does not and you get a black screen as seen below after you make the Translation change, click in the terminal window and press enter once. You should be returned to your previous session.

What It Should Look Like:

👽