ข้อผิดพลาดในการสร้างอุโมงค์ SSH:“ ช่อง 1: เปิดล้มเหลว: ไม่อนุญาตให้ดำเนินการ: เปิดล้มเหลว”

เมื่อฉันเปิดอุโมงค์ SSH นี้:

ssh -nXNT -p 22 localhost -L 0.0.0.0:8984:remote:8983

ฉันได้รับข้อผิดพลาดนี้เมื่อพยายามเข้าถึงเซิร์ฟเวอร์ HTTP ที่ทำงานบน localhost: 8984:

channel 1: open failed: administratively prohibited: open failed

ข้อผิดพลาดนี้หมายถึงอะไรและเครื่องใดที่คุณสามารถแก้ไขปัญหาได้

ช่องที่ 1: เปิดล้มเหลว: ไม่อนุญาตให้ดำเนินการ: เปิดล้มเหลว

ข้อความด้านบนหมายถึงเซิร์ฟเวอร์ SSH ของคุณปฏิเสธคำขอ SSH ของลูกค้าเพื่อเปิดช่องด้านข้าง นี้มักจะมาจาก-D, -Lหรือ-wเป็นช่องทางในกระแส SSH จะต้องข้ามฟากข้อมูลที่ส่งต่อไปทั่ว

เนื่องจากคุณกำลังใช้-L(ใช้ได้กับ-D) มีคำถามสองตัวเลือกที่ทำให้เซิร์ฟเวอร์ SSH ของคุณปฏิเสธคำขอนี้:

• AllowTcpForwarding (ดังที่ Steve Buzonas พูดถึง)
• PermitOpen

/etc/ssh/sshd_configตัวเลือกเหล่านี้สามารถพบได้ใน คุณควรมั่นใจว่า:

• AllowTCPForwarding ไม่เป็นปัจจุบันแสดงความคิดเห็นหรือตั้งค่าเป็น yes
• PermitOpenไม่แสดงความคิดเห็นหรือตั้งค่าเป็นany[1]

นอกจากนี้หากคุณกำลังใช้กุญแจ SSH เพื่อเชื่อมต่อคุณควรตรวจสอบว่ารายการที่สอดคล้องกับคีย์ SSH ของคุณ~/.ssh/authorized_keysไม่มีno-port-forwardingหรือpermitopenคำสั่ง [2]

ไม่เกี่ยวข้องกับคำสั่งเฉพาะของคุณ แต่ค่อนข้างเกี่ยวข้องกับหัวข้อนี้เช่นกันเป็นPermitTunnelตัวเลือกหากคุณพยายามใช้ตัวเลือก -w

[1] ไวยากรณ์ทั้งหมดในsshd_config(5)manpage

[2] ไวยากรณ์ทั้งหมดในauthorized_keys(5)manpage

ในกรณีที่แปลกมากฉันยังพบข้อผิดพลาดนี้ในขณะที่พยายามสร้างอุโมงค์ท้องถิ่น คำสั่งของฉันคืออะไรเช่นนี้:

ssh -L 1234:localhost:1234 user@remote

ปัญหาเกิดขึ้นบนรีโมตโฮสต์/etc/hostsไม่มีรายการสำหรับ "localhost" ดังนั้นเซิร์ฟเวอร์ ssh ไม่ทราบวิธีตั้งค่าช่องสัญญาณ ข้อความแสดงข้อผิดพลาดที่ไม่เป็นมิตรมากสำหรับกรณีนี้ ดีใจที่ฉันคิดออกในที่สุด

บทเรียน: ให้แน่ใจว่าชื่อโฮสต์เป้าหมายของคุณคืออุโมงค์ resolvable โดยโฮสต์ระยะไกลทั้งผ่าน DNS /etc/hostsหรือ

อย่างน้อยหนึ่งคำตอบก็คือเครื่อง "remote" ไม่สามารถเข้าถึงได้ด้วย ssh ด้วยเหตุผลบางอย่าง ข้อความแสดงข้อผิดพลาดเป็นเพียงเรื่องเหลวไหล

หากไม่สามารถแก้ไข 'ระยะไกล' บนเซิร์ฟเวอร์คุณจะได้รับข้อผิดพลาดนั้น แทนที่ด้วยที่อยู่ IP และดูว่าจะช่วยแก้ปัญหาของคุณ ...

(คำตอบเดียวกับ Neil - แต่ฉันก็พบว่าเป็นปัญหาด้านข้างของฉัน) [ฉันมีนามแฝงสำหรับชื่อเครื่องใน~/.ssh/configไฟล์ของฉัน- และเครื่องระยะไกลไม่ทราบว่ามีชื่อแทนอะไร ...

ข้อผิดพลาดนี้จะปรากฏขึ้นอย่างแน่นอนเมื่อคุณใช้ตัวเลือก ssh ControlPathและControlMasterสำหรับการแบ่งปันการเชื่อมต่อซ็อกเก็ตเดียวเพื่อนำมาใช้ซ้ำระหว่างการเชื่อมต่อไคลเอนต์หลาย (จากไคลเอนต์หนึ่งไปยังผู้ใช้ @ เซิร์ฟเวอร์เดียวกัน) การเปิดมากเกินไป (หมายความว่าอะไรในกรณีของฉัน ~ การเชื่อมต่อ 20 ครั้ง) จะให้ข้อความนี้ การปิดการเชื่อมต่อใด ๆ ก่อนหน้านี้ทำให้ฉันเปิดใหม่ได้อีกมากถึงขีด จำกัด

"administratively ห้าม" คือการตั้งค่าสถานะข้อความ ICMP เฉพาะที่เดือดลงไป "ผู้ดูแลระบบต้องการให้การเชื่อมต่อนี้ถูกบล็อกอย่างชัดเจน"

ตรวจสอบการตั้งค่า iptables ของคุณ

ปัญหาที่คล้ายกัน

นำไปได้อีกอย่างหนึ่ง

ฉันมีปัญหาเดียวกันโดยใช้กับ~/.ssh/authorized_keyspermitopen

เมื่อฉันใช้autosshเพื่อสร้างอุโมงค์ฉันต้องมีสองพอร์ต:

• หนึ่งสำหรับการเชื่อมต่อ (10,000)
• หนึ่งสำหรับการตรวจสอบ (1,0001)

ในฝั่งลูกค้า

สิ่งนี้ทำให้ฉันมีปัญหาคล้ายกันกับพอร์ตการตรวจสอบ:

autossh -M 10001 -o GatewayPorts=yes -o ServerAliveInterval=60  -o TCPKeepAlive=yes -T -N -R :10000:localhost:22 -i ~/.ssh/id_rsa user@remote

ฉันมีข้อความนั้น (หลังจาก 10 นาที):

channel 2: open failed: administratively prohibited: open failed

ด้านระยะไกล

ที่/var/log/auth.logมีอยู่ของฉัน:

Received request to connect to host 127.0.0.1 port 10001, but the request was denied.

ใน~/.ssh/authorized_keys(ด้านไกล) ฉันมีสิ่งนี้:

command="/home/user/tunnel",no-X11-forwarding,no-pty,permitopen="localhost:10000",permitopen="localhost:10001" ssh-rsa AAAA...

วิธีแก้ปัญหา

ฉันแก้ไขได้โดยแทนที่localhostอินสแตนซ์ด้วย127.0.0.1:

command="/home/user/tunnel",no-X11-forwarding,no-pty,permitopen="127.0.0.1:10000",permitopen="127.0.0.1:10001" ssh-rsa AAAA...

ดูเหมือนว่า SSH ไม่เข้าใจว่าlocalhostเป็นทางลัด127.0.0.1ดังนั้นข้อความในauth.logและข้อความที่ต้องห้ามในการดำเนินการ

สิ่งที่ฉันเข้าใจที่นี่คือการบริหารหมายถึง "เนื่องจากการกำหนดค่าเฉพาะในฝั่งเซิร์ฟเวอร์"

สิ่งนี้จะเกิดขึ้นเมื่อ/etc/sshd_configมี

AllowTcpForwarding no 

ชุด สลับเป็นเพื่อyesอนุญาตการส่งต่อ TCP

ในกรณีของฉันฉันต้องแทนที่localhostด้วย127.0.0.1ใน:

ssh -L 1234:localhost:3389 user@remote

เพื่อให้มันทำงาน

ผมพยายามที่จะrdesktop -L localhost:1234ต่อไปนี้ของ Amazon คำแนะนำเกี่ยวกับการเชื่อมต่อกับ AWS EC2 ผ่าน SSH อุโมงค์ ฉันพยายามเปลี่ยน/etc/ssh/sshd_config(ทั้งไคลเอนต์และเซิร์ฟเวอร์เรียกใช้ Ubuntu 16.04 LTS) ต่อคำตอบที่โหวตสูงสุด ฉันยังตรวจสอบว่าlocalhostมี/etc/hostsทั้งสองด้าน

ไม่มีอะไรทำงานจนกว่าฉันจะเปลี่ยนsshคำสั่งเป็น:

ssh -L 1234:127.0.0.1:3389 user@remote

กิจกรรมการแก้ไขปัญหาบางอย่างเป็นสิ่งจำเป็นเพื่อค้นหาคำตอบที่ชัดเจน:

• ตรวจสอบว่าเปิดใช้งานการส่งต่อพอร์ตในการกำหนดค่า ssh ของผู้ใช้
• เปิดใช้งาน verbosity ของ ssh (-v),
• ตรวจสอบบันทึก ssh บนโลคัลโฮสต์และล็อกที่ปลอดภัยบนรีโมต
• ทดสอบพอร์ตระยะไกลที่แตกต่างกัน
• ตรวจสอบการตั้งค่า iptables ของคุณ (ดังที่ Shadur กล่าว)

ฉันได้รับข้อผิดพลาดนี้ครั้งเดียวสำหรับการวางรีโมตในพารามิเตอร์ -L เช่นกัน 0.0.0.0 นั้นซ้ำซ้อนคุณสามารถละเว้นมันด้วยผลลัพธ์เดียวกันได้และฉันคิดว่าคุณควรเพิ่ม -g เพื่อให้ทำงานได้

นี่คือบรรทัดที่ฉันใช้สำหรับการขุดอุโมงค์: ssh -L 8983:locahost:8984 user@remote -4 -g -N

-4 tells to use only ipv4
-g Allows remote hosts to connect to local forwarded ports.
-N Do not execute a remote command.  This is useful for just forwarding ports (protocol version 2 only). I use this to clog the terminal so I don't forget to close it since generally I need the tunnels temporarily.

นอกจากนี้ยังอาจเกิดจากการไม่สามารถผูกกับพอร์ตในด้านท้องถิ่น

ssh -Nn -L 1234:remote:5678 user@remote

คำสั่งนี้พยายามเชื่อมพอร์ตการรับฟัง 1234 บนเครื่องโลคัลซึ่งแม็พกับเซอร์วิสบนพอร์ต 5678 บนเครื่องรีโมต

หากพอร์ต 1234 บนเครื่องโลคัลถูกใช้โดยกระบวนการอื่นอยู่แล้ว (อาจเป็นแบ็คกราวน์ ssh -f เซสชัน) ดังนั้น ssh จะไม่สามารถฟังบนพอร์ตนั้นและอุโมงค์จะล้มเหลว

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

lsof -ti:1234

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

ps aux | grep <pid>

เพื่อค้นหาว่ากระบวนการนั้นคืออะไร

เพื่อให้ได้ทั้งหมดนี้ในคำสั่งเดียว:

ps aux | grep "$(sudo lsof -ti:1234)"

ฉันมีข้อความเดียวกันขณะพยายามอุโมงค์ มีปัญหากับเซิร์ฟเวอร์ dns ที่ด้านระยะไกล ปัญหาได้รับการแก้ไขเมื่อกลับมาทำงาน

ฉันประหลาดใจอย่างยิ่งที่ไม่มีใครพูดถึงว่านี่อาจเป็นปัญหา DNS

journalctl -f
channel 3: open failed: administratively prohibited: open failed
Mar 10 15:24:57 hostname sshd[30303]: error: connect_to user@example.com: unknown host (Name or service not known)

สิ่งนี้อาจถูกนำเสนอหากremoteไม่สามารถแก้ไขได้หรือคุณป้อนไวยากรณ์ที่ไม่รู้จักเช่นที่ฉันทำที่นี่ซึ่งฉันได้เพิ่มuser@ไว้ในตรรกะการส่งต่อพอร์ต (ซึ่งจะไม่ทำงาน)

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

channel 2: open failed: administratively prohibited: open failed  

การกำหนดค่าอุโมงค์ของฉันเป็นดังนี้:

ssh -p [ssh-port] -N -f -L [local-port]:127.0.0.1:[remote-port]
[server-address]

ข้อผิดพลาดแสดงให้เห็นเมื่อเข้าสู่เซิร์ฟเวอร์โดยตรง (ไม่มี -N -f):

WARNING: Your password has expired. You must change your password now
and login again!

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

ฉันมีปัญหานี้เมื่อพยายามเชื่อมต่อผ่าน SSH กับผู้ใช้ที่ได้รับอนุญาตให้เชื่อมต่อโดยใช้ SFTP เท่านั้น

ตัวอย่างเช่นสิ่งนี้อยู่ในเซิร์ฟเวอร์/etc/ssh/sshd_config:

Match group sftponly
    ForceCommand internal-sftp
    ChrootDirectory /usr/chroot/%u
    [...]
Match

ดังนั้นในกรณีนี้หากต้องการใช้ SSH คุณจะต้องลบผู้ใช้ออกจากsftponlyกลุ่มที่เทียบเท่าหรือเชื่อมต่อโดยใช้ผู้ใช้ที่ไม่ จำกัด SFTP

ตรวจสอบว่า/etc/resolv.confว่างเปล่าบนเซิร์ฟเวอร์ที่คุณกำลังsshจะไป หลายครั้งที่ฉันพบสิ่งนี้เกี่ยวข้องกับ/etc/resolv.confไฟล์ว่างเปล่า

หากไม่ใช่รูทคุณสามารถตรวจสอบเซิร์ฟเวอร์โดยลองใช้บางส่วนpingหรือtelnet(80) บนชื่อโฮสต์สาธารณะเช่น:

root@bananapi ~ # telnet www.google.com 80
telnet: could not resolve www.google.com/80: Name or service not known

หลังจากเพิ่มระเบียนเนมเซิร์ฟเวอร์ไปที่/etc/resolv.conf:

root@bananapi ~ # telnet www.google.com 80
Trying 74.125.195.104...
Connected to www.google.com.
Escape character is '^]'.
GET / HTTP/1.0

HTTP/1.0 302 Found
Location: http://www.google.ro/?gws_rd=cr&ei=8fStVZ-hMIv6UvX6iuAK

อย่างไรก็ตามคุณควรตรวจสอบด้วยว่าเหตุใดจึง/etc/resolv.confว่างเปล่า (โดยทั่วไปจะมีข้อมูลที่มีชื่อเนมเซิร์ฟเวอร์โดยไคลเอ็นต์ dhcp บนเซิร์ฟเวอร์ถ้ามี

ฉันได้รับข้อความเดียวกันในขณะที่ SSH ปรับไปที่เดเบียน มันเปิดออกระบบระยะไกลไม่มีพื้นที่ว่าง หลังจากเพิ่มพื้นที่ว่างในดิสก์และรีบูตอุโมงค์เริ่มทำงาน

ฉันเห็นข้อผิดพลาดนี้ใน cygwin และสิ่งนี้ควรเป็นจริงสำหรับ linux เช่นกันและทำงานให้ฉัน ในกรณีของฉันฉันทำ ssh -ND *: 1234 user@127.0.0.1 และเมื่อฉันเชื่อมต่อเบราว์เซอร์กับเซิร์ฟเวอร์ comp-socks นั้นก็เรียกดู แต่ในคอมพ์ที่ฉันเรียกใช้คำสั่ง ssh นั้นฉันได้รับข้อผิดพลาดนั้นปรากฏที่ คอนโซลพร้อมคำขอแต่ละรายการ - อย่างน้อยหนึ่งไซต์แม้ว่าเบราว์เซอร์จะดึงข้อมูลผ่านพร็อกซีหรือดูเหมือนว่าอย่างน้อยก็เท่าที่ฉันเห็นอายุหลัก แต่การเปลี่ยนแปลงนี้จะกำจัดข้อความที่ล้มเหลว

http://linuxindetails.wordpress.com/2010/02/18/channel-3-open-failed-administratively-prohibited-open-failed/

While trying to do some SSH tunneling, here is the error I got :
channel 3: open failed: administratively prohibited: open failed
To avoid this kind of error, have a look at the SSH daemon configuration file :
/etc/ssh/sshd_config
Add possibly the following line :
root@remote-server:~# echo “PermitTunnel yes” >> /etc/ssh/sshd_config
Then, restart your sshd server :
root@remote-server:~# service ssh restart
or

root@remote-server:~# /etc/init.d/ssh restart

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

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

ตรวจสอบเราเตอร์เพื่อรับการป้องกันDNS Rebinding เราเตอร์ (pfsense) ของฉันมี DNS Rebinding Protection ที่เปิดใช้งานโดยค่าเริ่มต้น มันเป็นสาเหตุของข้อผิดพลาด 'ช่องทางที่เปิด: ล้มเหลวในการดำเนินงานที่ไม่ได้รับอนุญาต: การเปิดล้มเหลว' กับ SSH

ฉันมีปัญหาเดียวกันและฉันรู้ว่ามันเป็น DNS ปริมาณการใช้ข้อมูลถูกรับส่งในช่องสัญญาณ แต่ไม่มีการร้องขอ DNS ลองแก้ไขไฟล์โฮสต์ DNS ของคุณด้วยตนเองและเพิ่มบริการที่คุณต้องการเข้าถึง

กรณีของฉัน:

$ssh -D 8081 localhost >>log1.txt 2>&1 &

----wait for 3 days

$tail -f log1.txt
channel 963: open failed: connect failed: Connection refused
channel 963: open failed: connect failed: Connection refused
channel 971: open failed: connect failed: Connection reset by peer
channel 982: open failed: connect failed: Connection timed out
channel 979: open failed: connect failed: Connection timed out
channel 1019: open failed: administratively prohibited: open failed
accept: Too many open files
channel 1019: open failed: administratively prohibited: open failed
accept: Too many open files
channel 1019: open failed: administratively prohibited: open failed

$ps  axu | grep 8081
root       404  0.0  0.0   4244   592 pts/1    S+   05:44   0:00 grep --color=auto 8081
root       807  0.3  0.6   8596  6192 ?        S    Mar17  76:44 ssh -D 8081 localhost

$lsof -p 807 | grep TCP
ssh     807 root 1013u  sock     0,8      0t0 2076902 protocol: TCP
ssh     807 root 1014u  sock     0,8      0t0 2078751 protocol: TCP
ssh     807 root 1015u  sock     0,8      0t0 2076894 protocol: TCP
.....

$lsof -p 807 | wc -l
1047

$ cat /etc/hosts
127.0.0.1   localhost
127.0.1.1   malcolm-desktop

$ssh localhost
Welcome to Ubuntu 14.04.2 LTS (GNU/Linux 3.13.0-53-generic i686)

----after restart ssh -D 8081 localhost
$ lsof -p 1184 | grep TCP
ssh     1184 root    3u  IPv4 2332193      0t0   TCP localhost:37742->localhost:ssh (ESTABLISHED)
ssh     1184 root    4u  IPv6 2332197      0t0   TCP ip6-localhost:tproxy (LISTEN)
ssh     1184 root    5u  IPv4 2332198      0t0   TCP localhost:tproxy (LISTEN)
ssh     1184 root    6u  IPv4 2332215      0t0   TCP localhost:tproxy->localhost:60136 (ESTABLISHED)
ssh     1184 root    7u  IPv4 2336142      0t0   TCP localhost:tproxy->localhost:32928 (CLOSE_WAIT)
ssh     1184 root    8u  IPv4 2336062      0t0   TCP localhost:tproxy->localhost:32880 (CLOSE_WAIT)

ฉันพบข้อผิดพลาดขณะเขียนข้อความนี้ในบล็อกของฉัน :

/etc/ssh/sshd_config มีบางสิ่งที่ชอบ:

Match Group SSHTunnel_RemoteAccessGroup
    AllowTcpForwarding yes
    PermitOpen=sshbeyondremote.server.com:22

แต่~/.ssh/configมี:

Host remote.server.com
  HostName remote.server.com
  Port 10022
  User useronremote
  IdentityFile ~/.ssh/keys/key1/openssh.keyforremote.priv
  LocalForward 2222 SSHBeyondRemote.server.com:22

หมายเหตุ: ความแตกต่างในกรณี (ตัวพิมพ์ใหญ่) ระหว่างSSHBeyondRemote.server.com:22และsshbeyondremote.server.com:22

เมื่อฉันแก้ไขกรณีฉันไม่เห็นปัญหาอีกต่อไป

ฉันใช้:

รุ่นของไคลเอนต์ OpenSSH:

• OpenSSH_7.2p2 Ubuntu-4ubuntu2.4, OpenSSL 1.0.2g 1 มี.ค. 2559

รุ่นของเซิร์ฟเวอร์ OpenSSH:

• OpenSSH_7.6p1 Debian-4, OpenSSL 1.0.2n 7 ธันวาคม 2560

สาเหตุการแก้ไขชื่ออื่น ๆ : / etc / hosts ของฉันมีที่อยู่ IP ที่ผิดพลาดสำหรับชื่อของเซิร์ฟเวอร์ (ไม่ใช่สำหรับ localhost) เช่นนี้:

127.0.0.1     localhost
192.168.2.45  server.domain.com server

แต่ IP ของเซิร์ฟเวอร์ที่กำหนดค่า (และชื่อ DNS ที่ได้รับการแก้ไขด้วยคำสั่ง host / dig) คือ 192.168.2.47 การพิมพ์ผิดง่ายที่เกิดจากการกำหนดค่า IP ก่อนหน้า หลังจากแก้ไข / etc / hosts การเชื่อมต่อกับอุโมงค์ยังทำงานได้อย่างไร้ที่ติ:

ssh user@server.domain.com -L 3456:127.0.0.1:5901

เป็นเรื่องแปลกที่ IP จริงทำให้เกิดความล้มเหลวเมื่อฉันใช้ IP ตามตัวอักษร localhost สำหรับช่องสัญญาณ Distro: Ubuntu 16.04 LTS

เหตุผลที่ฉันมีข้อความนั้นไม่ใช่ข้อความธรรมดาที่สุด แต่ควรพูดถึง ฉันสร้างรายการอุโมงค์โดยสคริปต์และเพื่อให้แน่ใจว่างานนำเสนอคอลัมน์ฉันได้พิมพ์แต่ละไบต์สุดท้ายด้วยสองไบต์ เมื่อฉันพยายามที่จะเปิดอุโมงค์ส่งต่อไปที่ 192.168.66.08 มันล้มเหลวเสมอเพราะ gethostbyaddr แปลเป็น '08' โดยเป็นตัวเลขฐานแปดที่ไม่ถูกต้อง :)

ดูเหมือนว่ามีสาเหตุที่เป็นไปได้มากมายสำหรับข้อความนี้ ในกรณีของฉันมันเป็นความสามารถในการเข้าถึงระยะไกลเพราะฉันไม่ได้ให้keyfileอย่างถูกต้อง

-Lตัวเลือกเพิ่มกระโดด SSH นัย (อย่างมีประสิทธิภาพโดยใช้โฮสต์ SSH อย่างชัดเจนเป็นเซิร์ฟเวอร์ป้อมปราการ / กระโดด) การดีบักอาจทำได้ง่ายกว่าด้วยการกระโดดอย่างชัดเจนและสร้างเชลล์ล็อกอินให้กับเครื่องเป้าหมายโดยใช้ "proxycommand"

เมื่อสิ่งนี้ทำงานแล้วคุณสามารถทำพอร์ตไปข้างหน้าตามเครื่องเป้าหมายlocalhost(สมมติว่ามันสามารถล็อกอินด้วยตัวเอง):

-N -L 1234:localhost:1234