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

👽

HPE - Enable Jumbo Frames - 3500yl EDGE Switch

Info:

I usually enable jumbo frames on all my switches as part of tuning network performance. This particular setting is beneficial for large transfers, ie in the gigabyte or terabyte range. The endpoints must be able to support jumbo frames or this will not work. If you have virtual switches on the network be sure to configure them for jumbo frames as well.

Start Here:

Login to your HPE switch. Type what is in bold only. Enter is pressed after each command. (This should work with other HPE switches however I do not have an exhaustive list. Consult your manual here if you run into any syntax issues).

After login type:

    <switch># config

You are now in config mode. (After you type this command, in the rightmost column you'll see whether or not Jumbo Frames are enabled on said VLAN:

    <switch>(config)# show vlans

Do not type the < or > character; you just need to insert the VLAN ID# below:

    <switch>(config)# vlan <ID#> jumbo

Check if the setting applied successfully:

    <switch>(config)# show vlans

Save your changes to the switch:

    <switch>(config)# write memory

Logout from the switch.

Next Step:

Be sure to configure any devices in between this switch and including endpoint to support jumbo frames.

TIP:

If you'd like to disable Jumbo Frames for testing, type only what is in bold below while at the CLI:

    <switch>(config)# show vlans

    <switch>(config)# no vlan <ID#> jumbo

    <switch>(config)# show vlans

    <switch>(config)# write memory

The commands above will do the following:

1. You will see the VLAN Jumbo table.
2. You'll turn off jumbo packets for whichever VLAN ID# you type in.
3. You'll verify the setting changed.
4. Finally you'll write the changes to memory.

👽

Windows 10 - How to Disable UAC Remote Restrictions - LocalAccountTokenFilterPolicy

Intro:

I've been testing out a new RMM recently. However after several failed hours trying to decipher a Windows 10 error code I stumbled across a small speed bump that had been causing this error.

I was trying to access a bunch of Windows 10 test VM's across the network by calling up their IP followed by "c$" to access their hidden shares. I needed to copy files to the remote machine but I kept receiving an access denied error.

*Applies to a Windows 8.1 computer sending data to a Windows 10 computer.

*Applies to a Windows 10 computer sending data to a Windows 10 computer.

I tried a bunch of different ways to access two test machines running different versions of Windows 10. Versions were 21H1 & 21H2. Neither seemed to change the outcome.

Problem:

I tried the following:

• Connect via "\\192.168.1.100\c$"
• Connect via "\\192.168.1.100\admin$"
• Remotely connect to another machine using "services.msc"
• Remotely connect to another machine using "regedit.exe"
• Even "Computer Management" failed to connect to the remote machine.

They all returned back with "Error Code 5: Access Denied after typing in the username and password on that machine.

• I made sure the local user existed on both machines with the same password and both had "Administrator" rights.

So far this isn't working like any previous version of Windows and I know that I've been able to connect to hidden shares easily with the correct credentials countless times in the past without having to do anything extra.

I start digging further and come across a Microsoft Knowledge Base article that talks about remote UAC control restrictions for Windows Vista. I know I've seen this post before but I never had to explicitly change anything in the registry to get this to work.

https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/user-account-control-and-remote-restriction#how-to-disable-uac-remote-restrictions

I proceeded to read on and found that one registry key needs to be added and all is right in the world again.😒

How to Disable UAC Remote Restrictions in Windows 10:

1. Start --> Run --> regedit
2. Paste "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" without quotes into regedit and hit Enter.
3. Create a new DWORD (32-bit) Value called, "LocalAccountTokenFilterPolicy" if it doesn't exist and give it a value of 1. Hit OK to save.
4. Exit regedit.

Be sure to add a "DWORD (32-bit) Value" and not a "QWORD (64-bit) Value".

Now if you try any of the things I've mentioned at the beginning of this post they should work without an issue. You do not need to restart or even close the Registry Editor for this to take effect.

It seems that Microsoft has restricted legit local Administrator accounts from achieving full admin access unless interactively accessed via RDP or the likes.

👽

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:

👽

pfSense - Get Memory Module Manufacturer, Part Number, Serial Number, Memory Speed, and Voltage - All Without SSH

Intro:

I found this useful when trying to order memory for a new pfSense network appliance. I had purchased Crucial memory in the past however I've ordered way to much RAM for client machines that it was hard to differentiate between the models. To be 100% sure that I reordered the correct module, I was able to use the command below to grab the exact model number of the RAM stick used in this particular appliance.

Start Here:

1.) Call up your pfSense box and login.

2.) Click on 'Diagnostics' --> 'Command Prompt'

Diagnostics Menu

3.) In the section that says, 'Execute Shell Command' type the following, 'dmidecode --type 17' and click on 'Execute'.

Execute Shell Command

See this image for the syntax

4.) In the section below you can see the manufacturer, part number, serial number, memory speed, and voltage.

Results of dmidecode

Memory Photo by Possessed Photography on Unsplash

👽