- Community Home
- >
- Networking
- >
- Switching and Routing
- >
- Comware Based
- >
- SSHD Process high
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-13-2020 05:16 PM
04-13-2020 05:16 PM
Hi,
I have a HPE MSR1002-4, and this have a CPU high, I put command monitor thread and this is the result
149 processes; 231 threads
Thread states: 2 running, 229 sleeping, 0 stopped, 0 zombie
CPU states: 0.00% idle, 9.28% user, 70.88% kernel, 19.83% interrupt
Memory: 1003M total, 390M available, page size 4K
JID TID LAST_CPU PRI State HH:MM:SS MAX CPU Name
164 164 0 120 R 44:21:57 1 89.63% sshd
642396753 0 120 R 00:00:00 1 1.55% diagd
148 160 0 120 S 25:39:39 1 1.03% nqad
151 228 0 120 S 43:52:27 1 1.03% ospfd
210 211 0 110 S 22:20:28 1 1.03% mscd
83 83 0 120 D 07:46:08 1 0.51% [TMTH]
100 100 0 120 S 03:36:26 2 0.51% aaad
125 125 0 120 S 16:00:47 1 0.51% pppd
148 148 0 120 S 20:52:21 1 0.51% nqad
151 227 0 120 S 21:43:48 1 0.51% ospfd
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-14-2020 01:09 AM - last edited on 06-24-2021 07:19 AM by Ramya_Heera
04-14-2020 01:09 AM - last edited on 06-24-2021 07:19 AM by Ramya_Heera
SolutionHello!
What software version have you got on your MSR1002-4? Let me know and I will check if there are any known bugs that could result high CPU utilization by the SSHD process.
However, if you didn't protect SSH process by ACL and you have exposed the SSH to the Internet, it's pretty possible that somebody is trying to run DoS or DDoS against router's management plane.
Consider implementing following changes, but be sure you are not logged over the SSH, otherwise you will cut out the access to your router. Use a console cable instead.
1. Create an ACL that will permit only internal networks. If you need to access your router from Internet, modify ACL to permit IP address or IP subnet from which you normally access your router. It can be basic or advanced ACL, whatever you prefer. Do not forget to put "deny ip" as the last rule.
2. Disable SSH server by 'undo ssh server enable'.
3. Change the default SSH server's port to something not well-known, for example 52354 - 'ssh server port 52354'
4. Apply the ACL configured on Step 1 to the SSH server - 'ssh server acl <acl's number>'
5. Set SSH server authentication timeout to a small interval, for example 10 seconds - 'ssh server authentication-timeout 10'
6. Start SSH server again - 'ssh server enable'
As result you will have SSH access only from allowed networks on a non-standard port. This should be enough to stop 90% of script kiddies hammering your router.
If that won't help, please, contact our Support line for further investigation and provide them "display diag" and output from the following command:
system-view
probe
follow job 164
This should be enough to start deeper investigation.