Week 3-4: Learning Networking, SSH, Logs, and Bash Security with Cron Automation

What actually went down this week

Weeks 3 and 4 were about connecting the dots: networking, remote access, monitoring, security, and automation.
This was my first "mini sysadmin" sprint — not just running commands in isolation but:

• Mapping IPs, subnets, and ports on AWS EC2

• Hardening and using SSH for remote management

• Filtering logs with journalctl, grep, and tail -f

• Configuring firewalls with UFW & firewalld

• Writing Bash scripts and automating them with cron
  The best part: I built a daily backup + log analysis pipeline that runs automatically on my EC2 instance.

---

Why I had to tackle these topics now

Everything in Cloud & DevOps depends on these skills:

• Networking directly maps to AWS VPCs, subnets, and security groups.

• SSH is the default way to interact with remote Linux servers.

• Logs and monitoring are essential when things break (and they do!).

• Security (firewalls, ports) is non-negotiable before anything is public.

• Bash + cron = the simplest automation, which is basically the DevOps mantra. Without these, I’d just be copy-pasting commands blindly. Now I can actually explain what’s happening.

---

The topics I finished (short notes + useful commands)

14 — Networking Basics

Key ideas: OSI/TCP-IP models, IPs, subnets, ports, DNS, routes
Commands:

ip a                        # show IPs & interfaces
ping 8.8.8.8                # test connectivity
ip route show               # check routing table
ss -tuln | grep 80          # confirm nginx on port 80
dig google.com              # DNS resolution
traceroute google.com
curl -v http://<IP>         # TCP handshake + HTTP response

Takeaway: Networking = the backbone of cloud. Seeing my EC2’s nginx page load in a browser just clicked.

---

15 — SSH & Remote Management

SSH: lifeline for cloud servers.
What I practiced:

• Generated keys: ssh-keygen -t rsa -b 4096

• Disabled root login + password auth in /etc/ssh/sshd_config

• Restarted service: sudo systemctl restart ssh

• Tried port forwarding: ssh -L 8080:localhost:80 user@remote

• Used scp for secure file transfers

  Takeaway: Passwords are weak, keys are king. Hardening SSH is essential.

---

16 — Logs & Monitoring

Logs are your eyes when you can’t see.
Commands I used:

ls -l /var/log/             # explore log files
grep sshd /var/log/auth.log # filter SSH logs
journalctl -xe              # recent errors
journalctl -u ssh -f        # live logs for SSH
tail -f /var/log/syslog     # follow system logs
htop                        # real-time process monitor
df -h                       # disk usage

Custom log:

logger "Test log – $(date)"

---

17 — Security Basics (Firewall & Ports)

Firewalls = first defense.
UFW basics:

sudo ufw status verbose
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw deny 23/tcp

firewalld (CentOS):

sudo firewall-cmd --list-all
sudo firewall-cmd --add-port=8080/tcp --permanent
sudo firewall-cmd --reload

Testing:

nc -zv localhost 22   # check allowed
nc -zv localhost 23   # check blocked

Takeaway: Always allow SSH before enabling a firewall, or you’ll lock yourself out.

---

Bash + Cron Mini Project

First automation pipeline for daily operation.

• backup.sh → creates a timestamped tarball of a folder

• parse_logs.sh → scans logs for “error” or “warn”

• orchestrator.sh → runs both scripts Scheduled with cron:

@daily /home/ubuntu/scripting/scripts/orchestrator.sh >> /home/ubuntu/scripting/orchestrator.log 2>&1

Outcome: Every day, my EC2 makes a backup + log report automatically.

Takeaway: Cron runs in a minimal environment. Always use absolute paths.

---

The things that broke (and how I fixed them)

• Cron jobs failing silently → used /usr/bin/tar instead of just tar, redirected output to logs.

• Locked myself out with firewall → had to reset rules via AWS console.

• SSH “permissions too open” → fixed with chmod 600 ~/.ssh/id_rsa.

---

What I learned the hard way

• Networking is real when your EC2 doesn’t respond.

• Strict SSH config hygiene is a must (bad habits = security risk).

• Logs are noisy, but grep is your friend.

• Firewalls need a “whitelist first” mindset.

• Cron is simple but unforgiving — scripts must be production-ready and use full paths.

---

Resources I actually used

Linux Journey
Linux Handbook
GeeksForGeeks
Linux Upskill Challenge
TrainWithShubham (Youtube)

My own notes & cheatsheets:
GitHub Repo – Cloud & DevOps Journey

---

Up Next: Week 5 Plan

• Understand the concept of Cloud Computing

• Get Hands-on experience with AWS EC2, S3

• Setup IAM users, groups and control privileges

• Monitoring and automation with CloudWatch and Boto3 scripts

• Deeper dive into AWS networking, VPCs and subnetting

---

Follow along

GitHub: shauryad01/cloud-devops-journey
LinkedIn: Shaurya Dhingra