Skip to content
VDS · নিরাপত্তা

মেশিনে কে লগইন করেছে: লগইন লগ

সফল ও ব্যর্থ লগইন কোথায় দেখবেন, last, lastb এবং journalctl কীভাবে পড়বেন, sudo দিয়ে কাজ ট্র্যাক করবেন এবং লগ সংরক্ষণ কীভাবে কনফিগার করবেন।

আপডেট: ২৩ আগস্ট, ২০২৬

মেশিনে প্রতিটি লগইনই কিছু চিহ্ন রেখে যায়। সেই চিহ্নগুলো পাঁচ মিনিটে পড়তে পারাই শান্ত মাথায় ইনসিডেন্ট রিভিউ আর আন্দাজের মধ্যে পার্থক্য গড়ে দেয়।

দ্রুত ওভারভিউ

last -a -n 20
lastb -a -n 20
lastlog
who
w

last সফল লগইনগুলো অ্যাড্রেসসহ দেখায়, lastb — ব্যর্থ চেষ্টাগুলো, lastlog — কোন ইউজার সর্বশেষ কখন লগইন করেছিল। who এবং w দেখায় এখন কে মেশিনে আছে।

যদি lastlog-এ www-data-র মতো কোনো সিস্টেম ইউজারের লগইন তারিখ দেখেন, তাহলে এটি তদন্তের গুরুতর কারণ।

systemd journal

journalctl -u ssh -n 100
journalctl -u ssh --since "2026-08-20" --until "2026-08-21"
journalctl _COMM=sshd | grep "Accepted"
journalctl _COMM=sshd | grep "Failed password" | tail -50

গুরুত্বপূর্ণ লাইনগুলো:

লাইনঅর্থ
Accepted publickey for artemকী দিয়ে সফল লগইন
Accepted password for rootপাসওয়ার্ড দিয়ে সফল লগইন — উদ্বেগের কারণ
Failed password for invalid user adminঅস্তিত্বহীন নামে ব্রুট-ফোর্স, ব্যাকগ্রাউন্ড নয়েজ
Disconnected from authenticating userচেষ্টা বাতিল হয়েছে

Debian এবং Ubuntu-তে একই ইভেন্টগুলো /var/log/auth.log-এ ডুপ্লিকেট থাকে; AlmaLinux-এ /var/log/secure-এ।

grep "Accepted" /var/log/auth.log
grep -c "Failed password" /var/log/auth.log

পাবলিক অ্যাড্রেসে দিনে শত শত ব্যর্থ চেষ্টা স্বাভাবিক। অস্বাভাবিক হলো অন্য কিছু: আপনার চেনা নয় এমন কোনো অ্যাড্রেস থেকে সফল লগইন। নয়েজের বিরুদ্ধে fail2ban সাহায্য করে।

লগইনের পর কী করা হয়েছিল

journalctl -t sudo -n 100
grep sudo /var/log/auth.log
cat /home/artem/.bash_history

কমান্ড হিস্টোরি নির্ভরযোগ্য নয়: এটি সহজেই মুছে ফেলা যায়, আর নন-ইন্টারঅ্যাকটিভ সেশনে এটি রেকর্ড হয় না। sudo লগ অনেক বেশি সৎ — এটি শেল নয়, সিস্টেমই রক্ষণাবেক্ষণ করে। ইউজার এবং sudo আর্টিকেলে বর্ণিত "নিয়মিত ইউজার প্লাস sudo" স্কিমের পক্ষে এটি আরেকটি যুক্তি।

কর্নেল-লেভেলের সম্পূর্ণ অডিটিং:

apt install -y auditd
auditctl -w /etc/passwd -p wa -k passwd_changes
ausearch -k passwd_changes

স্টোরেজ

ডিফল্টভাবে systemd journal মেমরিতে থাকতে পারে এবং রিবুটে হারিয়ে যেতে পারে। ইনসিডেন্ট রিভিউয়ের জন্য এটি খারাপ। ফাইলটি /etc/systemd/journald.conf:

[Journal]
Storage=persistent
SystemMaxUse=500M
MaxRetentionSec=1month
systemctl restart systemd-journald
journalctl --disk-usage

সাইজ লিমিট বাধ্যতামূলক: ডিস্ক খেয়ে ফেলা journal সার্ভিসগুলো বন্ধ করে দেয়।

সাধারণ ভুল

ভুলপরিণতিসমাধান
রিবুটের মধ্যে journal সেভ হয় নাচিহ্ন হারিয়ে যায়Storage=persistent
শুধু .bash_history-র উপর নির্ভর করাডেটা সহজেই জাল করা যায়sudo এবং auditd লগ চেক করুন
journal-এর সাইজ লিমিট করেননিডিস্ক ভরে গেছেSystemMaxUse
ব্রুট-ফোর্স নয়েজকে হ্যাক ভাবাভুয়া অ্যালার্মFailed নয়, Accepted দেখুন

যদি অন্য কারও অ্যাড্রেস থেকে সফল লগইন পান, তাহলে মেশিনের নিজের লগ আর নির্ভরযোগ্য বলা যায় না: যে লগইন করেছে সে সেগুলো এডিট করে থাকতে পারে। আপসঙের লক্ষণ আর্টিকেল অনুসরণ করুন এবং ধরে নিন মেশিনটি পুনরায় ইনস্টল করতে হবে।