ບັນຊີ SSH proxy ສາມາດເຮັດວຽກໄດ້ໂດຍບໍ່ມີ shell

ຮັກສາການສົ່ງຕໍ່ SSH ໃຫ້ພ້ອມໃຊ້ ພ້ອມປິດເຊສຊັນ shell ແລະ ເຂົ້າໃຈຂອບເຂດຂອງການບັງຄັບ SOCKS ຢ່າງດຽວ.

ການຕັ້ງຄ່າທີ່ລໍ້ໃຈແມ່ນ AllowTcpForwarding no. ໜ້າເສຍດາຍ, ມັນຍັງປິດການສົ່ງຕໍ່ທີ່ proxy SSH SOCKS ພາຍໃນຕ້ອງການ. ການສົ່ງຕໍ່ແບບເຄື່ອນໄຫວບໍ່ແມ່ນຊ່ອງຫຼຸດນະໂຍບາຍຂອງເຊີບເວີ.

ສຳລັບບັນຊີສະເພາະ, OpenSSH ແຍກຄວາມສາມາດຫຼາຍຢ່າງ. ສ່ວນນະໂຍບາຍສາມາດອະນຸຍາດການສົ່ງຕໍ່ພາຍໃນ ພ້ອມກັບປ້ອງກັນເຊສຊັນ shell ແລະ ລະບົບຍ່ອຍ:

Match User proxyuser
    AllowTcpForwarding local
    MaxSessions 0
    PermitTTY no
    X11Forwarding no
    AllowAgentForwarding no

ຄູ່ມືເຊີບເວີ ອະທິບາຍ MaxSessions 0 ວ່າເປັນການຕັ້ງຄ່າທີ່ປ້ອງກັນເຊສຊັນ shell, ການເຂົ້າລະບົບ ແລະ ລະບົບຍ່ອຍ ພ້ອມອະນຸຍາດການສົ່ງຕໍ່. ລວມມັນເຂົ້າໃນບັນຊີທີ່ຢັ້ງຢືນແລ້ວ; ນີ້ບໍ່ແມ່ນການຕັ້ງຄ່າຄວາມປອດໄພ SSH ທີ່ສົມບູນ.

ການສົ່ງຕໍ່ຢ່າງດຽວ ບໍ່ແມ່ນ SOCKS ຢ່າງດຽວ

ການສົ່ງຕໍ່ພາຍໃນແບບຄົງທີ່ ແລະ ຄຳຮ້ອງ SOCKS ອາດສຸດທ້າຍຮ້ອງຂໍການເຊື່ອມຕໍ່ປາຍທາງຊະນິດດຽວກັນຈາກເຊີບເວີ. ການອະນຸຍາດການສົ່ງຕໍ່ພາຍໃນບໍ່ຮັບປະກັນວ່າລູກຄ້າໃຊ້ອິນເຕີເຟສ SOCKS ໃດໜຶ່ງ. ຢ່າອະທິບາຍບັນຊີວ່າເປັນການບັງຄັບໃຊ້ SOCKS ຢ່າງດຽວ.

PermitOpen ສາມາດຈຳກັດ ຄູ່ host ແລະ port ປາຍທາງ ເມື່ອລາຍຊື່ສະເພາະເໝາະກັບຄວາມຕ້ອງການ. ມັນບໍ່ແມ່ນການຫ້າມທົ່ວໄປທີ່ຮູ້ການແກ້ຊື່ host ສຳລັບທຸກເຄືອຂ່າຍສ່ວນຕົວ. ຂໍ້ຈຳກັດທີ່ຢູ່ກວ້າງກວ່າອາດຕ້ອງການນະໂຍບາຍເຄືອຂ່າຍ host ທີ່ເໝາະສົມ.

ການຕັ້ງຄ່າບັນຊີ, ກະແຈ ແລະ ເຊີບເວີທີ່ລວມເຂົ້າສາມາດຈຳກັດການສົ່ງຕໍ່ເພີ່ມເຕີມ. ການຫ້າມສົ່ງຕໍ່ແບບທົ່ວໄປຢູ່ບ່ອນອື່ນອາດລຶບຄວາມສາມາດທີ່ສ່ວນນີ້ເບິ່ງຄືວ່າອະນຸຍາດ.

ໃຊ້ຂັ້ນຕອນການບໍລິຫານເຊີບເວີປົກກະຕິພ້ອມເສັ້ນທາງກູ້ຄືນ, ແລ້ວປະເມີນຄວາມສາມາດທີ່ອະນຸຍາດ ແລະ ປະຕິເສດແຍກກັນ. ຜົນທີ່ຕ້ອງການແມ່ນການອະນຸຍາດສົ່ງຕໍ່ຢ່າງຊັດເຈນ, ບໍ່ແມ່ນການເຂົ້າລະບົບແບບໂຕ້ຕອບທີ່ຖືກເປີດໄວ້ໂດຍບັງເອີນ ຫຼື proxy ທີ່ຖືກປິດໂດຍຂໍ້ຈຳກັດຂອງມັນເອງ.

ບົດຄວາມທີ່ກ່ຽວຂ້ອງ