• Incident refers to any unexpected event that disrupts normal operations, especially in IT or security.

• Response is the structured approach to detect, contain, and recover from that incident.

• Effective incident response minimizes damage, reduces recovery time, and strengthens future resilience.

• It involves preparation, detection, analysis, containment, eradication, recovery, and post-incident review.

⏱️ The Golden Hour of Cybersecurity

• When a cyberattack strikes, the first 60 minutes are crucial.

• This “golden hour” decides whether your team contains the threat, preserves evidence, and limits damage — or suffers costly downtime and data loss.

• Quick, structured action is the key to survival and recovery.

• Here’s a practical, step-by-step guide to help IT teams respond effectively within that first hour.

⏱️ Minute 0–10: Detect and Validate the Incident

• 🔍 Monitor Security Alerts : Continuously monitor alerts from SIEM, EDR, firewall, and antivirus systems to detect potential security threats in real time.

  Analyze and correlate alerts from multiple sources to identify suspicious patterns or unauthorized activities. Ensure timely response to critical alerts to minimize the impact of security incidents.

• ✅ Confirm It’s a Real Incident, Not a False Positive: Verify whether the alert represents a genuine security incident or a false positive. Correlate data from multiple sources to validate the authenticity of the threat. Ensure accurate incident confirmation before escalating or taking remediation actions.

• 🧩 Identify Affected Systems and Users — Isolate the Scope Quickly : Determine which systems, networks, or user accounts are impacted by the incident. Quickly isolate affected assets to prevent further spread or damage. Define the scope of compromise to guide effective containment and recovery actions.

🔍 Tip: Use centralized logging and correlation tools to speed up validation.

🔒 Minute 10–20: Contain the Threat

• Isolate compromised endpoints from the network: Immediately disconnect compromised endpoints to stop the attack’s spread. Use network segmentation or EDR tools to quarantine infected devices. Preserve forensic evidence while ensuring containment of the threat.

• 👥 Disable Affected User Accounts or Revoke Suspicious Access Tokens: Temporarily disable compromised user accounts to prevent unauthorized access. Revoke suspicious access tokens or sessions to block ongoing threats. Restore account access only after confirming the environment is secure.

• 🌐 Block Malicious IPs, Domains, or Ports at the Firewall or Proxy Level: Block identified malicious IP addresses, domains, and ports to cut off attacker communication. Apply firewall or proxy rules to prevent further infiltration or data exfiltration. Continuously update blacklists based on new threat intelligence.

⚠️ Avoid shutting down systems abruptly — it may destroy forensic evidence.

📣 Minute 20–30: Notify Internal Stakeholders

• 🛠️ Inform IT/Security Leadership and Activate Your Incident Response Team: Notify IT and security leadership immediately about the confirmed incident. Activate the incident response team to coordinate containment and remediation efforts. Ensure clear communication channels for rapid decision-making and status updates.

• 📝 Document Initial Findings: What Was Detected, When, and How: Record the details of the detection, including what triggered the alert. Note the exact time and method of discovery for accurate tracking.

  Maintain thorough documentation to support investigation and future analysis.

• 👥 Assign roles for containment, investigation, and communication Clearly define team roles for containment, investigation, and internal/external communication. Ensure responsibilities are assigned to prevent overlap and delays during the incident. Streamline coordination to enable efficient and effective incident response.

🧠 Clear internal communication prevents confusion and duplication of effort.

📝 Minute 30–40: Begin Documentation

• 🕒 Start a Timeline of Events of events and actions taken: Create a chronological timeline of all detected events and response actions. Track each step to understand the incident’s progression and impact.

  Use the timeline for reporting, analysis, and post-incident review.

• 📝 Record Tools, Commands & Evidence, collected: Document all tools, scripts, and commands used during the investigation. Record any evidence collected from systems, logs, or network devices. Maintain detailed records to support forensic analysis and compliance requirements.

• 🧠 Preserve Logs & Memory Dumps for forensic analysis: Secure and retain system logs and memory dumps for thorough forensic examination. Ensure evidence integrity by following proper chain-of-custody procedures. Use preserved data to identify attack methods, affected systems, and threat actors.

🗂️ Use a shared incident response log or ticketing system to centralize notes.

🔄 Minute 40–50: Plan Next Steps

• 🔄 Decide on Recovery Actions: patching, restoring backups, or re-imaging systems : Determine the best recovery approach: applying patches, restoring from backups, or re-imaging affected systems. Prioritize actions to minimize downtime and prevent reinfection. Ensure systems are fully secured and tested before returning to production.

• 📢 Prepare External Notifications if required (legal, regulatory, customer): Identify stakeholders who must be informed, including legal, regulatory, or affected customers. Draft clear and accurate notifications detailing the incident and mitigation steps. Ensure compliance with laws and regulations while maintaining transparency and trust.

• ⚖️ Engage Forensic & Legal Teams if the breach involves sensitive data: Involve forensic experts to analyze the breach and preserve critical evidence. Consult legal teams to ensure compliance with data protection laws and regulations. Coordinate actions to mitigate risk and support potential investigations or litigation.

📞 Have legal and PR contacts ready in case public disclosure is needed.

🚫 Minute 50–60: Avoid Common Mistakes

• ⚠️ Don’t Shut Down Systems Prematurely: Avoid powering down systems too early to preserve volatile data for investigation. Keep affected systems running under controlled conditions to aid forensic analysis.

• 🚨 Don’t Ignore Logs or Alerts: Always review logs and alerts to detect early signs of potential threats.

  Ignoring them can allow incidents to escalate undetected, increasing risk. Don’t delay internal communication.

• 📚 Don’t Skip Documentation: Maintain detailed records of all actions, findings, and decisions during an incident. Skipping documentation can hinder investigations, reporting, and future prevention efforts.

✅ A calm, methodical response beats panic every time.

🧩 Lesson Learned After a Breach

• 🧠Post-Mortem Review:

  • Review what went wrong and identify gaps in detection or response.

  • Every incident reveals gaps — patch them before the next strike.

  • Conduct team debriefs and share lessons to improve future readiness.

• 📘 IR Plan Update:

  • Formally revise your Incident Response Playbook based on recent findings.

  • Update stronger security policies, smarter tools, better monitoring, and faster response procedures.

  • These are non-negotiable for modern threat defense.

  • Strengthen user awareness and training to prevent similar incidents.

🧭 Key Precautions Against IT Incidents

🧨 A Few Examples Of Recent incidents

1. 🔐 Third-Party Vendor Breach: affected Amazon employee data

• In November 2024, Amazon confirmed that employee work-contact info (emails, desk phone numbers, building locations) was exposed due to a security event at one of Amazon’s property-management vendors.

• Amazon asserted that its own core systems (including AWS) were not compromised, and no sensitive data such as financial or Social Security information was affected. India Today+1

• Lesson: Vendor or third-party risk is real — even if your systems are secure, exposure can occur via partners.

2. 🌐 Global Exploit: Microsoft SharePoint Global‐scale server/software Breach

• In July 2025, three Chinese-linked hacking groups exploited a vulnerability in on-premises SharePoint servers, affecting ~100 organizations (including U.S. federal agencies).

• The attack targeted self-hosted versions of the software, showing how legacy / on-prem systems still carry outsized risk.

• Lesson: Infrastructure software, especially when self-hosted or less frequently updated, can become high-impact attack surfaces with wide ripple effects.

3. 🌩️ Major AWS Outage: October 2025

• On around October 20 2025, AWS (specifically its US-EAST-1 region) experienced a large‐scale outage, disrupting many services globally (including sites like Snapchat, Reddit, Venmo, and even Amazon’s own services). 3Reuters

• The root cause was attributed to a DNS / health-monitoring subsystem failure in the EC2 internal network — not a cyberattack. mint+1

• Lesson: Even when not under attack, operational or infrastructure failures can cause major incidents; resilience and backup planning matter.

📋Check list for Incident Response

Download check list for next 60 min. CheckLlist-1, CheckList-2.

✅ Confirm the incident (validate alerts, logs, and system behavior)

✅ Identify affected systems and scope of impact

✅ Isolate compromised endpoints and disable suspicious accounts

✅ Block malicious IPs, ports, or domains

✅ Notify internal stakeholders and activate IR team

✅ Begin documentation: timeline, actions, tools, evidence

✅ Preserve forensic data (avoid premature shutdowns)

✅ Plan next steps: recovery, external notifications, legal review

✅ Maintain clear communication throughout the process

✅ Review and refine IR workflow post-incident

✅ Conclusion: Speed, Structure, and Clarity Save Systems

The first hour after a cyberattack isn’t just about reacting — it’s about responding with precision. A well-defined incident response workflow empowers IT teams to contain threats, preserve evidence, and maintain trust. Whether you're managing a small business or a global infrastructure, the steps you take in those first 60 minutes can shape the outcome of the entire breach.

By following this checklist, documenting every move, and avoiding common mistakes, your team can turn chaos into control. And remember: the best time to prepare is before an incident ever occurs.

Build your plan. Train your team. Test your response. Because when seconds count, preparation is everything.

🎥 Watch the Full Video

👉Y-iT Simplified - Incident Work Flow

🔔 Call-to-Action

💬 Share your questions in the comments.

👍 If you found this useful, follow me here on Blogs.

🎥 Don’t forget to watch the full tutorial on my YouTube channel:

Incident Work Flow: A Step-by-Step Guide for What to Do in the First 60 Minutes and Precautions.

👨‍💻 About the Author

I’m Rajesh Yerravalli, the creator of Yerravalli IT Simplified.

With over 20 years of experience in IT—covering IT Infrastructure, Linux, Windows, Networking, Servers, Cloud, and Cybersecurity—I’m passionate about breaking down complex technical topics into simple, hands-on tutorials.

📺 Watch tutorials on YouTube: Yerravalli IT Simplified (Y-iT Simplified)

✍️ Read more guides here on Hashnode.

సెక్యూర్ షెల్ (SSH) అనేది రిమోట్ సర్వర్ నిర్వహణకు వెన్నెముక. అయితే, దాని డిఫాల్ట్ బహిర్గత స్థితి ఆటోమేటెడ్ బ్రూట్-ఫోర్స్ దాడులకు ప్రధాన లక్ష్యంగా మారుతుంది, ఇక్కడ బాట్‌లు మీ లాగిన్ ఆధారాలను ఊహించడానికి ప్రయత్నిస్తాయి.

Protecting your server isn't difficult—it just requires a few crucial steps. This guide will walk you through the essential techniques to lock down your server and significantly reduce the risk of compromise.

మీ సర్వర్‌ను రక్షించడం కష్టం కాదు—దీనికి కొన్ని ముఖ్యమైన దశలు మాత్రమే అవసరం. మీ సర్వర్‌ను సురక్షితం చేయడానికి మరియు రాజీ పడే ప్రమాదాన్ని గణనీయంగా తగ్గించడానికి అవసరమైన పద్ధతులను ఈ గైడ్ మీకు చూపుతుంది.

1. Prerequisites

Before we begin, you'll need:

• A Linux server (e.g., Ubuntu, Debian, CentOS, RHEL).

• Root or sudo access to the server.

• Basic familiarity with the Linux command line and text editors like nano or vim.

మనం ప్రారంభించే ముందు, మీకు ఇవి అవసరం:

• ఒక లైనక్స్ సర్వర్ (ఉదా. Ubuntu, Debian, CentOS, RHEL).

• సర్వర్‌కు రూట్ లేదా sudo యాక్సెస్.

• లైనక్స్ కమాండ్ లైన్ మరియు nano లేదా vim వంటి టెక్స్ట్ ఎడిటర్‌లతో ప్రాథమిక పరిచయం.

2. Step 1: Switch to Key-Based Authentication 🔑

2. దశ 1: కీ-ఆధారిత ప్రమాణీకరణకు మారండి 🔑

The single most effective defense is to disable password logins entirely and rely on SSH Key Pairs. This makes brute-force attacks virtually impossible, as guessing a key is mathematically infeasible.

పాస్‌వర్డ్ లాగిన్‌లను పూర్తిగా నిలిపివేసి, SSH కీ జతలపై ఆధారపడటం అత్యంత ప్రభావవంతమైన రక్షణ. కీని ఊహించడం గణితపరంగా అసాధ్యం కాబట్టి, ఇది బ్రూట్-ఫోర్స్ దాడులను ఆచరణాత్మకంగా అసాధ్యం చేస్తుంది.

A. Generate Your Key Pair (On Your Local Machine)

A. మీ కీ జతను రూపొందించండి (మీ స్థానిక యంత్రంలో)

If you don't already have one, generate an ED25519 key pair. This is more secure and faster than RSA.

మీకు ఇప్పటికే లేకపోతే, ED25519 కీ జతను రూపొందించండి. ఇది RSA కంటే సురక్షితమైనది మరియు వేగవంతమైనది.

ssh-keygen -t ed25519

• You'll be prompted to save the key. The default locations (~/.ssh/id_ed25519 for the private key and ~/.ssh/id_ed25519.pub for the public key) are usually fine.

• Set a strong passphrase for your private key.

• కీని సేవ్ చేయమని మీరు ప్రాంప్ట్ చేయబడతారు. డిఫాల్ట్ స్థానాలు (ప్రైవేట్ కీ కోసం ~/.ssh/id_ed25519 మరియు పబ్లిక్ కీ కోసం ~/.ssh/id_ed25519.pub) సాధారణంగా సరిపోతాయి.

• మీ ప్రైవేట్ కీ కోసం బలమైన పాస్‌ఫ్రేజ్‌ను సెట్ చేయండి.

B. Copy the Public Key to the Server

B. పబ్లిక్ కీని సర్వర్‌కు కాపీ చేయండి

Use ssh-copy-id to easily transfer your public key to your server:.

మీ పబ్లిక్ కీని మీ సర్వర్‌కు సులభంగా బదిలీ చేయడానికి ssh-copy-id ఉపయోగించండి:

ssh-copy-id -i ~/.ssh/id_ed25519.pub your_username@your_server_ip

• You will be asked for your password one last time.

• మీరు చివరిసారిగా మీ పాస్‌వర్డ్ కోసం అడగబడతారు.

C. Test Key-Based Login

C. కీ-ఆధారిత లాగిన్‌ను పరీక్షించండి

Log out and try to log back in using your key:

లాగ్ అవుట్ చేసి, మీ కీని ఉపయోగించి తిరిగి లాగిన్ చేయడానికి ప్రయత్నించండి:

ssh your_username@your_server_ip

• If successful, you should be prompted for your key's passphrase instead of your server password.

• విజయవంతమైతే, మీ సర్వర్ పాస్‌వర్డ్‌కు బదులుగా మీ కీ యొక్క పాస్‌ఫ్రేజ్ కోసం మీరు ప్రాంప్ట్ చేయబడతారు.

3. Step 2: Disable Password Authentication

3. దశ 2: పాస్‌వర్డ్ ప్రమాణీకరణను నిలిపివేయండి

Once you confirm key-based login works, you must disable password logins to close the door on brute-force attackers.

కీ-ఆధారిత లాగిన్ పనిచేస్తుందని మీరు నిర్ధారించిన తర్వాత, బ్రూట్-ఫోర్స్ దాడిదారుల నుండి తలుపు మూసివేయడానికి మీరు పాస్‌వర్డ్ లాగిన్‌లను నిలిపివేయాలి.

A. Edit the SSH Configuration File

Open the SSH daemon configuration file, typically located at /etc/ssh/sshd_config.

సాధారణంగా /etc/ssh/sshd_config వద్ద ఉన్న SSH డెమోన్ కాన్ఫిగరేషన్ ఫైల్‌ను తెరవండి.

sudo nano /etc/ssh/sshd_config

B. Apply Hardening Changes

B. పటిష్టం చేసే మార్పులను వర్తింపజేయండి

Find and modify (or add) the following lines:

కింది పంక్తులను కనుగొని సవరించండి (లేదా జోడించండి):

Your changes should look like this:

మీ మార్పులు ఇలా ఉండాలి:

# /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin no
X11Forwarding no"

C. Restart the SSH Service

C. SSH సర్వీస్‌ను పునఃప్రారంభించండి

Apply the changes by restarting the SSH service:

SSH సర్వీస్‌ను పునఃప్రారంభించడం ద్వారా మార్పులను వర్తింపజేయండి:

On Debian/Ubuntu:

sudo systemctl restart ssh

On CentOS/RHEL:

sudo systemctl restart sshd

4. Step 3: Change the Default SSH Port 🚪

4. దశ 3: డిఫాల్ట్ SSH పోర్ట్‌ను మార్చండి 🚪

Brute-force bots typically target the default SSH port, 22. Changing this to a non-standard, high-numbered port (e.g., 2222, 58491) won't stop a determined attacker, but it will eliminate the vast majority of automated scanning noise.

బ్రూట్-ఫోర్స్ బాట్‌లు సాధారణంగా డిఫాల్ట్ SSH పోర్ట్, 22ని లక్ష్యంగా చేసుకుంటాయి. దీన్ని నాన్-స్టాండర్డ్, అధిక సంఖ్య గల పోర్ట్‌కు (ఉదా. 2222, 58491) మార్చడం వలన నిర్ణీత దాడిదారు ఆగిపోరు, కానీ ఇది ఆటోమేటెడ్ స్కానింగ్ శబ్దంలో ఎక్కువ భాగాన్ని తొలగిస్తుంది.

A. Edit the SSH Configuration File

A. SSH కాన్ఫిగరేషన్ ఫైల్‌ను సవరించండి

Open /etc/ssh/sshd_config again:

/etc/ssh/sshd_configను మళ్లీ తెరవండి:

sudo nano /etc/ssh/sshd_config

B. Change the Port

B. పోర్ట్‌ను మార్చండి

Find the line for Port and change it to a port between 1024 and 65535. For example, we'll use 2222.

Port కోసం పంక్తిని కనుగొని, దానిని 1024 మరియు 65535 మధ్య ఉన్న పోర్ట్‌కు మార్చండి. ఉదాహరణకు, మనం 2222ను ఉపయోగిస్తాము.

# /etc/ssh/sshd_config
Port 2222

C. Open the New Port in the Firewall

C. ఫైర్‌వాల్‌లో కొత్త పోర్ట్‌ను తెరవండి

You must open the new port in your server's firewall before restarting SSH. Otherwise, you will lock yourself out!

మీరు SSHను పునఃప్రారంభించే ముందు మీ సర్వర్ యొక్క ఫైర్‌వాల్‌లో కొత్త పోర్ట్‌ను తప్పక తెరవాలి. లేకపోతే, మీరు లాక్ అవుట్ అవుతారు!

Using UFW (Ubuntu/Debian):

UFW ఉపయోగించి (Ubuntu/Debian):

sudo ufw allow 2222/tcp
sudo ufw delete allow 22/tcp  # Remove old port access

Using firewalld (CentOS/RHEL):

firewalld ఉపయోగించి (CentOS/RHEL):

sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload

D. Restart the SSH Service

D. SSH సర్వీస్‌ను పునఃప్రారంభించండి

sudo systemctl restart ssh

E. Connecting to the New Port

E. కొత్త పోర్ట్‌కు కనెక్ట్ చేయడం

From now on, you'll need to specify the port when connecting:

ఇకపై, మీరు కనెక్ట్ చేస్తున్నప్పుడు పోర్ట్‌ను పేర్కొనాలి:

ssh -p 2222 your_username@your_server_ip

Successfully logged in the server with the customized port (sometimes restart may require)

🔧 4.1 Troubleshooting: SSH Key Authentication Issues

🔧4.1 ట్రబుల్షూటింగ్: ఇతర యంత్రాలలో SSH కీ ప్రమాణీకరణ సమస్యలు

Switching to key-based login is secure, but you might run into connection errors when logging in from a new computer or after copying your key. Here are the most common issues and their fixes.

కీ-ఆధారిత లాగిన్‌కు మారడం సురక్షితం, కానీ కొత్త కంప్యూటర్ నుండి లాగిన్ అయినప్పుడు లేదా మీ కీని కాపీ చేసిన తర్వాత కనెక్షన్ లోపాలను ఎదుర్కొనే అవకాశం ఉంది. ఇక్కడ సాధారణ సమస్యలు మరియు వాటి పరిష్కారాలు ఉన్నాయి.

A. Permission Denied (Public Key)

A. పర్మిషన్ నిరాకరణ (Permission Denied - Public Key)

The most frequent error is "Permission denied (publickey)." This usually means the server either can't find your key or the local machine's permissions are too open.

అత్యంత తరచుగా వచ్చే లోపం "Permission denied (publickey)." దీని అర్థం సర్వర్ మీ కీని కనుగొనలేకపోయింది లేదా స్థానిక యంత్రం యొక్క అనుమతులు చాలా ఓపెన్‌గా ఉన్నాయి

On Your Local Machine (The machine you are connecting from):

మీ స్థానిక యంత్రంలో (మీరు కనెక్ట్ చేస్తున్న యంత్రం):

• సమస్య: మీ ప్రైవేట్ కీ ఫైల్ (id_ed25519 లేదా id_rsa) తప్పు అనుమతులను కలిగి ఉంది. SSHకి చాలా కఠినమైన, సురక్షితమైన అనుమతులు అవసరం.

• పరిష్కారం: మీ ప్రైవేట్ కీని మీరు మాత్రమే చదవగలరని నిర్ధారించుకోండి.

• Issue: Your private key file (id_ed25519 or id_rsa) has incorrect permissions. SSH requires very strict, secure permissions.

• Fix: Ensure only you can read the private key.

    chmod 400 ~/.ssh/id_ed25519
  

On the Server (The machine you are connecting to):

సర్వర్‌లో (మీరు కనెక్ట్ అవుతున్న యంత్రం):

• సమస్య: సర్వర్‌లోని .ssh డైరెక్టరీ లేదా authorized_keys ఫైల్ తప్పు అనుమతులను కలిగి ఉంది.

• పరిష్కారం: సర్వర్‌లోని కీ ఫైల్‌ల కోసం ఈ సురక్షిత అనుమతులను ఉపయోగించండి:

• Issue: The .ssh directory or the authorized_keys file on the server has incorrect permissions.

• Fix: Use these secure permissions for the key files on the server:

    # Secure the .ssh directory
    chmod 700 ~/.ssh
  
    # Secure the authorized_keys file
    chmod 600 ~/.ssh/authorized_keys
  

B. Key Agent Issues (Key Not Found)

B. కీ ఏజెంట్ సమస్యలు (Key Agent Issues - Key Not Found)

If you are using a new local machine or are prompted for a password instead of your key's passphrase, the system might not be aware of your key.

• Issue: Your key is not loaded into the SSH agent, which manages your keys in memory.

• Fix: Manually start the agent and add your key:

మీరు కొత్త స్థానిక యంత్రాన్ని ఉపయోగిస్తున్నట్లయితే లేదా మీ కీ యొక్క పాస్‌ఫ్రేజ్‌కు బదులుగా పాస్‌వర్డ్ కోసం ప్రాంప్ట్ చేయబడినట్లయితే, సిస్టమ్‌కు మీ కీ గురించి తెలియకపోవచ్చు.

• సమస్య: మీ కీ SSH ఏజెంట్‌లో లోడ్ చేయబడలేదు.

• పరిష్కారం: ఏజెంట్‌ను మాన్యువల్‌గా ప్రారంభించి, మీ కీని జోడించండి:

# Start the SSH agent
eval "$(ssh-agent -s)"

# Add your key to the agent
ssh-add ~/.ssh/id_ed25519
# You will be prompted for your key's passphrase here.

If you have multiple keys, try running ssh-add -l to see which keys are loaded.

C. Key Mismatch or Identity Not Specified

C. కీ సరిపోలకపోవడం లేదా గుర్తింపు పేర్కొనబడకపోవడం (Key Mismatch or Identity Not Specified)

Sometimes, the SSH client tries to use the wrong key or doesn't know which key to use for a specific server.

కొన్నిసార్లు, SSH క్లయింట్ తప్పు కీని ఉపయోగించడానికి ప్రయత్నిస్తుంది లేదా నిర్దిష్ట సర్వర్ కోసం ఏ కీని ఉపయోగించాలో తెలియదు.

• Issue: You are not using the default key name (like id_ed25519) or you have multiple keys.

• Fix: Explicitly tell the client which key file to use with the -i flag:

• సమస్య: మీరు డిఫాల్ట్ కీ పేరును (ఉదా. id_ed25519) ఉపయోగించడం లేదు లేదా మీకు బహుళ కీలు ఉన్నాయి.

• పరిష్కారం: ఏ కీ ఫైల్‌ను ఉపయోగించాలో -i ఫ్లాగ్‌తో క్లయింట్‌కు స్పష్టంగా చెప్పండి:

ssh -i ~/.ssh/my_special_server_key -p 2222 your_username@your_server_ip

(గమనిక: మీరు దశ 3ని అనుసరించినట్లయితే, 2222ని మీ కస్టమ్ పోర్ట్‌తో భర్తీ చేయండి.)

(Note: Replace 2222 with your custom port if you followed Step 3.)

5. Step 4: Install and Configure Fail2ban 🤖

5. దశ 4: Fail2banను ఇన్‌స్టాల్ చేసి కాన్ఫిగర్ చేయండి 🤖

Even with key-based authentication, you'll still see bots knocking on your door. Fail2ban is an intrusion prevention software that scans log files (like your SSH logs) for repetitive failed login attempts and dynamically bans the corresponding IP addresses using the firewall.

కీ-ఆధారిత ప్రమాణీకరణతో కూడా, మీ తలుపు తట్టే బాట్‌లను మీరు చూస్తూనే ఉంటారు. Fail2ban అనేది ఒక చొరబాటు నివారణ సాఫ్ట్‌వేర్, ఇది పునరావృతమయ్యే విఫలమైన లాగిన్ ప్రయత్నాల కోసం లాగ్ ఫైల్‌లను (మీ SSH లాగ్‌ల వంటివి) స్కాన్ చేస్తుంది మరియు ఫైర్‌వాల్ ఉపయోగించి సంబంధిత IP చిరునామాలను డైనమిక్‌గా నిషేధిస్తుంది.

A. Installation

A. ఇన్‌స్టాలేషన్

On Debian/Ubuntu:

sudo apt update
sudo apt install fail2ban

On CentOS/RHEL:

sudo yum install fail2ban
sudo systemctl enable fail2ban

B. Basic Configuration

B. ప్రాథమిక కాన్ఫిగరేషన్

Fail2ban uses configuration files called jails. Do not edit the main configuration file (/etc/fail2ban/jail.conf). Instead, create a copy for your local overrides:

Fail2ban జైల్స్ అని పిలువబడే కాన్ఫిగరేషన్ ఫైల్‌లను ఉపయోగిస్తుంది. ప్రధాన కాన్ఫిగరేషన్ ఫైల్ (/etc/fail2ban/jail.conf)ను సవరించవద్దు. బదులుగా, మీ స్థానిక ఓవర్‌రైడ్‌ల కోసం ఒక కాపీని సృష్టించండి:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

C. Modify Jail Settings

C. జైల్ సెట్టింగ్‌లను సవరించండి

Under the [DEFAULT] section, check/modify the following:

[DEFAULT] విభాగం కింద, కింది వాటిని తనిఖీ చేయండి/సవరించండి:

D. Enable the SSH Jail

D. SSH జైల్‌ను ప్రారంభించండి

Find the SSH-specific jail, which is typically called [sshd], and ensure it is enabled.

సాధారణంగా [sshd] అని పిలువబడే SSH-నిర్దిష్ట జైల్‌ను కనుగొని, అది ప్రారంభించబడిందని నిర్ధారించుకోండి.

[sshd]
enabled = true
port    = 2222  # IMPORTANT: Use your custom port!
logpath = %(sshd_log)s
backend = systemd

E. Start and Enable Fail2ban

E. Fail2banను ప్రారంభించి ఎనేబుల్ చేయండి

sudo systemctl start fail2ban
sudo systemctl enable fail2ban
sudo systemctl status fail2ban

To see which IPs are currently banned, use:

ప్రస్తుతం ఏ IPలు నిషేధించబడ్డాయో చూడటానికి, ఉపయోగించండి:

sudo fail2ban-client status sshd

Summary of Hardening Steps

పటిష్టం చేసే దశల సారాంశం

By implementing these four steps, you've created a robust defense:

1. Eliminated the weakest link: Disabled password authentication.

2. Secured the front door: Disabled direct root login.

3. Achieved security through obscurity: Changed the default SSH port.

4. Automated attack defense: Installed and configured Fail2ban.

ఈ నాలుగు దశలను అమలు చేయడం ద్వారా, మీరు బలమైన రక్షణను సృష్టించారు:

1. బలహీనమైన లింక్‌ను తొలగించారు: పాస్‌వర్డ్ ప్రమాణీకరణను నిలిపివేశారు.

2. ముందు తలుపును సురక్షితం చేశారు: డైరెక్ట్ రూట్ లాగిన్‌ను నిలిపివేశారు.

3. గుప్తత ద్వారా భద్రతను సాధించారు: డిఫాల్ట్ SSH పోర్ట్‌ను మార్చారు.

4. ఆటోమేటెడ్ దాడి రక్షణ: Fail2banను ఇన్‌స్టాల్ చేసి కాన్ఫిగర్ చేశారు.

Your Linux server is now significantly hardened against the most common type of attack: the SSH brute-force bot. Stay secure! 🔒

మీ లైనక్స్ సర్వర్ ఇప్పుడు అత్యంత సాధారణ రకం దాడికి: SSH బ్రూట్-ఫోర్స్ బాట్‌కు వ్యతిరేకంగా గణనీయంగా పటిష్టం చేయబడింది. సురక్షితంగా ఉండండి! 🔒

✅ SSH Hardening Checklist

• [x] Change default SSH port

• [x] Disable root login

• [x] Use key-based authentication

• [x] Restrict access by IP

• [x] Install Fail2Ban

• [x] Monitor logs regularly

📣 Conclusion

SSH is powerful but vulnerable if left unprotected. By following these steps, you’ll greatly reduce the risk of brute force attacks and improve your server’s security posture.

Telugu: ఈ చర్యలు తీసుకోవడం ద్వారా మీ Linux సర్వర్‌ను brute force దాడుల నుండి రక్షించవచ్చు. మరిన్ని bilingual tutorials కోసం Y-IT Simplified ని ఫాలో అవ్వండి.

🎥 Watch the Full Video

👉Y-iT Simplified - SSH Hardening Tutorial

🔔 Call-to-Action

💬 Share your questions in the comments.

👍 If you found this useful, follow me here on Blogs.

🎥 Don’t forget to watch the full tutorial on my YouTube channel:

SSH Brute Force Defense: A Step-by-Step Guide to Hardening Your Linux Server

👨‍💻 About the Author

I’m Rajesh Yerravalli, the creator of Yerravalli IT Simplified.

With over 20 years of experience in IT—covering IT Infrastructure, Linux, Windows, Networking, Servers, Cloud, and Cybersecurity—I’m passionate about breaking down complex technical topics into simple, hands-on tutorials.

📺 Watch tutorials on YouTube: Yerravalli IT Simplified (Y-iT Simplified)

✍️ Read more guides here on Hashnode.

Protecting your server isn't difficult—it just requires a few crucial steps. This guide will walk you through the essential techniques to lock down your server and significantly reduce the risk of compromise.

1. Prerequisites

Before we begin, you'll need:

• A Linux server (e.g., Ubuntu, Debian, CentOS, RHEL).

• Root or sudo access to the server.

• Basic familiarity with the Linux command line and text editors like nano or vim.

Section 2: Step 1 (Key-Based Authentication)

2. Step 1: Switch to Key-Based Authentication 🔑

The single most effective defense is to disable password logins entirely and rely on SSH Key Pairs. This makes brute-force attacks virtually impossible, as guessing a key is mathematically infeasible.

A. Generate Your Key Pair (On Your Local Machine)

If you don't already have one, generate an ED25519 key pair. This is more secure and faster than RSA.

ssh-keygen -t ed25519

• You'll be prompted to save the key. The default locations (~/.ssh/id_ed25519 for the private key and ~/.ssh/id_ed25519.pub for the public key) are usually fine.

• Set a strong passphrase for your private key.

B. Copy the Public Key to the Server

Use ssh-copy-id to easily transfer your public key to your server:.

ssh-copy-id -i ~/.ssh/id_ed25519.pub your_username@your_server_ip

• You will be asked for your password one last time.

C. Test Key-Based Login

Log out and try to log back in using your key:

ssh your_username@your_server_ip

• If successful, you should be prompted for your key's passphrase instead of your server password.

3. Step 2: Disable Password Authentication

Once you confirm key-based login works, you must disable password logins to close the door on brute-force attackers.

A. Edit the SSH Configuration File

Open the SSH daemon configuration file, typically located at /etc/ssh/sshd_config.

sudo nano /etc/ssh/sshd_config

B. Apply Hardening Changes

Find and modify (or add) the following lines:

Your changes should look like this:

# /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin no
X11Forwarding no"

C. Restart the SSH Service

Apply the changes by restarting the SSH service:

On Debian/Ubuntu:

sudo systemctl restart ssh

On CentOS/RHEL:

sudo systemctl restart sshd

4. Step 3: Change the Default SSH Port 🚪

Brute-force bots typically target the default SSH port, 22. Changing this to a non-standard, high-numbered port (e.g., 2222, 58491) won't stop a determined attacker, but it will eliminate the vast majority of automated scanning noise.

A. Edit the SSH Configuration File

Open /etc/ssh/sshd_config again:

sudo nano /etc/ssh/sshd_config

B. Change the Port

Find the line for Port and change it to a port between 1024 and 65535. For example, we'll use 2222.

# /etc/ssh/sshd_config
Port 2222

C. Open the New Port in the Firewall

You must open the new port in your server's firewall before restarting SSH. Otherwise, you will lock yourself out!

Using UFW (Ubuntu/Debian):

sudo ufw allow 2222/tcp
sudo ufw delete allow 22/tcp  # Remove old port access

Using firewalld (CentOS/RHEL):

sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload

D. Restart the SSH Service

sudo systemctl restart ssh

E. Connecting to the New Port

From now on, you'll need to specify the port when connecting:

ssh -p 2222 your_username@your_server_ip

Successfully logged in the server with the customized port (sometimes restart may require)

🔧 4.1 Troubleshooting: SSH Key Authentication Issues

Switching to key-based login is secure, but you might run into connection errors when logging in from a new computer or after copying your key. Here are the most common issues and their fixes.

A. Permission Denied (Public Key)

The most frequent error is "Permission denied (publickey)." This usually means the server either can't find your key or the local machine's permissions are too open.

On Your Local Machine (The machine you are connecting from):

• Issue: Your private key file (id_ed25519 or id_rsa) has incorrect permissions. SSH requires very strict, secure permissions.

• Fix: Ensure only you can read the private key.

    chmod 400 ~/.ssh/id_ed25519
  

On the Server (The machine you are connecting to):

• Issue: The .ssh directory or the authorized_keys file on the server has incorrect permissions.

• Fix: Use these secure permissions for the key files on the server:

    # Secure the .ssh directory
    chmod 700 ~/.ssh
  
    # Secure the authorized_keys file
    chmod 600 ~/.ssh/authorized_keys
  

B. Key Agent Issues (Key Not Found)

If you are using a new local machine or are prompted for a password instead of your key's passphrase, the system might not be aware of your key.

• Issue: Your key is not loaded into the SSH agent, which manages your keys in memory.

• Fix: Manually start the agent and add your key:

# Start the SSH agent
eval "$(ssh-agent -s)"

# Add your key to the agent
ssh-add ~/.ssh/id_ed25519
# You will be prompted for your key's passphrase here.

If you have multiple keys, try running ssh-add -l to see which keys are loaded.

C. Key Mismatch or Identity Not Specified

Sometimes, the SSH client tries to use the wrong key or doesn't know which key to use for a specific server.

• Issue: You are not using the default key name (like id_ed25519) or you have multiple keys.

• Fix: Explicitly tell the client which key file to use with the -i flag:

ssh -i ~/.ssh/my_special_server_key -p 2222 your_username@your_server_ip

(Note: Replace 2222 with your custom port if you followed Step 3.)

5. Step 4: Install and Configure Fail2ban 🤖

Even with key-based authentication, you'll still see bots knocking on your door. Fail2ban is an intrusion prevention software that scans log files (like your SSH logs) for repetitive failed login attempts and dynamically bans the corresponding IP addresses using the firewall.

A. Installation

On Debian/Ubuntu:

sudo apt update
sudo apt install fail2ban

On CentOS/RHEL:

sudo yum install fail2ban
sudo systemctl enable fail2ban

B. Basic Configuration

Fail2ban uses configuration files called jails. Do not edit the main configuration file (/etc/fail2ban/jail.conf). Instead, create a copy for your local overrides:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

C. Modify Jail Settings

Under the [DEFAULT] section, check/modify the following:

D. Enable the SSH Jail

Find the SSH-specific jail, which is typically called [sshd], and ensure it is enabled.

[sshd]
enabled = true
port    = 2222  # IMPORTANT: Use your custom port!
logpath = %(sshd_log)s
backend = systemd

E. Start and Enable Fail2ban

sudo systemctl start fail2ban
sudo systemctl enable fail2ban
sudo systemctl status fail2ban

To see which IPs are currently banned, use:

sudo fail2ban-client status sshd

Summary of Hardening Steps

By implementing these four steps, you've created a robust defense:

1. Eliminated the weakest link: Disabled password authentication.

2. Secured the front door: Disabled direct root login.

3. Achieved security through obscurity: Changed the default SSH port.

4. Automated attack defense: Installed and configured Fail2ban.

Your Linux server is now significantly hardened against the most common type of attack: the SSH brute-force bot. Stay secure! 🔒

✅ SSH Hardening Checklist

• [x] Use key-based authentication

• [x] Disable root login

• [x] Disable PasswordAuthentication

• [x] Change default SSH port

• [x] Restrict access by IP

• [x] Install Fail2Ban

• [x] Complexity Passwdqc

• [x] Monitor logs regularly

📣 Conclusion

SSH is powerful but vulnerable if left unprotected. By following these steps, you’ll greatly reduce the risk of brute force attacks and improve your server’s security posture.

🎥 Watch the Full Video

👉Y-iT Simplified - SSH Hardening Tutorial

🔔 Call-to-Action

💬 Share your questions in the comments.

👍 If you found this useful, follow me here on Blogs.

🎥 Don’t forget to watch the full tutorial on my YouTube channel:

SSH Brute Force Defense: A Step-by-Step Guide to Hardening Your Linux Server

👨‍💻 About the Author

I’m Rajesh Yerravalli, the creator of Yerravalli IT Simplified.

With over 20 years of experience in IT—covering IT Infrastructure, Linux, Windows, Networking, Servers, Cloud, and Cybersecurity—I’m passionate about breaking down complex technical topics into simple, hands-on tutorials.

📺 Watch tutorials on YouTube: Yerravalli IT Simplified (Y-iT Simplified)

✍️ Read more guides here on Hashnode.

Cybersecurity isn’t just for big corporations. Small businesses are increasingly targeted by attackers—often because they’re easier to breach. Let’s explore five common mistakes how to fix them, step by step.

1. 🔐 Weak Passwords

Mistake: Using simple or repeated passwords like “admin123”.

Fix:

• Use strong passwords with symbols and numbers: Use strong passwords with symbols, numbers, and mixed-case letters to make them harder to guess. Avoid common words or patterns—random combinations are your best defense.

• Enable Multi-Factor Authentication (MFA): Enable Multi-Factor Authentication (MFA) to add an extra layer of protection beyond passwords. Even if credentials are stolen, MFA helps block unauthorized access by requiring a second verification step.

• Use password managers: Use password managers to securely store and generate complex passwords for all your accounts. They reduce the risk of reuse and make it easier to follow strong password practices without memorizing everything.

2. 🧩 Unpatched Systems

Mistake: Ignoring software updates.

Fix:

• Enable auto-updates: Enable auto-updates to ensure your systems receive the latest security patches without delay. This reduces manual effort and protects against newly discovered vulnerabilities before attackers can exploit them.

• Maintain a patch schedule: Maintain a patch schedule to regularly update all systems, applications, and devices. A consistent routine ensures no critical updates are missed and helps reduce exposure to known vulnerabilities.

• Stable versions: Maintain stable versions of operating systems and software to reduce compatibility issues and unexpected bugs. Avoid using beta or unsupported releases in production environments unless thoroughly tested.

3. 🔥 Poor Firewall Configuration

Mistake: Leaving default settings or open ports.

Fix:

• Regular port scan: Perform regular port scans to identify open or vulnerable ports that attackers could exploit. This helps ensure your firewall and network configurations remain secure and aligned with best practices.

• Default deny policy: Apply a default deny policy to block all traffic by default and only allow what’s explicitly needed. This minimizes exposure by ensuring unauthorized access is automatically rejected unless specifically permitted.

• Review firewall rules: Review firewall rules regularly to ensure only necessary traffic is allowed and outdated permissions are removed. This helps maintain a secure perimeter and prevents accidental exposure of internal systems.

  ---

4. 🚨 No Incident Response Plan

Mistake: No plan for cyberattacks.

Fix:

• Create a simple response playbook: Create a simple response playbook that outlines what to do during a cyber incident—step by step. It should include key contacts, escalation paths, and immediate actions to contain and recover from threats.

• Assign roles and escalation paths: Assign clear roles and escalation paths so every team member knows their responsibility during a cyber incident. This ensures faster decision-making, reduces confusion, and helps contain threats efficiently

• Conduct mock drills: Conduct mock drills to simulate cyber incidents and test your team’s readiness. These practice runs help identify gaps in your response plan and build confidence in handling real threats.

5. 🧠 Lack of Security Awareness

Mistake: Employees unaware of phishing or cyber hygiene.

Fix:

• Share real-world examples: Share real-world examples of cyberattacks and conduct phishing simulations to help employees recognize threats. Practical exposure builds awareness and prepares your team to respond confidently to suspicious emails or links.

• Conduct awareness training: Conduct awareness training to educate employees about common cyber threats like phishing, malware, and social engineering. Regular sessions help build a security-first mindset and reduce the risk of human error.

• Encourage open reporting: Encourage or reward open reporting of suspicious activity to build a culture of transparency and vigilance. Recognizing employees who speak up—whether through praise or small incentives—helps surface threats early and fosters team-wide accountability.

💡 Final Thoughts

Cybersecurity is not optional—it’s essential for every business, big or small. Fixing these common mistakes strengthens your defenses, builds customer trust, and ensures long-term resilience against evolving threats.

👉 Visit Yerravalli IT Simplified for tutorials, consulting, and more.

🔗 What’s Next?

SSH Brute Force Defense: Ubuntu Server Management and Security Hardening

🔔 Call-to-Action

💬 Share your questions in the comments.

👍 If you found this useful, follow me here on Blog.

🎥 Don’t forget to watch the full tutorial on my YouTube channel:

Top 5 Security Mistakes Small Businesses Make—and How to Fix Them

👨‍💻 About the Author

I’m Rajesh Kumar Yerravalli, the creator of Yerravalli IT Simplified.

With over 20 years of experience in IT—covering Linux, Windows, Networking, Servers, Cloud, and Cybersecurity—I’m passionate about breaking down complex technical topics into simple, hands-on tutorials.

📺 Watch tutorials on YouTube: Yerravalli IT Simplified

This guide continues from the Ubuntu Server installation. You’ll install and enable OpenSSH, configure VirtualBox networking modes (NAT, Bridged, Host-Only, Internal), optionally set up port forwarding, and assign a static IP on Ubuntu using Netplan so you can reliably SSH into the VM.

👉 If you haven’t installed Ubuntu Server yet, start here: How to Install Ubuntu Server on VirtualBox
👉 Next tutorial in the series: Ubuntu Server Management and Security Hardening

What you’ll need (Prerequisites)

• VirtualBox installed on your host (Windows / macOS / Linux).

• An Ubuntu Server VM already installed (recap video or installation guide).

• Basic comfort with the terminal (copy/paste commands provided).

• Optional: Administrator/owner access to the host machine (for VirtualBox settings).

Quick overview of VirtualBox network modes (one-liner)

• NAT: Easiest — VM can access the internet. Host cannot connect to VM directly unless you add port forwarding.

• NAT Network: Multiple VMs can talk to each other and reach the internet; host cannot access VMs unless you configure port forwarding.

• Bridged: VM is on the same LAN as your host — good for servers that need direct LAN access.

• Host-Only: Host and VMs can reach each other — great for lab networks but no internet (unless you add another adapter).

• Internal: VMs only communicate among themselves (isolated).

Step by step

1) Recap — confirm your VM is running

Start VirtualBox and power on your Ubuntu Server VM.

2) Install & enable OpenSSH on Ubuntu

Open a terminal in the VM (or use the VirtualBox console).

# update packages
sudo apt update

# install OpenSSH server
sudo apt install -y openssh-server

# enable and start ssh service
sudo systemctl enable --now ssh

# check status
sudo systemctl status ssh --no-pager

You should see active (running).

Tip: If sshd is not installed (very rare on server images), sudo apt install openssh-server fixes it.

3) Confirm the VM’s network interface name & IP (always do this first)

Find the interface name and IP assigned to the VM:

ip a      # lists network interfaces and addresses

Look for an interface like enp0s3, ensXXX, or eth0. Note the inet address (e.g., 10.0.2.15 or 192.168.56.101).

4) How to connect by SSH (depending on network mode)

If using Bridged mode

The VM gets an IP from your LAN DHCP (same subnet as host). Connect from host:

ssh <username>@<vm-ip>
# e.g.
ssh rajesh@192.168.1.45

If using Host-Only mode

Host and VM are on a private host-only subnet (commonly 192.168.56.x). Use the

host-only IP:

ssh <username>@192.168.56.101

If using NAT mode (default)

VM can reach the internet but host cannot directly reach guest unless you add port forwarding.

• Power off VM.

• VirtualBox → Select VM → Settings → Network → Adapter 1 → Advanced → Port Forwarding.

• Add a rule: Host IP 127.0.0.1, Host Port 2222, Guest IP (leave empty or put guest IP), Guest Port 22.

• Start VM. Connect from host:

ssh -p 2222 <username>@127.0.0.1
# e.g.
ssh -p 2222 rajesh@127.0.0.1

• Option B — Port forwarding (VBoxManage CLI):

• From the host terminal (replace "UbuntuVM" with your VM name):

    VBoxManage modifyvm "UbuntuVM" --natpf1 "guestssh,tcp,,2222,,22"
  

• Then use ssh -p 2222 user@127.0.0.1 to connect.

  If using NAT Network

  Similar to NAT — you can configure port forwarding for the NAT Network or use other networking (host-only) to allow host access. By default, host cannot access VMs on NAT Network without forwarding.

5) (Optional) Set a static IP on Ubuntu (Netplan) — e.g., for Host-Only or Bridged static IPs

If you want the VM to always have the same IP (recommended for servers), configure netplan.

1. Find the interface name: ip a (e.g., enp0s3).

2. Create or edit /etc/netplan/01-netcfg.yaml (filename may differ):

# Example: static IP for Host-Only network (replace interface and addresses)
network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s3:
      dhcp4: no
      addresses: [192.168.56.101/24]
      gateway4: 192.168.56.1
      nameservers:
        addresses: [8.8.8.8,8.8.4.4]

3. Apply the config:

sudo netplan try      # test the config
# or
sudo netplan apply

4. Verify: ip a and ping 8.8.8.8.

Important: Replace enp0s3 with the interface name from ip a. Use correct gateway for your network (Host-Only default gateway often 192.168.56.1 in VirtualBox).

6) Make sure firewall allows SSH (UFW example)

If ufw is active, allow SSH:

# allow default OpenSSH profile
sudo ufw allow OpenSSH

# if you used host-side port-forward 2222:
sudo ufw allow 2222/tcp

# enable and check
sudo ufw enable
sudo ufw status

7) Verify connectivity from host

• Ping the VM IP: ping <vm-ip>

• SSH test: ssh user@<vm-ip> or ssh -p 2222 user@127.0.0.1.

• Use netcat to test port: nc -vz <vm-ip> 22 (or 127.0.0.1 2222).

8) Useful VirtualBox GUI checks & tips

• Cable connected: In VM → Settings → Network → ensure “Cable connected” checkbox is ON.

• Adapter type: Usually leave as Intel PRO/1000 (Default).

• Two adapters: You can add two adapters — e.g., Adapter 1 NAT (internet) + Adapter 2 Host-Only (host access). This gives VM internet + stable host access.

• Create NAT Network: If you want VM-to-VM comms with NAT (NAT Network), use VirtualBox global settings → Network → NAT Networks → Add and configure.

9) Example lab setups & recommended use

• Quick internet access, minimal fuss: Use NAT. Use port forwarding to SSH from host.

• Server accessible on your LAN (others can reach it): Use Bridged. Good for test servers or services to be accessed by other machines on the LAN.

• Isolated lab where host must access VMs: Use Host-Only (or Host-Only + NAT for internet).

• Fully isolated multi-VM testing: Internal Network.

Common troubleshooting checklist

• SSH says Connection refused → Ensure sshd is installed & running: sudo systemctl status ssh.

• SSH times out → Check firewall (ufw status) or VirtualBox port forwarding.

• Wrong IP → Re-run ip a inside VM.

• Port forwarding not working → VM must be powered off to change some NAT settings (use GUI or VBoxManage), and make sure host port is free.

• Netplan config fails → Run sudo netplan try to rollback if something breaks. Use ip a to confirm interface names.

✅ Wrapping Up

In this tutorial, we configured SSH access and set up networking in VirtualBox for Ubuntu Server. With this setup, you can now connect to your VM remotely and experiment with different networking modes (NAT, Bridged, Host-Only, etc.) just like in a real-world environment.

👉 If you missed the installation steps, check out the first part of this series:
How to Install Ubuntu Server on VirtualBox (Step by Step)

✅ Wrapping Up

In this tutorial, we configured SSH access and set up networking in Ubuntu Server on VirtualBox. With this setup, you can now connect remotely and experiment with different VirtualBox network modes just like in real-world environments.

🔗 What’s Next?

Now that your VM can be accessed via SSH, the next step is to explore Ubuntu Server management and security hardening.

👉 If you missed the installation tutorial, start here:

How to Install Ubuntu Server on VirtualBox

👉 Continue to the next tutorial:

Ubuntu Server Management and Security Hardening

🔔 Call-to-Action

💬 Share your questions in the comments.

👍 If you found this useful, follow me here on Blog.

🎥 Don’t forget to watch the full tutorial on my YouTube channel:

How to Configure SSH and Networking in Ubuntu Server on VirtualBox

👨‍💻 About the Author

I’m Rajesh Kumar, the creator of Yerravalli IT Simplified.

With over 20 years of experience in IT—covering Linux, Windows, Networking, Servers, Cloud, and Cybersecurity—I’m passionate about breaking down complex technical topics into simple, hands-on tutorials.

📺 Watch tutorials on YouTube: Yerravalli IT Simplified

📚 Ubuntu Server on VirtualBox Series

1️⃣ How to Install Ubuntu Server on VirtualBox

2️⃣ How to Configure SSH and Networking in Ubuntu Server on VirtualBox

3️⃣ SSH Brute Force: Ubuntu Server Management and Security Hardening

Stay tuned — new parts will be added here as the series continues! 🚀

This guide continues from the Ubuntu Server install. You’ll install and enable OpenSSH, pick and configure the right VirtualBox network mode (NAT, NAT Network, Bridged, Host-Only, Internal), optionally create port-forwarding (for NAT), and set a static IP on Ubuntu with Netplan so you can reliably SSH into the VM.

What you’ll need (Prerequisites)

• Oracle VirtualBox installed (Windows, macOS, or Linux).

• Ubuntu Server ISO (download from official Ubuntu site).

• At least 2 GB RAM and 20 GB free disk space on your host system.

Step 1: Download Ubuntu Server ISO

1. Go to Ubuntu Downloads

2. Download the latest Ubuntu Server LTS ISO (e.g., 24.04 LTS).

3. Save it on your host machine.

Step 2: Create a new Virtual Machine in VirtualBox

1. Open VirtualBox → Click New.

2. Name: UbuntuServer

3. Type: Linux | Version: Ubuntu (64-bit)

4. Allocate Memory: 2048 MB or higher.

5. Create a Virtual Hard Disk: 20 GB VDI (dynamically allocated)

Step 3: Attach the Ubuntu ISO

1. Select the new VM → Settings → Storage.

2. Under “Controller: IDE”, add the Ubuntu Server ISO as a virtual CD/DVD.

3. Save and close settings.

4. Skip unattended installation

Step 4: Configure VM Settings (Optional but recommended)

• Processors: Assign 2 CPUs if your host supports it.

• Network: Start with NAT (easiest for internet access).

• Display: Enable VMSVGA and 16 MB VRAM.

Step 5: Start the VM and begin installation

1. Start the VM.

2. Ubuntu installer will boot.

3. Follow the steps:

   • Choose Language & Keyboard Layout.

   • Configure network (auto via DHCP is fine for now).

   • Set hostname (e.g., ubuntu-vm).

   • Create user account & password.

   • Select disk → Use entire disk → Install.

   • Wait for installation to finish.

Step 6: First boot and login

1. Remove the ISO (Settings → Storage → remove ISO).

2. Reboot VM.

3. Login with your new username and password.

   

4. Verify internet:

    ping google.com -c 3
   

Step 7: Install updates

sudo apt update && sudo apt upgrade -y

This ensures your server is secure and up to date.

Troubleshooting Tips

• No 64-bit option in VirtualBox: Enable virtualization (VT-x/AMD-V) in BIOS.

• Installer stuck on network: Switch VM adapter to NAT or Bridged.

• No boot after install: Ensure hard disk is set as the first boot device.

✅ Wrapping Up

In this tutorial, we set up the Ubuntu Server installation on VirtualBox. With this setup, you can now experiment with different OS versions and modes, just like in real-world environments.

🔗 What’s Next?

Now that your VM can be accessed via SSH, the next step is to explore Ubuntu Server management and security hardening.

👉 Continue to the next tutorial:

How to Configure SSH and Networking in Ubuntu Server on VirtualBox

🔔 Call-to-Action

💬 Share your questions in the comments.

👍 If you found this useful, follow me here on Blog.

🎥 Don’t forget to watch the full tutorial on my YouTube channel:

How to Install Ubuntu Server on VirtualBox

👨‍💻 About the Author

I’m Rajesh Kumar, the creator of Yerravalli IT Simplified.

With over 20 years of experience in IT—covering Linux, Windows, Networking, Servers, Cloud, and Cybersecurity—I’m passionate about breaking down complex technical topics into simple, hands-on tutorials.

📺 Watch tutorials on YouTube: Yerravalli IT Simplified

📚 Ubuntu Server on VirtualBox Series

1️⃣ How to Install Ubuntu Server on VirtualBox

2️⃣ How to Configure SSH and Networking in Ubuntu Server on VirtualBox

3️⃣ SSH Brute Force: Ubuntu Server Management and Security Hardening

Stay tuned — new parts will be added here as the series continues! 🚀