วิธีบันทึกเซสชันเทอร์มินัลทั้งหมดโดยอัตโนมัติด้วยยูทิลิตี้สคริปต์


28

สิ่งที่ฉันต้องการบรรลุคือสามารถบันทึกเซสชันเทอร์มินัลของฉันให้เป็นไฟล์โดยอัตโนมัติเมื่อใดก็ตามที่ฉันใช้ Yakuake / Konsole

เป็นเรื่องง่ายที่จะประสบความสำเร็จหากเริ่มเซสชันของฉัน:

script -f /home/$USER/bin/shell_logs/$(date +"%d-%b-%y_%H-%M-%S")_shell.log

แต่ฉันต้องการเรียกใช้ข้างต้นโดยอัตโนมัติเมื่อใดก็ตามที่ฉันเริ่ม Yakuake หรือเปิดแท็บใหม่

การใช้. bashrc ไม่ทำงานเนื่องจากสร้างลูปไม่สิ้นสุดเนื่องจาก 'สคริปต์' เปิดเซสชันใหม่ซึ่งจะอ่าน. bashrc และเริ่มต้นอีก 'สคริปต์' และอื่น ๆ

ดังนั้นฉันจึงต้องเขียนสคริปต์ Yakuake / Konsole เพื่อเรียกใช้ 'สคริปต์' ครั้งหนึ่งเมื่อเปิดแท็บใหม่ คำถามคืออย่างไร


ลองวิธีแก้ปัญหาด้วยปัญหาลูป แต่เติมexecที่จุดเริ่มต้นของบรรทัด มันควรเริ่มต้นscript -fในเชลล์ PID เดียวกัน
Hanan N.

คำถามที่น่าสนใจอีกอย่างที่น่าสนใจของรุ่นนี้คือวิธีการบังคับให้ผู้ใช้ที่ไม่ใช่วงล้อเพื่อเขียนสคริปต์การประชุมทั้งหมดของพวกเขาเช่นกัน ...
Yordan Georgiev

คำตอบ:


26

หากมีคนต้องการบันทึกเซสชันเทอร์มินัลโดยอัตโนมัติรวมถึงเซสชัน SSH (!) ด้วยการใช้scriptยูทิลิตี้นี่คือวิธี

เพิ่มบรรทัดต่อไปนี้ที่ส่วนท้ายของ.bashrcไดเรกทอรีหลักของคุณหรือ/etc/bash.bashrcถ้าคุณต้องการบันทึกเซสชันของผู้ใช้ทั้งหมดเท่านั้น เราจะทดสอบสำหรับการปกครองของเปลือกไม่ได้และเรียกใช้แล้วscriptscript

สำหรับ Linux:

test "$(ps -ocommand= -p $PPID | awk '{print $1}')" == 'script' || (script -f $HOME/$(date +"%d-%b-%y_%H-%M-%S")_shell.log)

สำหรับ BSD และ macOS เปลี่ยนscript -fเป็นscript -F:

test "$(ps -ocommand= -p $PPID | awk '{print $1}')" == 'script' || (script -F $HOME/$(date +"%d-%b-%y_%H-%M-%S")_shell.log)

นั่นคือทั้งหมด!

ตอนนี้เมื่อคุณเปิดเทอร์มินัลใหม่คุณจะเห็น:

Script started, file is /home/username/file_name.log

scriptจะเขียนเซสชันของคุณไปยังไฟล์ในโฮมไดเร็กตอรี่ของคุณตั้งชื่อให้บางอย่าง30-Nov-11_00-11-12_shell.logที่เป็นผลลัพธ์

การปรับแต่งเพิ่มเติม:

  • คุณสามารถผนวกเซสชันของคุณเข้ากับไฟล์ขนาดใหญ่หนึ่งไฟล์แทนที่จะสร้างไฟล์ใหม่สำหรับทุกเซสชันด้วย script -a /path/to/single_log_file
  • คุณสามารถปรับตำแหน่งที่จะเขียนไฟล์โดยเปลี่ยนเส้นทางหลังจากscript -f(Linux) หรือscript -F(BSD และ macOS)

คำตอบนี้จะถือว่าคุณได้scriptติดตั้งแน่นอน บนการแจกแจงแบบเดเบียนscriptเป็นส่วนหนึ่งของbsdutilsแพ็คเกจ


คุณสามารถแก้ไขคำถามและชื่อของมันเอง เพียงคลิกที่editปุ่มที่ปรากฏด้านล่าง
Mat

8
คุณอาจต้องการพิจารณาการเพิ่ม${RANDOM}และ / หรือ$$ชื่อไฟล์ตั้งแต่เริ่มต้นสองเชลล์ภายในหนึ่งวินาทีของแต่ละอื่น ๆ จะทำให้เกิดการชนกันของชื่อไฟล์ โดยส่วนตัวแล้วฉันมักจะใช้script.$(date -u +%Y%m%dt%H%M%S).${HOSTNAME:-$(hostname)}.$$.${RANDOM}.logเพื่อให้แน่ใจว่าไฟล์จะถูกจัดเรียงตามวันที่ / เวลาโดยอัตโนมัติและสอดคล้องกับ TZ ฉันรู้ว่าโฮสต์ที่เริ่มต้นฉันรู้ว่าเป็นเจ้าของกระบวนการและไม่มีการชนกันของชื่อ ฉันไม่ค่อยได้ใช้${USER}เพราะปกติแล้วมันจะเป็นของฉัน
nicerobot

"ตรวจสอบให้แน่ใจว่าคุณได้สร้าง / var / log / script และทำให้ผู้อื่นสามารถเขียนได้" ที่คุณเขียน ฉันสงสัยว่าจะแนะนำจากมุมมองด้านความปลอดภัยเพื่อใช้ "sudo chmod 777 / var / log / script" ในกรณีนี้
Teo

10

ถึงแม้ว่าคำถามนี้ถูกถามโดยบุคคลที่ต้องการบันทึกเซสชันของตัวเองกรณีใช้งานทางเลือกอาจเป็นผู้ดูแลระบบที่ต้องการติดตามสิ่งที่ผู้ใช้หลายคนกำลังทำอยู่

ฉันกลัวว่าการทำงานscriptภายในระบบทั้งระบบbashrcอาจไม่เหมาะสมในกรณีที่ผู้ใช้เครื่องลังเลที่จะบันทึกเสียงในเซสชันของตน

ผู้ใช้ที่ต้องการเก็บตัวไม่ระบุตัวตนสามารถข้ามการบันทึกได้โดยขอให้ sshd เปิดเชลล์ที่แตกต่าง (เช่นzsh) หรือเรียกใช้bash --rcfile ___เพื่อป้องกัน/etc/bash.bashrcการโหลด

วิธีการทางเลือก

คู่มือนี้จาก 2008 ( เก็บถาวร ) ใช้วิธีการอื่นเพื่อบังคับscriptให้ทำงานเมื่อผู้ใช้ล็อกอินด้วย ssh ซึ่งต้องการให้ผู้ใช้เข้าสู่ระบบด้วยคีย์สาธารณะ / ส่วนตัว

สิ่งนี้ทำได้โดยการเพิ่มสคริปต์ลงใน.ssh/authorized_keysไฟล์ของผู้ใช้ด้านหน้าของคีย์:

command="/usr/local/sbin/log-session" ssh-dss AAAAB3NzaC1kc3MAAAEBAMKr1HxJz.....

log-session( เก็บไว้ ) สคริปต์แล้วตัดสินใจหรือไม่ที่จะทำงาน/usr/bin/scriptเพื่อเข้าสู่เซสชั่นของผู้ใช้นี้

exec script -a -f -q -c "$SSH_ORIGINAL_COMMAND" $LOGFILE

เพื่อป้องกันผู้ใช้จากการลบคำสั่งเพิ่มผู้ดูแลระบบจะต้องถือว่าเป็นเจ้าของauthorized_keysไฟล์ของผู้ใช้

chown root:root ~user/.ssh/authorized_keys

น่าเสียดายที่นี่หมายความว่าผู้ใช้จะไม่สามารถเพิ่มคีย์เพิ่มเติมใด ๆ ได้ด้วยตนเองหรือที่สำคัญกว่านั้นคือเพิกถอนคีย์ที่มีอยู่หากคีย์ถูกบุกรุกซึ่งอยู่ไกลจากอุดมคติ

คำเตือน

เป็นเรื่องปกติสำหรับการกำหนดค่าเริ่มต้นของ sshd เพื่ออนุญาตให้ผู้ใช้ดำเนินการ SFTP ผ่านการเข้าสู่ระบบ ssh ของพวกเขา นี่เป็นวิธีสำหรับผู้ใช้ในการแก้ไขไฟล์โดยไม่ต้องมีการบันทึกการเปลี่ยนแปลง หากผู้ดูแลระบบไม่ต้องการให้ผู้ใช้สามารถทำเช่นนั้นได้เขาควรเปิดใช้งานการบันทึกบางอย่างสำหรับ SFTP หรือปิดใช้งานบริการ ถึงแม้ว่าในตอนนั้นผู้ใช้ยังสามารถทำการเปลี่ยนแปลงที่มองไม่เห็นในไฟล์โดยเรียกใช้สิ่งนี้ในเทอร์มินัล:

curl "http://users.own.server/server/new_data" > existing_file

อาจเป็นไปได้ที่จะตรวจสอบการเปลี่ยนแปลงเช่นนั้นโดยใช้ระบบไฟล์คัดลอกเมื่อเขียนที่บันทึกประวัติไฟล์ทั้งหมด

แต่เคล็ดลับที่คล้ายกันนี้จะอนุญาตให้ผู้ใช้เรียกใช้คำสั่งโดยที่ไม่ได้บันทึกไว้:

curl "http://users.own.server/server/secret_commands_824" | sh

ฉันไม่รู้วิธีแก้ปัญหาง่าย ๆ ความเป็นไปได้อาจเป็น:

  • การบันทึกข้อมูลเครือข่ายทั้งหมด (และยกเลิกการแกะข้อมูลในภายหลัง)
  • การบันทึกการโทรของระบบทั้งหมด

เรียงลำดับของสิ่งนี้อาจจะเป็นไปได้ด้วยauditd

แต่อย่างไรก็ตาม...

ไม่น่าเป็นไปได้ที่การบันทึกเซสชันผู้ใช้จะให้ความปลอดภัยที่แท้จริงสำหรับผู้ดูแลระบบ โดยค่าเริ่มต้นผู้ใช้สามารถจัดการไฟล์ของตัวเองและไม่สามารถเป็นอันตรายต่อระบบ หากผู้ใช้ที่เป็นอันตรายได้จัดการเพื่อเพิ่มสิทธิ์ผู้ใช้สามารถปิดการบันทึกและลบบันทึก (เว้นแต่ผู้ดูแลระบบได้กำหนดค่าบันทึกที่จะจัดเก็บไว้ในเครื่องแยกต่างหากในแบบผนวกเท่านั้น)

ผู้ดูแลระบบที่ทำการบันทึกเซสชันผู้ใช้โดยอัตโนมัติอาจแจ้งผู้ใช้ว่ากำลังดำเนินการอยู่ ในบางเขตอำนาจศาลรูปแบบของการเก็บรวบรวมข้อมูลนี้อาจละเมิดข้อมูลหรือกฎหมายความเป็นส่วนตัว และอย่างน้อยที่สุดก็จะเป็นที่เคารพผู้ใช้เพื่อให้พวกเขาตระหนักถึง

มีแนวโน้มว่าผู้ดูแลระบบจะสนใจเข้าสู่เซสชันของsudoผู้ใช้มากขึ้น นั่นอาจจะเป็นคำตอบที่แตกต่างหรืออาจเป็นคำถามที่แตกต่าง


2

แทน:

test "$(ps -ocommand= -p $PPID | awk '{print $1}')" == 'script' ||

ฉันจะใช้:

grep -qx "$PPID" <(pgrep -x "script") ||

เครื่องหมายคำพูดคู่ไม่จำเป็นในกรณีนี้ แต่ฉันมักจะใช้มันเป็นแบบมาตรฐาน ฉันแนะนำให้ใช้สวิตช์ "x" กับทั้ง grep และ pgrep เพื่อหลีกเลี่ยงการจับคู่ที่ไม่ค่อยพบ แต่เป็นปัญหากับสตริงย่อย

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.