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