I recently installed HestiaCP (v1.9.2) on a fresh server (Linux Ubuntu Server 22.04 LTS) in my staging environment on Sunday afternoon (GMT timezone). Since then, I haven’t logged into it manually or configured anything.
No additional security measures have been applied yet (besides MFA for the control panel)
The server has no mail domains, no web domains, no databases, and no DNS configured yet
Only two users exist:
Admin user (with a custom name, different from “admin”).
My user (no services assigned).
However, despite not accessing it, SSH connections have been logged, which I cannot explain (please refer to the below screenshot from the last 24 hours)
Findings from Troubleshooting:
1 - SSH Usage Graph shows activity over the last 24 Hours
Attached below is a screenshot showing multiple SSH sessions, but I did not initiate them:
did not reveal any clear system processes that might have initiated the SSH session.
Sanitized Logs
/var/log/auth.log – Successful SSH login (expected, but not initiated by me)
Feb 18 05:32:10 myserver sshd[1635]: Accepted publickey for myuser from xxx.xxx.xxx.xxx port 51550 ssh2: RSA SHA256:xxxxxxxxxxxxxxxxxxxx
Feb 18 05:32:10 myserver sshd[1635]: pam_unix(sshd:session): session opened for user myuser(uid=1001) by (uid=0)
My user logged in via public key authentication
I was NOT using my machine at that time
This suggests something initiated SSH without my interaction
ps aux | grep ssh on my Mac (no SSH sessions active)
Thanks for your response @eris but I don’t believe that’s the case.
1 - My staging environment had SSH activity, even though:
I hadn’t logged in since installing HestiaCP
File Manager was never opened
No users were active
2 - My production environment, where I actively use HestiaCP with multiple users and actual traffic, shows zero SSH activity (see the attached screenshot below):
3 - I checked all system logs (journalctl, auth.log, ps aux), and there is no evidence of HestiaCP initiating an SSH/SFTP session
If File Manager were automatically connecting over SSH/SFTP, I should see similar SSH activity in production—but I don’t.
Can you clarify under what conditions File Manager makes automated SSH connections, and where these would be logged? Because from my tests, this doesn’t seem to be the case.
1 - Since HestiaCP’s SSH usage graph is based on ps aux | grep sshd, it seems like it doesn’t track real SSH logins, but just counts processes:
I’ve confirmed that both my Production and Staging servers return the same ps aux count
However, only Staging reports unexplained SSH activity while Production does not
This suggests the graph is not reliable for detecting real SSH usage
2 - The fact that Ubuntu 24.04 shows “random connections” makes me wonder if newer Ubuntu versions handle SSHD processes differently, leading to false readings:
My server is not running Ubuntu 24.04, but this might still be related
3 - Would it be possible to improve the SSH tracking mechanism to rely on actual login events instead?
Instead of counting ps aux | grep sshd, using journalctl -u ssh | grep "session opened" would provide a more accurate view of real SSH logins.
I appreciate your input—just trying to get to the bottom of this!
I’ve confirmed that both my Production and Staging servers return the same ps aux count
However, only Staging reports unexplained SSH activity while Production does not
This suggests the graph is not reliable for detecting real SSH usage
[/qoute]
It could be random connections from outside it doesn’t mean it is an active ssh connections. If bots try to connect to a server it will be also shown as active connections…
I do a lot more with those server and I haven’t blocked any external ssh connections so it might explain why…
[quote=“ivano.buffa, post:7, topic:18130, full:true”]
3 - Would it be possible to improve the SSH tracking mechanism to rely on actual login events instead?
Instead of counting ps aux | grep sshd, using journalctl -u ssh | grep "session opened" would provide a more accurate view of real SSH logins.
I appreciate your input—just trying to get to the bottom of this!
[/qoute]
Then we need to write an actual log praser to keep track of connection / disconnects to show the actual number. Is the investment of changing it worth it. It might be use to include an ssh log with last xx login attempt instead…
@eris: “No it counts active SSH sessions it excludes the process /usr/sbin/sshd from the list”
Thanks for confirming that HestiaCP only counts active SSH sessions.
However, this still doesn’t explain why:
My Staging environment (where I didn’t log in) showed unexplained SSH activity.
My Production environment (where I have actual users logging in) showed no SSH activity at all.
Both environments return the same ps aux count.
If it’s counting real sessions, why does it show activity in one environment but not the other?
@eris: “If bots try to connect to a server it will also be shown as active connections…”
If the SSH usage graph includes bot connections, shouldn’t I see failed logins in /var/log/auth.log?
I checked my logs, and there were zero failed SSH attempts.
If no failed logins occurred, how would bot activity be counted as an active session?
Can you clarify exactly what HestiaCP is detecting in these cases?
@eris: “Then we need to write an actual log parser to keep track of connections/disconnects… Is the investment worth it?”
I understand that rewriting the SSH tracking mechanism requires effort.
However, if the current system can mislead users into thinking there are active SSH sessions when there aren’t, wouldn’t it make sense to at least provide a more reliable way to track real SSH logins?
Would it be possible to include an option for users to choose between the current tracking method and one based on journalctl logins?
Even adding an SSH log summary (like you suggested) would improve clarity.
If it’s counting real sessions, why does it show activity in one environment but not the other?
It uses greps: all lines with sshd in the list
Then removes the line with grep
Then it removes the line with /usr/sbin/
And then counts the number of lines and nothing more…
I checked my logs, and there were zero failed SSH attempts.
If no failed logins occurred, how would bot activity be counted as an active session?
Can you clarify exactly what HestiaCP is detecting in these cases?
I have no idea only method is to find out Is to run the command and check
It doesn’t look it counts connections. The only thing we can do it to write a script that runs for a few hours and see. what it logs…
Would it be possible to include an option for users to choose between the current tracking method and one based on journalctl logins?
journalctl logins doesn’t show active connections so to show the active connections is “worthless”
Thanks for the quick script and your insights @eris!
I understand that HestiaCP tracks active SSH sessions based on the ps aux count. However, this method doesn’t clarify why Staging shows SSH activity but Production does not. Both servers show the same number of sshd processes, but only Staging reports unexplained SSH activity.
The script you provided works for counting sshd processes, but I’m concerned it counts bot traffic or other background processes as active SSH sessions.
This could lead to false positives, especially when no actual user logged in.
Regarding journalctl, while it doesn’t show active connections, it would give us the real login events, which would be more accurate than process counts.
I understand that we might not want to rely on it fully, but could we at least provide users with an option to track actual SSH logins alongside the current method?
As Staging is running on v1.9.2 and given this post, the output of v-list-cron-jobs admin is empty. Anyhow, this is the list of allk cronjobs in staging:
You can copy /usr/local/hestia/web/rrd/ssh/daily-ssh.png to one of your web domains (or your PC) and try to open it just to check whether the graph is updated.
However, despite not accessing it, SSH connections have been logged, which I cannot explain (please refer to the below screenshot from the last 24 hours)
