SSH උමං මාර්ග දෝෂය: “නාලිකා 1: විවෘත කිරීම අසාර්ථකයි: පරිපාලනමය වශයෙන් තහනම්: විවෘත අසාර්ථකයි”

මම මෙම ssh උමග විවෘත කරන විට:

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

Localhost: 8984 හි ධාවනය වන HTTP සේවාදායකයට ප්‍රවේශ වීමට උත්සාහ කිරීමේදී මට මෙම දෝෂය ඇතිවිය.

channel 1: open failed: administratively prohibited: open failed

මෙම දෝෂය අදහස් කරන්නේ කුමක්ද, ඔබට ගැටලුව විසඳිය හැක්කේ කුමන යන්ත්‍රයෙන්ද?

නාලිකාව 1: විවෘත කිරීම අසාර්ථකයි: පරිපාලනමය වශයෙන් තහනම්: විවෘත අසාර්ථකයි

ඉහත පණිවුඩය මඟින් ඔබේ SSH සේවාදායකයා පැති නාලිකාවක් විවෘත කිරීමට ඔබගේ SSH සේවාදායකයාගේ ඉල්ලීම ප්‍රතික්ෂේප කරයි. මෙය සාමාන්‍යයෙන් පැමිණෙන්නේ -D, -Lහෝ -w, ඉදිරියට යවන ලද දත්ත හරහා ගෙනයාමට SSH ප්‍රවාහයේ වෙනම නාලිකා අවශ්‍ය වන බැවිනි.

ඔබ භාවිතා කරන බැවින් -L(ද අදාළ වේ -D), ඔබේ SSH සේවාදායකය මෙම ඉල්ලීම ප්‍රතික්ෂේප කිරීමට හේතු වන විකල්ප දෙකක් තිබේ:

• AllowTcpForwarding (ස්ටීව් බුසෝනාස් සඳහන් කළ පරිදි)
• PermitOpen

මෙම විකල්පයන් සොයාගත හැකිය /etc/ssh/sshd_config. ඔබ එය සහතික කළ යුතුය:

• AllowTCPForwarding එක්කෝ නොපවතී, අදහස් දක්වනු ලැබේ, නැතහොත් සකසා ඇත yes
• PermitOpenඑක්කෝ නොපවතී, අදහස් දක්වනු ලැබේ, නැතහොත් any[1] ලෙස සකසා ඇත.

මීට අමතරව, ඔබ සම්බන්ධ වීමට SSH යතුරක් භාවිතා කරන්නේ නම්, ඔබේ SSH යතුරට අනුරූප වන ප්‍රවේශය හෝ ප්‍රකාශයන් ~/.ssh/authorized_keysනොමැති බව ඔබ පරීක්ෂා කළ යුතුය [2].no-port-forwardingpermitopen

ඔබගේ විශේෂිත විධානයට අදාළ නොවන නමුත් මෙම මාතෘකාවට තරමක් අදාළ වේ, PermitTunnelඔබ -w විකල්පය භාවිතා කිරීමට උත්සාහ කරන්නේ නම් විකල්පය වේ.

[1] sshd_config(5)මෑන් පිටුවේ සම්පූර්ණ වාක්‍ය ඛණ්ඩය.

[2] authorized_keys(5)මෑන් පිටුවේ සම්පූර්ණ වාක්‍ය ඛණ්ඩය.

ඉතා අමුතු අවස්ථාවක, දේශීය උමගක් නිර්මාණය කිරීමට උත්සාහ කරන අතරතුර මම ද මෙම දෝෂය අත්විඳිමි. මගේ අණ මේ වගේ දෙයක් විය:

ssh -L 1234:localhost:1234 user@remote

ගැටළුව වූයේ දුරස්ථ ධාරකයේ /etc/hosts"localhost" සඳහා ප්‍රවේශයක් නොතිබීමයි , එබැවින් උමඟ සකස් කරන්නේ කෙසේදැයි ssh සේවාදායකයා නොදැන සිටියේය. මෙම නඩුව සඳහා ඉතා හිතකර නොවන වැරදි පණිවිඩයක්; සතුටුයි මම අන්තිමට ඒක හොයාගත්තා.

පාඩම: ඔබේ උමගෙහි ඉලක්කගත ධාරක නාමය දුරස්ථ ධාරකයා විසින් DNS හරහා හෝ විසඳිය හැකි බවට වග බලා ගන්න /etc/hosts.

අවම වශයෙන් එක් පිළිතුරක් නම් “දුරස්ථ” යන්ත්‍රය කිසියම් හේතුවක් නිසා ssh සමඟ ළඟා විය නොහැකි බවයි. දෝෂ පණිවිඩය විකාරයකි.

සේවාදායකයේ 'දුරස්ථය' විසඳිය නොහැකි නම් ඔබට එම දෝෂය ලැබෙනු ඇත. IP ලිපිනයක් සමඟ ප්‍රතිස්ථාපනය කර එය ඔබගේ ගැටළුව විසඳන්නේ දැයි බලන්න ...

(මූලික වශයෙන් නීල්ගේ පිළිතුරමයි - නමුත් මගේ පැත්තේ ගැටලුව එය බව මට නිසැකවම පෙනී ගියේය) [මගේ ~/.ssh/configගොනුවේ යන්ත්‍ර නාමය සඳහා අන්වර්ථයක් තිබුණි - දුරස්ථ යන්ත්‍රය එම අන්වර්ථය ගැන කිසිවක් දැන සිටියේ නැත ...

ඔබ ssh විකල්ප භාවිතා කරන විට ControlPathසහ ControlMasterසේවාදායක සම්බන්ධතා කිහිපයක් අතර නැවත භාවිතා කිරීම සඳහා එක් සොකට් සම්බන්ධතාවයක් බෙදා ගැනීමේදී (එක් සේවාදායකයෙකුගේ සිට එකම පරිශීලක සේවාදායකයා දක්වා) මෙම දෝෂය නිශ්චිතවම මතු වේ. ඕනෑවට වඩා විවෘත කිරීම (එහි අර්ථය කුමක් වුවත්, මගේ සම්බන්ධතා ~ 20 සම්බන්ධතා) මෙම පණිවිඩය ලබා දෙයි. පෙර ඇති ඕනෑම සම්බන්ධතා වසා දැමීමෙන් මට නව, නැවත සීමාව දක්වා විවෘත කළ හැකිය.

"පරිපාලනමය වශයෙන් තහනම්" යනු නිශ්චිත ICMP පණිවිඩ ධජයකි, එය "පරිපාලකයාට පැහැදිලිවම මෙම සම්බන්ධතාවය අවහිර කිරීමට අවශ්‍යය".

ඔබගේ iptables සැකසුම් පරීක්ෂා කරන්න.

මගේ නඩුවේදී, මට ආදේශ localhostකිරීමට සිදු 127.0.0.1වූයේ:

ssh -L 1234:localhost:3389 user@remote

එය ක්‍රියාත්මක කිරීමට.

SSH උමං මාර්ගයෙන් AWS EC2 හා සම්බන්ධ වීමටrdesktop -L localhost:1234 ඇමසන් උපදෙස් අනුගමනය කිරීමට මම උත්සාහ කළෙමි . /etc/ssh/sshd_configවැඩිම ඡන්දය දුන් පිළිතුරකට වෙනස් කිරීමට මම උත්සාහ කර ඇත්තෙමි (සේවාදායකයා සහ සේවාදායකයා උබුන්ටු 16.04 LTS ධාවනය කරයි). මම එය ද පරීක්ෂා localhostවේ /etc/hostsදෙපස.

මම sshවිධානය වෙනස් කරන තුරු කිසිවක් ක්‍රියාත්මක වූයේ නැත:

ssh -L 1234:127.0.0.1:3389 user@remote

ඒ හා සමාන ගැටළුවක්

විය හැකි තවත් ඊයම්

මටත් ඒ වගේ ප්‍රශ්නයක් ~/.ssh/authorized_keysතිබුණා permitopen.

මම autosshඋමගක් සෑදීමට භාවිතා කරන විට, මට වරායන් දෙකක් අවශ්‍යයි:

• සම්බන්ධතාවය සඳහා එකක් (10000),
• අධීක්ෂණය සඳහා එකක් (10001).

සේවාදායකයාගේ පැත්තෙන්

වරාය අධීක්ෂණය කිරීමේදී මෙය මට සමාන ගැටලුවක් ලබා දුන්නේය:

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...

එය localhostකෙටිමඟක් බව SSH තේරුම් නොගන්නා බව පෙනේ 127.0.0.1, එම නිසා පණිවිඩය auth.logසහ පරිපාලනමය වශයෙන් තහනම් පණිවිඩය.

මෙහි මා තේරුම් ගත් දෙය නම් පරිපාලනමය වශයෙන් අදහස් කරන්නේ "සේවාදායක පැත්තේ නිශ්චිත වින්‍යාසයක් හේතුවෙන්" යන්නයි.

විට මෙය සිදු /etc/sshd_configකර

AllowTcpForwarding no 

set. yesTCP ඉදිරියට යැවීමට ඉඩ දීම සඳහා එය මාරු කරන්න .

නිශ්චිත පිළිතුරක් සොයා ගැනීම සඳහා සමහර දෝශ නිරාකරණ ක්‍රියාකාරකම් අවශ්‍ය වේ:

• පරිශීලකයාගේ ssh වින්‍යාසය තුළ වරාය ඉදිරියට යැවීම සක්‍රීය දැයි පරීක්ෂා කරන්න,
• ssh (-v) හි වාචිකතාව සක්‍රීය කරන්න,
• දේශීය සත්කාරකයේ ssh ල logs ු-සටහන් පරීක්ෂා කර දුරස්ථ එකක ලොග් සුරක්ෂිත කරන්න,
• විවිධ දුරස්ථ වරාය පරීක්ෂා කරන්න,
• ඔබගේ iptables සැකසුම් පරීක්ෂා කරන්න (ෂදූර් පැවසූ පරිදි).

-L පරාමිතිය තුළ දුරස්ථය තැබීම සඳහා මට මෙම දෝෂය එක් වරක් ලැබුණි, එසේම 0.0.0.0 අතිරික්ත වන අතර ඔබට එම ප්‍රති results ල සමඟම එය මඟ හැරිය හැකි අතර එය ක්‍රියාත්මක වීමට ඔබ -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.

මෙය ඩීඑන්එස් ගැටළුවක් විය හැකි බව කිසිවෙකු සඳහන් නොකිරීම ගැන මම අතිශයින් පුදුම වෙමි.

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@වරාය ඉදිරියට ගෙන යන තර්කනයට එකතු කර ඇත්තෙමි (එය ක්‍රියා නොකරනු ඇත).

දේශීය පැත්තෙන් වරායට බැඳීමට නොහැකි වීමෙන් ද මෙය සිදුවිය හැකිය.

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

මෙම විධානය මඟින් දේශීය යන්ත්‍රයේ සවන්දීමේ වරාය 1234 බන්ධනය කිරීමට උත්සාහ කරන අතර එය දුරස්ථ යන්ත්‍රයක 5678 වරායේ සේවාවක් වෙත සිතියම් ගත කරයි.

දේශීය යන්ත්‍රයේ 1234 වරාය දැනටමත් වෙනත් ක්‍රියාවලියක් භාවිතා කරයි නම් (සමහර විට පසුබිම් ssh -f සැසිය), එවිට ssh හට එම වරායට සවන් දීමට නොහැකි වන අතර උමග අසමත් වනු ඇත.

ගැටළුව වන්නේ මෙම දෝෂ පණිවිඩයට කරුණු කිහිපයක් අදහස් විය හැකි අතර “පරිපාලනමය වශයෙන් තහනම්” සමහර විට වැරදි අදහස ලබා දෙයි. එබැවින් DNS, දේශීය සහ දුරස්ථ අතර ඇති ෆයර්වෝල් සහ sshd_config පරීක්ෂා කිරීමට අමතරව, දේශීය වරාය දැනටමත් භාවිතා කර ඇත්දැයි පරීක්ෂා කරන්න. භාවිත

lsof -ti:1234

1234 මත ක්‍රියාත්මක වන්නේ කුමන ක්‍රියාවලියදැයි සොයා බැලීමට. වෙනත් පරිශීලකයින් සතු ක්‍රියාවලි ලැයිස්තුගත කිරීම සඳහා ඔබට සුඩෝ අවශ්‍ය විය හැකිය. එවිට ඔබට භාවිතා කළ හැකිය

ps aux | grep <pid>

එම ක්‍රියාවලිය කුමක්දැයි සොයා ගැනීමට.

මේ සියල්ල එකම විධානයකින් ලබා ගැනීම සඳහා:

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

උමං මාර්ගයක් ගැනීමට උත්සාහ කරන අතරතුර මට එකම පණිවිඩයක් තිබුණි. දුරස්ථ පැත්තේ dns සේවාදායකය සමඟ ගැටළුවක් ඇතිවිය. එය නැවත වැඩට පැමිණි විට ගැටළුව විසඳුණි.

මගේ නඩුවේදී, ගැටළුව වූයේ ෂෙල් ප්‍රවේශය නොමැතිව උමගක් ඉල්ලා සිටීම සහ සේවාදායකයා මගේ ගිණුමේ මුරපද වෙනස් කිරීමක් බල කිරීම ය. කවචයක් නොමැතිකම නිසා මට එය නොපෙනුණු අතර දෝෂය පමණක් ලැබුණි

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!

ෂෙල් ප්‍රවේශය සමඟ ප්‍රවේශ වී මුරපදය වෙනස් කිරීමෙන් මම ගැටලුව විසඳුවා. එවිට මට නැවත ෂෙල් ප්‍රවේශය නොමැතිව උමං මාර්ග භාවිතා කළ හැකිය.

එස්එෆ්ටීපී භාවිතයෙන් සම්බන්ධ වීමට පමණක් අවසර දී ඇති පරිශීලකයෙකු සමඟ එස්එස්එච් හරහා සම්බන්ධ වීමට උත්සාහ කිරීමේදී මට මෙම ගැටළුව ඇති විය.

උදාහරණයක් ලෙස, මෙය සේවාදායකයේ විය /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 -ND *: 1234 user@127.0.0.1 සහ මම බ්‍රවුසරයක් එම කොම්ප්-මේස් සේවාදායකයට සම්බන්ධ කළ විට, එය පිරික්සීය, නමුත් මම එම 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 ධාරක ගොනුව අතින් සංස්කරණය කිරීමට උත්සාහ කර ඔබට ප්‍රවේශ වීමට අවශ්‍ය සේවාව එක් කරන්න.

මගේ නඩුව:

$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 උබුන්ටු -4ubuntu2.4, OpenSSL 1.0.2g 1 මාර්තු 2016

OpenSSH සේවාදායකයේ අනුවාදය:

• OpenSSH_7.6p1 Debian-4, OpenSSL 1.0.2n 7 දෙසැම්බර් 2017

වෙනත් නම් විභේදන හේතුව: මගේ / etc / ධාරකයන්ට සේවාදායකයේ නම සඳහා වැරදි IP ලිපිනයක් තිබුණි (localhost සඳහා නොවේ), මේ වගේ:

127.0.0.1     localhost
192.168.2.45  server.domain.com server

නමුත් වින්‍යාස කරන ලද සේවාදායක IP (සහ ධාරක / ඩිග් විධාන සමඟ විසඳන ලද DNS නම) 192.168.2.47 විය. පෙර IP නැවත සකස් කිරීම නිසා ඇති වූ සරල යතුරු ලියනයකි. / Etc / ධාරක සවි කිරීමෙන් පසු උමං සම්බන්ධතාවය දෝෂ රහිතව ක්‍රියාත්මක විය:

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

උමඟ සඳහා දේශීය හොස්ටල් අයිපී භාවිතා කරන විට සැබෑ අයිපී අසමත් වීම විකාරයකි. ඩිස්ට්‍රෝ: උබුන්ටු 16.04 එල්ටීඑස්.

මට එම පණිවිඩය ලැබීමට හේතුව වඩාත් සුලභ නොවන නමුත් එය සඳහන් කිරීම වටී. මම ස්ක්‍රිප්ට් මගින් උමං ලැයිස්තුවක් ජනනය කර ඇති අතර, තීරු ඉදිරිපත් කිරීමක් සහතික කිරීම සඳහා, මම සෑම අන්තිම බයිට් එකක්ම බයිට් දෙකකින් මුද්‍රණය කර ඇත්තෙමි. මම 192.168.66.08 වෙත ඉදිරියට යන උමං මාර්ගය විවෘත කිරීමට උත්සාහ කළ විට, එය සැමවිටම අසාර්ථක විය, මන්ද '08' යන්න අවලංගු අෂ්ටක අංකයක් ලෙස gethostbyaddr විසින් අර්ථකථනය කර ඇති බැවිනි :)

මෙම පණිවිඩය සඳහා මූල හේතු රාශියක් ඇති බව පෙනේ. මගේ නඩුවේදී එය යතුරුපුවරුව නිවැරදිව ලබා දී නොමැති නිසා දුරස්ථයට ප්‍රවේශ වීමට නොහැකි විය .

මෙම -Lවිකල්පය මඟින් ව්‍යාජ SSH පැනීමක් එක් කරයි (පැහැදිලි SSH ධාරකය බලකොටුවක් / පැනීමේ සේවාදායකයක් ලෙස effectively ලදායී ලෙස භාවිතා කිරීම). පැහැදිලිවම පැනීම සිදු කිරීමෙන් සහ "ප්‍රොක්සි කොමන්ඩ්" භාවිතා කරමින් ඉලක්කගත යන්ත්‍රයට පිවිසුම් කවචයක් නිර්මාණය කිරීමෙන් මෙය නිදොස් කිරීම පහසු වනු ඇත.

මෙය ක්‍රියාත්මක වූ පසු, ඉලක්කගත යන්ත්‍රය මත පදනම්ව ඔබට වරාය ඉදිරියට යා localhostහැකිය (එයට තමාටම පිවිසිය හැකි යැයි උපකල්පනය කරන්න):

-N -L 1234:localhost:1234

Asus RT68U රවුටරයේ ස්ථිරාංග (මර්ලින් අසූස්) සතුව SSH වරාය ඉදිරියට යැවීමට අවසර දෙන සැකසුමක් ඇත, එය සක්‍රීය කළ යුතුය:

විස්තර කර ඇති පරිදි ගතික වරාය ඉදිරියට යැවීම සකසා ඇත: ඩයමික් උමං දෝශ නිරාකරණය