SSH connection and other active user warning

[ArneTR]

• Added warning if there are active SSH connections on the system which could influence measurement
• Added warning if there are active users on the system whose activity could influence measurement

Greptile Summary

Added system checks to warn users about active SSH connections and logged-in users that could affect measurement accuracy in the Green Metrics Tool.

• Added check in lib/system_checks.py to detect active SSH connections using pgrep sshd
• Added check in lib/system_checks.py to identify active users via the who command
• Both checks are implemented as WARN level to alert without blocking execution
• Checks align with GMT's goal of ensuring accurate energy consumption measurements

[greptile-apps]

LGTM

_{1 file(s) reviewed, no comment(s)
Edit PR Review Bot Settings | Greptile}

[github-actions]

Eco-CI Output:

Label	🖥 avg. CPU utilization [%]	🔋 Total Energy [Joules]	🔌 avg. Power [Watts]	Duration [Seconds]
Total Run (incl. overhead)	25.69	2725.81	3.98	684.47
Measurement #1	25.6597	2725.81	3.99	682.34

🌳 CO2 Data:
City: San Jose, Lat: 37.3388, Lon: -121.8916
IP: 52.234.2.111
CO₂ from energy is: 0.449758650 g
CO₂ from manufacturing (embodied carbon) is: 0.195288742 g
Carbon Intensity for this location: 165 gCO₂eq/kWh
SCI: 0.645047 gCO₂eq / pipeline run emitted

---

Total cost of whole PR so far:

[ribalba]

But this checks if the demon is running not if someone is connected. Even if no one is connected there will still be a sshd demon running so people can connect.

who should expose users that are connected via sshd or ss -tnp | grep :22 will show open ssh connections

@ArneTR

[ArneTR]

I did look into that when creating the PR and apparently my testing was not sufficient.

On my test system the ssh port listening was done by systemd. Looked like this:

State           Recv-Q           Send-Q                     Local Address:Port                     Peer Address:Port          Process
LISTEN          0                128                              0.0.0.0:2798                          0.0.0.0:*              users:(("sshd",pid=597,fd=3))
LISTEN          0                128                                 [::]:2798                             [::]:*              users:(("sshd",pid=597,fd=4))

But now after your commented I probed more systems, where the sshd process directly sets the listener:

State            Recv-Q           Send-Q                     Local Address:Port                     Peer Address:Port           Process
LISTEN           0                4096                                   *:22                                  *:*               users:(("sshd",pid=5830,fd=3),("systemd",pid=1,fd=309))

The reason for not going for port 22 is that I also want to support ssh watching on non standard ports.

However given that I cannot identify the process I currently have no idea how to do it. Since the sshd is not readable the best shot would be to parse ss and check for port 22 or for sshd as process user ...
Or, maybe even better, to not allow any listening connections at all in the ss list ... (apart from DNS and our DB connection)?

You got a more sleek idea? Or any remarks?

[ribalba]

Couldn't you use who | grep pts?

[ArneTR]

I will look into this, but I have a feeling that forced commands via SSH are not captured through that mechanism ...

[ribalba]

No, but isn’t that a server configuration? I would say that we add something into the documentation that this will then not work. My assumption is that 99+% will have a shell open.