දේශීය උබුන්ටු සිට ඇමේසන් ඊසී 2 සේවාදායකයක් වෙත එස්එස්එච් කිරීමට උත්සාහ කරන විට මට “අවසරය ප්‍රතික්ෂේප කර ඇත”

218

ඇමේසන් ඊසී 2 උදාහරණයේ වලාකුළෙහි ධාවනය වන යෙදුමක් මා සතුව ඇති අතර, එය මගේ දේශීය උබුන්ටු වෙතින් සම්බන්ධ කිරීමට අවශ්‍යය. එය දේශීය උබුන්ටු සහ ලැප්ටොප් එකක හොඳින් ක්‍රියා කරයි. වෙනත් දේශීය උබුන්ටු එකක SSH EC2 වෙත ප්‍රවේශ වීමට උත්සාහ කරන විට මට "අවසරය ප්‍රතික්ෂේප කරන ලදි (publickey)" පණිවිඩය ලැබුණි. ඒක මට හරිම අමුතුයි.

මම සිතන්නේ ඇමසන් ඊසී 2 හි ආරක්ෂක සැකසුම් වල යම් ආකාරයක ගැටළු ඇති අතර එය එක් අවස්ථාවකට හෝ සහතිකයකට සීමිත අයිපී ප්‍රවේශයක් ඇති අතර නැවත උත්පාදනය කිරීමට අවශ්‍ය විය හැකිය.

කවුරුහරි විසඳුමක් දන්නවාද?

linux ssh amazon-ec2

— වෝර්ලීක් චයි
source

11

"එය පෙර වැඩ කිරීමට පුරුදුව සිටියේය" - කුමක් කිරීමට පෙර ?

— ගර්භාෂය

මට ඉලාස්ටික් බීන්ස්ටොක් ඊසී 2 උදාහරණයක් තිබේ. අගෝස්තු -2013 වන විට විසඳුම වූයේ අවසරය ප්‍රතික්ෂේප කරන ලද (publicKey) දෝෂය පහව ගිය ec2- පරිශීලක පරිශීලකයා ලෙස නිදසුනට ප්‍රවේශ වීමයි. Viz: ssh -i ./mike-key-pairoregon.pem ec2-user@ec2-some-address.us-west-2.compute.amazonaws.com. ඇත්ත වශයෙන්ම ඔබට stackoverflow.com/questions/4742478/…

— mikemay

3

ඔබ සතුව වැරදි පරිශීලක නාමයක් තිබේ නම් ඔබට මෙම ගැටළුව ලැබෙනු ඇත. Aws docs ( docs.aws.amazon.com/AWSEC2/latest/UserGuide/… ) දැනට ec2-user [ssh -i /path/my-key-pair.pem ec2-user @ ec2-198 -51-100-1.

— david.barkhuizen

comment david.barkhuizen, ඔබේ අදහස මට උදව් විය. මට සමාන ගැටලුවක් තිබුණි; එය පරිශීලක නාමය සමඟ කළ යුතු බව පෙනී ගියේය. ස්තූතියි.

— නයිජා ප්‍රෝග්‍රැමර්

144

මෙම තත්වය තුළ කළ යුතු පළමු දෙය නම් -vවිකල්පය භාවිතා කිරීමයි ssh, එවිට ඔබට කුමන ආකාරයේ සත්‍යාපනය උත්සාහ කර ඇත්ද සහ එහි ප්‍රති result ලය කුමක් දැයි ඔබට දැක ගත හැකිය. තත්වය පැහැදිලි කිරීමට එය උපකාරී වේද?

ඔබගේ ප්‍රශ්නයට යාවත්කාලීන කිරීමේදී, ඔබ "වෙනත් දේශීය උබුන්ටු" ගැන සඳහන් කරයි. ඔබ ssh පුද්ගලික යතුර හරහා අනෙක් යන්ත්‍රයට පිටපත් කර තිබේද?

— ග්‍රෙග් හෙව්ගිල්
source

2

@ ග්‍රෙග් යෝජනා කළ පරිදි මම ssh පුද්ගලික යතුර අනෙක් යන්ත්‍රයට පිටපත් කර ඇත්තෙමි. එය දැන් ක්‍රියාත්මක වේ. ස්තූතියි!

— වෝර්ලීක් චි

3

FYI ඔබට යතුරු ස්ථාපනය නොකර -i ධජය භාවිතා කළ හැකිය

— ජෝර්ජ් වර්ගාස්

20

මගේ නඩුවේදී, මම බිට්නාමි .අමි භාවිතා කළ අතර ඔබ බිට්නාමි නම් පරිශීලකයා ලෙස ලොග් විය යුතු බව නොදැන, වැනි : ssh -i <keyfile> bitname@<ec2-address>. අවාසනාවට -vවිකල්පය මට මෙය සොයා ගැනීමට උදව් නොකළ නමුත් එය පරීක්ෂා කිරීම තවමත් ඉතා ප්‍රයෝජනවත් වේ!

— මැට් කොනොලි

7

හොඳයි, මගේ නඩුවේදී මම භාවිතා කළේ වැරදි පරිශීලක නාමයකි. "බිට්නාමි" වෙනුවට "උබුන්ටු" භාවිතා කරමින් සිටියේය. මේ වගේ: ssh -i key.pem bitnami @ hostaddress

— Lucas Pottersky

3

හොඳ ඊයම් යනු දුරස්ථ නෝඩය ද වේ, සොයා බලන්න /var/log/auth.log, සමහර විට ඔබට පහත පණිවිඩ පෙනෙනු ඇත: Authentication refused: bad ownership or modes for file /var/lib/jenkins/.ssh/authorized_keysහෝ වෙනත් දෙයක්

— ජොනාස් ලිබ්‍රෙච්ට්

76

එය නිශ්චිතව සඳහන් කර නොමැති බැවින්, sshd පෙරනිමියෙන් authorized_keysලිපිගොනු සඳහා වන අවසරයන් සම්බන්ධයෙන් ඉතා දැඩි වේ. ඒ නිසා, නම් authorized_keysවේ , ලිවිය-හැකි ගොනුවක් පරිශීලක හැර වෙනත් කිසිවෙකුට හෝ , ලිවිය-හැකි ගොනුවක් කළ හැකි පරිශීලක හැර වෙනත් කිසිවෙකුට විසින්, එය සත්ය බවට සහතික කිරීම ප්රතික්ෂේප වෙයි (sshd සමඟ මානකරන නම් මිස StrictModes no)

"ලිවිය හැකි" යන්නෙන් මා අදහස් කරන්නේ, පරිශීලක හැර වෙනත් ඕනෑම කෙනෙකුට මව් නාමාවලි ලිවිය හැකි නම්, එම නාමාවලි වෙනස් කිරීමට අවසර දී ඇති පරිශීලකයින්ට අවසර ලත්_කයිස් වෙනස් කිරීමට / ප්‍රතිස්ථාපනය කිරීමට හැකි වන පරිදි අවසර වෙනස් කිරීම ආරම්භ කළ හැකිය.

තවද, /home/username/.sshනාමාවලිය පරිශීලකයා සතු නොවේ නම් , එමඟින් ඔබට ගැටළු වලට මුහුණ දිය හැකි යතුර කියවීමට පරිශීලකයාට අවසර නොමැත:

drwxr-xr-x 7 jane jane 4096 Jan 22 02:10 /home/jane
drwx------ 2 root root 4096 Jan 22 03:28 /home/jane/.ssh

ජේන්ට .sshගොනුව අයිති නැති බව සලකන්න . මෙය හරහා සවි කරන්න

chown -R jane:jane /home/jane/.ssh

මෙම ආකාරයේ ගොනු පද්ධති අවසර ගැටළු සමඟ නොපෙන්වන අතර ssh -v, ඔබ ලොග් මට්ටම DEBUG ලෙස සකසන තුරු ඒවා sshd ලොග් (!) තුළ නොපෙන්වයි.

සංස්කරණය කරන්න /etc/ssh/sshd_config. ඔබට අවශ්‍ය LogLevel DEBUGවන්නේ එහි කොතැනක හෝ කියවන රේඛාවක් . ඩිස්ට්‍රෝ විසින් සපයන ලද යාන්ත්‍රණය භාවිතා කරමින් SSH සේවාදායකය නැවත පූරණය කරන්න. ( service sshd reloadRHEL / CentOS / Scientific මත.) අලංකාර රීලෝඩ් එකක් පවතින සැසි අතහරින්නේ නැත.
නැවත සත්‍යාපනය කිරීමට උත්සාහ කරන්න.
ඔබේ සහතික කිරීමේ ල logs ු-සටහන් කොතැනට ගොස් ඒවා කියවන්න. (IIRC, /var/log/auth.logඩේබියන් පදනම් කරගත් ඩිස්ට්‍රෝස් මත; /var/log/secureRHEL / CentOS / Scientific මත.)

ගොනු පද්ධති අවසර දෝෂ ඇතුළත් වන නිදොස් කිරීමේ ප්‍රතිදානයේ වැරැද්ද කුමක්දැයි සොයා බැලීම වඩා පහසුය. සිදු වූ /etc/ssh/sshd_configවිට වෙනස නැවත කිරීමට මතක තබා ගන්න !

— කෙජිල් ජෝර්ගන්සන්
source

5

එය "ලිවිය හැකි" බිට් එක තමයි මට ලැබුණේ

— wmarbut

7

FWIW යතුරු ලිපිගොනු සඳහා නිවැරදි අවසරයන් 600 කි ( මෙහි බලන්න )

— මැට් ලියොන්ස්

1

ඔව්, මගේ .authorized_keys ගොනුව කණ්ඩායම විසින් ලිවිය හැකි බැවින් එය පිළිගැනීම ප්‍රතික්ෂේප කළේය.

— ආදිත්‍ය පාර්ලිමේන්තු මන්ත්‍රී

2

මම මගේ හිසට බිත්තියට පහර දුන්නා! මගේ පරිශීලක ෆෝල්ඩරයට වැරදි අවසරයන් තිබුණි. ඔබට ස්තුතියි!

— XJones

4

~ / .ssh ෆෝල්ඩරය සඳහාම එයම වේ. ඔබට පහත දෝෂ පණිවිඩය ලැබිය හැකිය:Authentication refused: bad ownership or modes for directory

— යෙව්ගීනී එම්.

37

මට මෙම දෝෂය ලැබුණි, මන්ද මට -lවිකල්පයක් එක් කිරීමට අමතක වූ බැවිනි . මගේ දේශීය පරිශීලක නාමය දුරස්ථ පද්ධතියට සමාන නොවේ.

මෙය ඔබගේ ප්‍රශ්නයට පිළිතුරු සපයන්නේ නැත, නමුත් මම මෙහි පැමිණියේ මගේ ගැටලුවට පිළිතුරක් සොයමිනි.

— pkmk
source

26

ssh host -l userහා සමාන වේ ssh user@hostඅයිතිය?

— Znarkus

3

Nznarkus ඔව්, එය එසේමයි.

— cregox

ඔව්, මෙය මගේ ගැටලුව විසඳූ අතර “අවසරය ප්‍රතික්ෂේප කරන ලදි (පොදු)” දෝෂය ද ඇති විය.

— ok ක්ස් මෝසෙස්

1

මෙය මට ගැටලුව විය. පරිශීලක "root" වැඩ කරනු ඇතැයි මම අපේක්ෂා කළෙමි, නමුත් මම භාවිතා කළේ සුපුරුදු පරිශීලක "උබුන්ටු" ඇති උබුන්ටු ඊසී 2 රූපයකි.

— සෙරින්

19

මට මෙම පණිවිඩය ලැබුනේ උබුන්ටු ඒඑම්අයි මත පදනම් වූ නව අවස්ථාවක ය. මම PEM සැපයීම සඳහා -i විකල්පය භාවිතා කළ නමුත් එය තවමත් "අවසරය ප්‍රතික්ෂේප කරන ලදි (publickey)" පෙන්වයි.

මගේ ගැටලුව වූයේ මම නිවැරදි පරිශීලකයා භාවිතා නොකිරීමයි. උබුන්ටු @ ec2 සමඟ ssh ධාවනය කිරීමෙන් ... එය සාමාන්‍ය පරිදි ක්‍රියාත්මක විය.

ඔව් ... මම විධානය ක්‍රියාත්මක කරමින් සිටියෙමි sudo, ඒ නිසා එය ක්‍රියාත්මක නොවීය.

— thaddeusmt

16

කියවීමට වඩා පහසු දෙයක් ssh -v(ඇත්ත වශයෙන්ම මගේ මතය අනුව) tail -f /var/log/auth.log. එය සම්බන්ධ වීමට උත්සාහ කරන අතරතුර ඔබ සම්බන්ධ වීමට උත්සාහ කරන සේවාදායකයේ ක්‍රියාත්මක විය යුතුය. එය සරල පෙළෙහි දෝෂ පෙන්වනු ඇත.

මෙය මගේ ගැටලුව විසඳීමට මට උපකාරී විය:

Xlow.yy.com වෙතින් පරිශීලක [පරිශීලක නාමය] අවසර නැත, මන්ද පරිශීලක කණ්ඩායම් කිසිවක් AllowGroups හි ලැයිස්තුගත කර නොමැත

— ස්නාර්කස්
source

මෙය සේවාදායක ලොගයයි. RHEL / CentOS 7 සඳහා:tail -f /var/log/secure

— Gianfranco P.

10

ඔබගේ / etc / ssh / sshd_config ගොනුව පරීක්ෂා කරන්න . එහිදී, පවසන රේඛාව සොයා ගන්න

PasswordAuthentication no

නැත යන්න වෙනුවට ඔව් යැයි පැවසීමට එම රේඛාව වෙනස් කළ යුතුය. එසේම, පසුව sshd සේවාදායකය නැවත ආරම්භ කරන්න.

sudo /etc/init.d/ssh restart

— සුදීප්තා චැටර්ජි
source

19

එමඟින් සේවාදායකය අඩු ආරක්ෂිත වේ.

— Znarkus

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

— ඩැනියෙල්

1

අපට /etc/ssh/sshd_configසේවාදායකයට ඇතුළු වීමට නොහැකි නම් - අප යන්නේ කෙසේද ?

— cyber8200

සේවාදායකයට ඇතුල් වීමට, ඔබ උදාහරණය නිර්මාණය කරන විට ඔවුන් ලබා දුන් PEM ගොනුව භාවිතා කළ යුතුය. උපදෙස් ඉන් පසුව යයි.

— සුදිප්තා චටර්ජි

Sshd නැවත ආරම්භ කිරීම සඳහා පහත දැක්වෙන විධානය අවශ්‍ය වුවද මෙය මට ප්‍රයෝජනවත් විය:sudo service sshd reload

— pacoverflow

6

සමහර විට වත්මන් පෝස්ටරයට අදාළ නොවිය හැකි නමුත් සමාන තත්වයන්ට පිළිතුරු සෙවීමේදී මෙය සොයා ගන්නා අනෙක් අයට උදව් විය හැකිය. ඇමේසන්ට ssh යතුරු පුවරුව ජනනය කිරීමට ඉඩ දෙනවා වෙනුවට, මම නිර්දේශ කරන්නේ ඔබේම, සම්මත, සුපුරුදු පොදු ssh යතුර ඇමසන් වෙත උඩුගත කිරීමට සහ ඔබ EC2 උදාහරණයක් ක්‍රියාත්මක කරන විට එය නියම කිරීමට ය.

මෙය ඔබට "-i" වර්ගයේ සින්ටැක්ස් ssh තුළට දැමීමටත්, සම්මත විකල්ප සමඟ rsync භාවිතා කිරීමටත්, සියලු EC2 කලාප හරහා එකම ssh යතුර භාවිතා කිරීමටත් ඉඩ දෙයි.

මෙම ක්‍රියාවලිය ගැන මම මෙහි ලිපියක් ලිව්වෙමි:

පුද්ගලික ssh යතුරු ඇමසන් EC2 වෙත උඩුගත කිරීම
http://alestic.com/2010/10/ec2-ssh-keys

— එරික් හැමන්ඩ්
source

+1 මෙම හේතුව නිසා මෙම ප්‍රශ්නය හරියටම බැලීය.

— ජෝන් රිසෙල්වාටෝ

ඔබේ ලිපිය අනුගමනය කිරීමේදී මෙම දෝෂය මට පෙනේ. කලාප = $ (ec2-description-region | cut -f2) අවශ්‍ය විකල්පය '-K, --private-key KEY' අස්ථානගත වී ඇත (-h භාවිතය සඳහා)

— කාෂිෆ් අලි

Ash කෂිෆ්අලි ඔබට EC2 API විධාන රේඛා මෙවලම් අක්තපත්‍ර සැකසීමට අවශ්‍ය වනු ඇත, එබැවින් සෑම අණ රේඛාවකම අක්තපත්‍ර සම්මත කිරීමට ඔබට අවශ්‍ය නැත.

— එරික් හැමන්ඩ්

5

පුදුමයට කරුණක් නම්, මගේ ගැටළුව වූයේ සේවාදායකය නැවත ආරම්භ කර එයට නව DNS නමක් නිකුත් කිරීමයි. මම පරණ ඩීඑන්එස් නම පාවිච්චි කළා. මෙය මෝඩකමක් බව මම දනිමි, නමුත් මෙය වටහා ගැනීමට මට යම් කාලයක් ගත විය.

— පැට්රික් කොලින්ස්
source

ඔබට ස්තුතියි! මෙය හරියටම මගේ ගැටලුව විය. ඔබ උදාහරණයක් නැවත ආරම්භ කරන විට DNS නම වෙනස් වී ඇති බව මම නොදනිමි.

— ටිම් ස්වස්ට්

මගේ නඩුවේදී, මම ප්‍රත්‍යාස්ථ IP එකක් ලබා දුන් විට * .compute.amazonaws.com URL වෙනස් විය.

— ජෙෆ්රි බූත්

2

ඔබ ඩ්‍රොප්බයර් ධාවනය වන සයනොජන් මොඩ් දුරකථනයකට සම්බන්ධ වීමට උත්සාහ කරන්නේ නම්, සියල්ල අවසර දී ඇති බව තහවුරු කර ගැනීම සඳහා ඔබ පහත දැක්වෙන රේඛා ධාවනය කළ යුතුය:

chmod 600 /data/dropbear/.ssh/authorized_keys

හෝ

chmod 700 /data/dropbear/.ssh/authorized_keys # In case of MacOS X 10.6-10.8

හා

chmod 755 /data/dropbear/ /data/dropbear/.ssh

මෙය මා වෙනුවෙන් එය සවි කර ඇත, එසේ නොමැතිනම් කිසිවක් සම්බන්ධ කළ නොහැක.

— නෆ්ටුලි කේ
source

"වෙනත් දේශීය උබුන්ටු මත SSH EC2 වෙත ප්‍රවේශ වීමට උත්සාහ කරන විට."

— ව්‍යාකරණ

1

මම නැති නම් authorized_keys ?

— ඉගෝර්ගනාපොල්ස්කි

2

ඔබ CentOS 5 භාවිතා කරන්නේ නම්, ඔබ මාලාවක් කිරීමට ඔබට අවශ්ය විය හැක StrictModes noදී /etc/ssh/sshd_config. මම NIS / NFS භාවිතා කරමින් / නිවාස නාමාවලිය බෙදා ගන්නෙමි, මම සියලු අවසරයන් නිවැරදිව සකසා ඇත, නමුත් එය සෑම විටම මුරපදය සමඟ මා පොළඹවන ලදී. මම සැකසූ පසු StrictModes no, ගැටලුව අතුරුදහන් විය!

— uichin
source

1

ග්‍රෙග්ගේ පිළිතුර මඟින් එය වඩා හොඳින් වෙඩි තැබිය හැකි ආකාරය පැහැදිලි කරයි, කෙසේ වෙතත් සත්‍ය ගැටළුව නම් ඔබ ගනුදෙනුවේ එක් පැත්තක (සේවාදායකයා) ssh යතුරක් තබා ඇති අතර එය මුරපදය පදනම් කරගත් සත්‍යාපනයකට වඩා පොදු යතුරු සත්‍යාපනය කිරීමට උත්සාහ කරයි. EC2 නිදසුනෙහි අනුරූප පොදු යතුර ඔබ සතුව නොමැති බැවින් මෙය ක්‍රියා නොකරනු ඇත.

— සියන්
source

2

ඔබ ගැටලුව විසඳන්නේ කෙසේද?

— ජූලියන් ග්‍රෙනියර්

1

මට එකම ගැටළුවක් ඇති අතර, වැඩ කිරීමට අසමත් වූ විසඳුම් ටොන් ගණනක් උත්සාහ කිරීමෙන් පසු මම මගේ රවුටරයේ ෆයර්වෝලය මත SSH වරාය විවෘත කළෙමි (මගේ රවුටරයේ ෆයර්වෝල් පාලක පැනලය අවුල් සහගතය, එබැවින් සිදුවන්නේ කුමක්දැයි කීමට අපහසුය). කෙසේ වෙතත්, එය සවි කර ඇත :)

ඔබට ලැබෙන දෝෂය අවසරය ප්‍රතික්ෂේප කිරීම සුපිරි ලේවැකි කරදරයක් වන අතර එයින් ගම්‍ය වන්නේ යම් ආකාරයක සම්බන්ධතාවයක් ඇති බවයි.

— චිචිලට්
source

1

මා ඇතුළු සියලු පියවර අනුගමනය කළත් මට එකම ගැටලුවක් තිබුණි

$ ec2-authorize default -p 22

කෙසේ වෙතත්, මම මගේ අවස්ථාව බටහිර-බටහිර කලාපයේ ආරම්භ කර ඇත්තෙමි. එබැවින් ඉහත විධානය මඟින් ද එය නියම කළ යුතුය.

$ ec2-authorize default -p 22 --region us-west-1

මෙම විධානයෙන් පසුව මට නිදසුන ලිවීමට හැකි විය. ගැටලුව අවබෝධ කර ගැනීමට පෙර මම ටික වේලාවක් ගත කළ අතර මෙම ලිපිය අන් අයට උපකාර කරනු ඇතැයි බලාපොරොත්තු වෙමි.

— අජිත් වර්මා
source

0

මෙය දුර්ලභ අවස්ථාවකි, නමුත් ඔබ selinux සක්‍රීය කර ඇත්නම් සහ ඔබ බලයලත්_කයිස් (උදා: හවුල් නිවාස නාමාවලි) සමඟ නාමාවලිය සඳහා nfs භාවිතා කරන්නේ නම්, ඔබට සෙලිනක්ස් අක්‍රීය කිරීමට අවශ්‍ය වනු ඇත (ආරක්ෂක හේතූන් මත නිර්දේශ නොකරයි, නමුත් ඔබට එය තාවකාලිකව අබල කළ හැකිය මෙය ගැටළුවක් ඇති කරන්නේ දැයි බැලීමට) හෝ සෙලිනක්ස් හට nfs නිවාස නාමාවලි භාවිතා කිරීමට ඉඩ දෙන්න. විස්තර පිළිබඳ මට පැහැදිලි නැත, නමුත් මෙය මට වැඩ කළේය setsebool -P use_nfs_home_dirs 1

— රීස්
source

0

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

tail -f /var/log/secureයන්ත්‍රය මත ධාවනය වී දෝෂය දැකීමෙන් මෙය හේතුව බව මම සොයා ගතිමි Authentication refused: bad ownership or modes for directory /home/<username>.

— ජේකබ් ටොම්ලින්සන්
source