Networking, SSH, Scheduling & Logs

What is it?

Networking config gives the box an address and routes; SSH is secure remote administration; cron/systemd-timers schedule jobs; logs (/var/log, journald) record what happened.

Why it matters

A server is only useful if reachable, remotely manageable, doing its scheduled work, and telling you what it did — these four make it operable.

Where you see it

`ip a` shows addresses, `ss -tlnp` shows listening services, `ssh user@host` connects, `crontab -l` lists jobs, `journalctl` reads logs.

What normal looks like

The expected IP and gateway, only intended services listening, SSH on its port, scheduled jobs succeeding and logging cleanly.

What suspicious looks like

No route to the gateway, an unexpected service listening on 0.0.0.0, a cron job failing every run, or logs showing repeated errors — each a concrete lead.

How analysts investigate

Work bottom-up for connectivity (ip a → ping gateway → DNS → service), read ss for what listens, and always confirm a scheduled job by its log, not by assuming it ran.

Common beginner mistakes

Assuming a cron job ran without checking its output/log.
Exposing SSH or a service to 0.0.0.0 when localhost/an internal range would do.

Reachable, managed, scheduled, logged

  ss -tlnp   (what is listening)
    LISTEN 0.0.0.0:22    sshd      ← remote admin (harden this)
    LISTEN 0.0.0.0:5432  postgres  ← DB exposed to ALL interfaces? investigate
    LISTEN 127.0.0.1:6379 redis    ← localhost only (good)
  crontab -l → 0 2 * * * /opt/backup.sh   (confirm success in its log)

ss reveals what listens and where; confirm scheduled jobs by their logs, not assumption.

Quick check

ss shows postgres listening on 0.0.0.0:5432. Why investigate?

A quick self-check — it doesn't affect your XP or progress.