පොදු යතුරු සත්‍යාපනය සමඟ ssh සමඟ මුරපද විමසුමක් මා තවමත් ලබා ගන්නේ ඇයි?

මම මෙහි සොයාගත් URL වෙතින් වැඩ කරමි:

http://web.archive.org/web/20160404025901/http://jaybyjayfresh.com/2009/02/04/logging-in-without-a-password-certificates-ssh/

මගේ ssh සේවාදායකයා උබුන්ටු 64 බිට් 11.10 ඩෙස්ක්ටොප් වන අතර මගේ සේවාදායකය සෙන්ටෝස් 6.2 64 බිට් වේ. මම උපදෙස් අනුගමනය කර ඇත්තෙමි. මට තවමත් ssh මත මුරපද විමසුමක් ලැබේ.

ඊළඟට කුමක් කළ යුතුදැයි මට විශ්වාස නැත.

~/.sshනාමාවලිය සහ එහි අන්තර්ගතය පිළිබඳ අවසරයන් නිසි බවට වග බලා ගන්න . මම මුලින්ම මගේ ssh යතුරු සත්‍යාපනය ~/.sshසැකසූ විට, ෆෝල්ඩරය නිසියාකාරව සකසා නොතිබූ අතර එය මට කෑගැසුවේය.

• ඔබගේ නිවසේ බහලුම ~, ඔබේ ~/.sshබහලුම සහ ~/.ssh/authorized_keysදුරස්ථ පරිගණකයේ ගොනු ඔබට පමණක්, ලිවිය-හැකි ගොනුවක් විය යුතුය: rwx------හා rwxr-xr-xදඩ, නමුත් rwxrwx---ඔබ ඔබේ කණ්ඩායමේ එකම පරිශීලක පවා නම්, කිසිදු good¹ වේ (ඔබ සංඛ්යාත්මක මාතයන් කැමති නම්: 700හෝ 755නොව 775) .
  නම් ~/.sshහෝ authorized_keysසංකේතාත්මක පුරුකක් වන අතර, (පුළුල් සංකේතාත්මක සබැඳි සමග) කැනොනිකල් මාර්ගය පරීක්ෂා කෙරේ .
• ඔබගේ ~/.ssh/authorized_keysගොනුව (දුරස්ථ යන්ත්‍රයේ) කියවිය හැකි (අවම වශයෙන් 400 ක්) විය යුතුය, නමුත් ඔබට එය ලිවිය හැකි (600) අවශ්‍ය වේ නම් ඔබ එයට තවත් යතුරු එකතු කරන්නේ නම්.
• ඔබගේ පුද්ගලික යතුරු ගොනුව (දේශීය යන්ත්‍රයේ) කියවිය හැකි සහ ලිවිය හැකි වන්නේ ඔබට පමණි:, rw-------එනම් 600.
• එසේම, SELinux බලාත්මක කිරීමට සකසා ඇත්නම්, ඔබට ධාවනය කිරීමට අවශ්‍ය විය හැකිය restorecon -R -v ~/.ssh(උදා: උබුන්ටු දෝෂ 965663 සහ ඩේබියන් දෝෂ වාර්තාව # 658675 බලන්න ; මෙය CentOS 6 හි ඇලවී ඇත ).

¹ _{ඔබ ඔබේ කණ්ඩායමේ එකම පරිශීලක නම් කණ්ඩායමක් writability ඉඩ කේතය ලැබු ඇති සමහර බෙදාහැරීම් (ඩේබියන් හා ව්යුත්පන්න) දින හැර.}

ඔබට සේවාදායකයට root ප්‍රවේශය තිබේ නම්, එවැනි ගැටළු විසඳීමට ඇති පහසුම ක්‍රමය /usr/sbin/sshd -d -p 2222නම්, සේවාදායකයේ වැනි දෙයක් නිකුත් කිරීමෙන් (sshd ක්‍රියාත්මක කළ හැකි සම්පූර්ණ මාර්ගය, which sshdඋදව් කළ හැකිය) සහ සේවාදායකයා සමඟ සම්බන්ධ වීමෙන් sshd නිදොස් කිරීමේ ක්‍රමයට ධාවනය කිරීමයි ssh -p 2222 user@host. මෙමඟින් SSH ඩීමන්ට පෙරබිමෙහි රැඳී සිටීමට සහ සෑම සම්බන්ධතාවයක් ගැනම නිදොස් කිරීමේ තොරතුරු පෙන්වීමට බල කෙරෙනු ඇත. වැනි දෙයක් සොයන්න

debug1: trying public key file /path/to/home/.ssh/authorized_keys
...
Authentication refused: bad ownership or modes for directory /path/to/home/

විකල්ප වරායක් භාවිතා කිරීමට නොහැකි නම්, ඔබට තාවකාලිකව SSH ඩීමන් නැවැත්විය හැකි අතර එය දෝශ නිරාකරණ ආකාරයෙන් ආදේශ කළ හැකිය. එස්එස්එච් ඩීමනය නැවැත්වීමෙන් දැනට පවතින සම්බන්ධතා විනාශ නොවන බැවින් දුරස්ථ පර්යන්තයක් හරහා මෙය කළ හැකි නමුත් තරමක් අවදානම් සහිත වේ - දෝශ නිරාකරණ ප්‍රතිස්ථාපනය ක්‍රියාත්මක නොවන මොහොතක සම්බන්ධතාවය කෙසේ හෝ බිඳී ගියහොත් ඔබ යන්ත්‍රයෙන් අගුළු දමා ඇත ඔබට එය නැවත ආරම්භ කරන තුරු. අවශ්‍ය විධාන:

service ssh stop
/usr/sbin/sshd -d
#...debug output...
service ssh start

(ඔබගේ ලිනක්ස් බෙදාහැරීම මත පදනම්ව, පළමු / අවසාන පේළිය systemctl stop sshd.service/ systemctl start sshd.serviceඒ වෙනුවට විය හැකිය .)

ඔබේ නිවස ඩර් සංකේතනය කර තිබේද? එසේ නම්, ඔබගේ පළමු ssh සැසිය සඳහා ඔබට මුරපදයක් ලබා දිය යුතුය. එකම සේවාදායකයට දෙවන ssh සැසිය auth යතුර සමඟ ක්‍රියා කරයි. මෙය එසේ නම්, ඔබට authorized_keysසංකේතාංකනය නොකළ ඩිරර් වෙත ගෙන ගොස් මාර්ගය වෙනස් කළ ~/.ssh/configහැකිය.

මා අවසන් /etc/ssh/usernameකළේ නිවැරදි අවසරයන් සහිත පරිශීලක නාමයට අයත් ෆෝල්ඩරයක් නිර්මාණය කර authorized_keysගොනුව එහි තැබීමයි. ඉන්පසු AuthorizedKeysFile විධානය වෙනස් කළේ /etc/ssh/config:

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

අවසරයන් නොසලකා හරිමින් බහු පරිශීලකයින්ට මෙම ssh ප්‍රවේශය ලබා ගැනීමට මෙය ඉඩ දෙයි.

දුරස්ථ යන්ත්‍රයට යතුරු පිටපත් කර ඒවා ඇතුළත තැබීමෙන් පසු authorized_keysඔබට මේ වගේ දෙයක් කිරීමට සිදුවේ:

ssh-agent bash
ssh-add ~/.ssh/id_dsa or id_rsa

පහත දැක්වෙන විධානයන් උත්සාහ කරන්න

1. ssh-keygen

   ඔබට විමසුම ලැබෙන තුරු Enter යතුර ඔබන්න

2. ssh-copy-id -i root@ip_address

   (එය වරක් සත්කාරක පද්ධතියේ මුරපදය ඉල්ලනු ඇත)

3. ssh root@ip_address

   දැන් ඔබට මුරපදයකින් තොරව ප්‍රවේශ විය හැකි විය යුතුය

දුරස්ථයේ ඇති නිවාස නාමාවලියට නිවැරදි වරප්‍රසාද නොමැති විට මම අභියෝගයන්ට මුහුණ දුන්නා. මගේ නඩුවේදී, පරිශීලකයා කණ්ඩායමේ සිටින සමහර දේශීය ප්‍රවේශය සඳහා නිවසේ ඩිර් 777 ලෙස වෙනස් කළේය . යන්ත්‍රයට තවදුරටත් ssh යතුරු සමඟ සම්බන්ධ වීමට නොහැකි විය. මම අවසරය 744 දක්වා වෙනස් කළ අතර එය නැවත ක්‍රියාත්මක වීමට පටන් ගත්තේය.

අපි එකම ගැටලුවකට මුහුණ දුන් අතර පිළිතුරේ පියවර අනුගමනය කළෙමු. නමුත් එය තවමත් අපට සාර්ථක වූයේ නැත. අපගේ ගැටළුව වූයේ පිවිසුම එක් සේවාදායකයෙකුගෙන් නොව වෙනත් සේවාදායකයෙකුගෙන් නොවේ (.ssh නාමාවලිය එන්එෆ්එස් සවිකර ඇති අතර සේවාදායකයින් දෙදෙනාම එකම යතුරු භාවිතා කිරීමයි).

ඒ නිසා අපට තවත් පියවරක් ඉදිරියට යාමට සිදු විය. Ssh විධානය වාචික මාදිලියේ ධාවනය කිරීමෙන් ඔබට බොහෝ තොරතුරු ලැබෙනු ඇත.

ssh -vv user@host

අප සොයාගත් දෙය නම් පෙරනිමි යතුර (id_rsa) භාර නොගත් අතර ඒ වෙනුවට ssh සේවාදායකයා සේවාදායක සත්කාරක නාමයට ගැලපෙන යතුරක් ඉදිරිපත් කළේය:

debug1: Offering public key: /home/user/.ssh/id_rsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: /home/user/.ssh/id_dsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: user@myclient                                          
debug2: we sent a publickey packet, wait for reply                                        
debug1: Server accepts key: pkalg ssh-rsa blen 277                  

නිසැකවම මෙය වෙනත් සේවාදායකයෙකුගෙන් ක්‍රියා නොකරනු ඇත.

එබැවින් අපගේ නඩුවේ විසඳුම වූයේ පෙරනිමි rsa යතුර පරිශීලක @ myclient අඩංගු යතුරට මාරු කිරීමයි. යතුරක් පෙරනිමියෙන් ඇති විට, සේවාදායකයාගේ නම පරීක්ෂා කිරීමක් නොමැත.

ස්විචයෙන් පසුව අපි තවත් ගැටලුවකට මුහුණ දුන්නා. පෙනෙන විදිහට යතුරු දේශීය ssh නියෝජිතයා තුළ තැන්පත් කර ඇති අතර නිදොස් කිරීමේ ලොගයෙහි අපට පහත දෝෂය ලැබුණි:

'Agent admitted failure to sign using the key'

Ssh නියෝජිතයාට යතුරු නැවත පූරණය කිරීමෙන් මෙය විසඳුණි:

ssh-add

RedHat / CentOS 6 හි SELinux හි පබ්කි සත්‍යාපනය පිළිබඳ ගැටළුවක් ඇත , සමහර විට සමහර ලිපිගොනු නිර්මාණය කරන විට selinux එහි ACL නිවැරදිව සකසන්නේ නැත.

මූල පරිශීලකයා සඳහා සෙලිනක්ස් ACLs අතින් සකස් කිරීමට:

restorecon -R -v /root/.ssh

එය සේවාදායක අවසානයේ SSH අස්ථානගත වීමේ වින්‍යාසය වනු ඇත. සේවාදායකයේ sshd_config ගොනුව සංස්කරණය කළ යුතුය. පිහිටා ඇත /etc/ssh/sshd_config. එම ගොනුවේ විචල්යයන් වෙනස් කරන්න

• ChallengeResponseAuthentication, PasswordAuthentication, UsePAM සඳහා 'ඔව්' සිට 'නැත'

• PubkeyAuthentication සඳහා 'නැත' සිට 'ඔව්' දක්වා

මත පදනම් http://kaotickreation.com/2008/05/21/disable-ssh-password-authentication-for-added-security/

AuthorizedKeysFileනිවැරදි ස්ථානයට යොමු වන බවට සහතික වන්න , %uපරිශීලක නාමය සඳහා ස්ථාන දරන්නෙකු ලෙස භාවිතා කරන්න:

# /etc/ssh/sshd_config
AuthorizedKeysFile /home/%u/authorized_keys

සමහර විට ඔබට රේඛාව ලිහිල් කිරීමට අවශ්‍ය විය හැකිය:

බලයලත් කයිස්ෆයිල් .ssh / author_keys

සිදුවිය යුතු වෙනස්කම් සඳහා ඔබ ssh සේවාව නැවත පූරණය කළ යුතු බව සිතන්න:

service sshd reload

අදහස් දෙකක්: මෙය මුල් ගොනුව නැවත ලියයි. මම ජනනය කළ පොදු යතුර පිටපත් කර මෙවැනි දෙයක් කරන්නෙමි:

cat your_public_key.pub >> .ssh/authorized_keys

මෙය ඔබට දැනට පවතින යතුරු ලැයිස්තුවට භාවිතා කිරීමට අවශ්‍ය යතුර එකතු කරනු ඇත. තවද, සමහර පද්ධති මෙම ගොනුව භාවිතා කරයි authorized_keys2එය අතර දැඩි සම්බන්ධයක් දැක්වුම් කිරීමට හොඳ අදහසක්, ඒ authorized_keysහා authorized_keys2පමණක් නඩුවේ,.

මගේ විසඳුම වූයේ ගිණුම අගුළු දමා තිබීමයි. / Var / log / safe හි ඇති පණිවිඩය: ගිණුම අගුළු දමා ඇති නිසා පරිශීලකයාට අවසර නැත විසඳුම: පරිශීලකයාට නව මුරපදයක් ලබා දෙන්න.

මම ඒ හා සමාන ගැටලුවකට මුහුණ දී නිදොස් කිරීමේ මාදිලිය භාවිතා කරමින් පියවර අනුගමනය කළෙමි.

/usr/sbin/sshd -d

මෙය පහත ප්‍රති .ලය පෙන්වයි

debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
Authentication refused: bad ownership or modes for directory /root
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys2
debug1: Could not open authorized keys '/root/.ssh/authorized_keys2': No such file or directory
debug1: restore_uid: 0/0
Failed publickey for root from 135.250.24.32 port 54553 ssh2
debug1: userauth-request for user root service ssh-connection method gssapi-with-mic

එය ඇත්තෙන්ම අවුල් සහගත විය

[root@sys-135 ~]# ls -l /
drwxrwxrwx.   2 root root     4096 Dec 14 20:05 bin
drwxrwxrwx.   5 root root     1024 May  6  2014 boot
drwxrwxrwx.   2 root root     4096 Dec  2  2013 cgroup
drwxrwxrwx.  10 root root     1024 Sep 25 23:46 data
drwxrwxrwx. 124 root root    12288 Dec 16 10:26 etc
drwxrwxrwx.  11 root root     4096 Jan 14  2014 lib
drwxrwxrwx.   9 root root    12288 Dec 14 20:05 lib64
drwxrwxrwx.   2 root root    16384 Jan 10  2014 lost+found
drwxrwxrwx.   2 root root     4096 Jun 28  2011 media
drwxr-xr-x.   2 root root        0 Dec 10 14:35 misc
drwxrwxrwx.   2 root root     4096 Jun 28  2011 mnt
drwxrwxrwx.   4 root root     4096 Nov 24 23:13 opt
dr-xr-xr-x. 580 root root        0 Dec 10 14:35 proc
drwxrwxrwx.  45 root root     4096 Dec 16 10:26 root

මූල ඩිරෙක්ටරියට සෑම කෙනෙකුටම අවසර ඇති බව එයින් පෙන්නුම් කෙරිණි. අනෙක් අයට අවසර නොලැබෙන පරිදි අපි එය වෙනස් කළෙමු.

[root@sys-135 ~]# chmod 750 /root

යතුරු සත්‍යාපනය ක්‍රියාත්මක වීමට පටන් ගත්තේය.

/ Etc / selinux / config ගොනුවේ SELINUX අක්‍රීය කිරීම සඳහා මුරපද රහිත ssh වැඩ සාර්ථකව ක්‍රියාත්මක කිරීමෙන් අක්‍රීය කර ඇත.

මීට පෙර මට එය එක් ආකාරයකින් කළ හැකිය. දැන් දෙයාකාරයෙන්ම මට මුරපද රහිත ssh කළ හැකිය.

මට වැරදුණු එක් දෙයක් නම් සේවාදායක පද්ධතියේ මගේ නිවාස නාමාවලියෙහි හිමිකාරිත්වයයි. සේවාදායක පද්ධතිය පෙරනිමියට සකසා ඇත: පෙරනිමිය එබැවින් මම:

chown -R root:root /root

එය ක්‍රියාත්මක විය. තවත් ලාභදායී විසඳුමක් වන්නේ StrictModes අක්‍රීය කිරීමයි: StirctModes no. sshd_config හි. යතුරු හුවමාරුව සහ සම්බන්ධතා ප්‍රොටෝකෝල හොඳ නම් මෙය අවම වශයෙන් ඔබට කියනු ඇත. එවිට ඔබට නරක අවසර දඩයම් කළ හැකිය.

මට නම්, විසඳුම වොජ්ටෙක් රෙසපාලගේ ප්‍රතිවිරුද්ධ දෙයයි : මම තවමත් භාවිතා authorized_keys2කරන බව මා දුටුවේ නැත , එය අතහැර දමා ඇත . මගේ ssh සැකසුම යම් අවස්ථාවක දී ක්‍රියා කිරීම නවතා දැමුවේ, සේවාදායකය යාවත්කාලීන වූ විට විය හැකිය. ගැටළුව විසඳූ .ssh/authorized_keys2පරිදි නැවත නම් කිරීම .ssh/authorized_keys.

ඩෝ!

අවසරයන් පරික්ෂා කිරීමෙන් පසුව සහ මෙහි ලැයිස්තුගත කර ඇති තවත් විසඳුම් කිහිපයක් උත්සාහ කිරීමෙන් පසුව, මම අවසානයේ සේවාදායකයේ ඇති ssh නාමාවලිය ඉවත් කළෙමි, මගේ පොදු යතුර නැවත සැකසීම.

සේවාදායක විධාන:

# rm -rf ~/.ssh

දේශීය විධාන:

# ssh-copy-id user@192.168.1.1        # where <user> is your username and <192.168.1.1> is the server IP

අතීතයේදී මට ssh මුරපදයක් අඩු සැකසුමක් ලබා ගන්නේ කෙසේද යන්න විස්තර කරන නිබන්ධන කිහිපයක් හමු විය, නමුත් සමහර ඒවා කනගාටුදායක ලෙස වැරදිය.
අපි නැවත ආරම්භ කරමු, සෑම පියවරක්ම පරීක්ෂා කරන්න:

1. සේවාදායකයා වෙතින් - යතුර ජනනය කරන්න: ssh-keygen -t rsa
   පොදු සහ පෞද්ගලික යතුර ( id_rsa.pubසහ id_rsa) ස්වයංක්‍රීයව ~/.ssh/නාමාවලියෙහි ගබඩා වේ .
   ඔබ හිස් මුරපදයක් භාවිතා කරන්නේ නම් සැකසීම පහසු වනු ඇත. ඔබ එය කිරීමට අකමැති නම්, තවමත් මෙම මාර්ගෝපදේශය අනුගමනය කරන්න, නමුත් පහත වෙඩි උණ්ඩය පරීක්ෂා කරන්න.
   
   
2. සේවාදායකයා වෙතින් - පොදු යතුර සේවාදායකයට පිටපත් කරන්න : ssh-copy-id user@server
   සේවාලාභී පොදු යතුර සේවාදායකයේ ස්ථානයට පිටපත් කරනු ලැබේ ~/.ssh/authorized_keys.
   
   
3. සේවාදායකයා වෙතින් - සේවාදායකයට සම්බන්ධ වන්න:ssh user@server
   
   

දැන්, විස්තර කර ඇති පියවර 3 න් පසුව එය තවමත් ක්‍රියාත්මක නොවන්නේ නම්, පහත සඳහන් දෑ උත්සාහ කරන්න:

• සේවාදායකයා සහ සේවාදායක යන්ත්‍රය ~/sshතුළ ඇති ෆෝල්ඩර අවසර පරීක්ෂා කරන්න .
• පරීක්ෂා කරන්න /etc/ssh/sshd_configතුළ සේවාදායකය බව සහතික කිරීමට RSAAuthentication, PubkeyAuthenticationසහ UsePAMවිකල්පයන් අක්රීය නොවන, ඔවුන් සමග පෙරනිමියෙන් සක්රිය කළ හැකිය yes.
• ඔබේ සේවාදායක ප්රධාන සකස්කරන විට ඔබ යුත් මුරවදනක් ඇතුළත් නම්, ඔබ උත්සාහ කල හැකි ssh-agentසහ ssh-addඔබගේ සැසිය තුල රහස් පදය-අඩු සම්බන්ධතා සපුරා ගැනීමට.
• අන්තර්ගතය පරීක්ෂා කරන්න /var/log/auth.logමත සේවාදායකය ප්රධාන සත්යාපන සියලු දී ගියේ ඇයි ප්රශ්නය සොයා ගැනීමට.

පුටි උබුන්ටු 16.04 යන්ත්‍රයකට සම්බන්ධ කිරීම සම්බන්ධයෙන් මට හරියටම සමාන ගැටලුවක් තිබුණි. පුට්ටිගේ පීඑස්සීපී වැඩසටහන එකම යතුරක් සමඟ හොඳින් ක්‍රියාත්මක වන නිසා එය ප්‍රහේලිකාවක් විය (එම යතුරම වෙනත් සත්කාරකයකු හා සම්බන්ධ වීමට පුටිට වැඩ කළේය).

T උටා ජාර්හෙඩ්ගේ වටිනා අදහස් දැක්වීමට ස්තූතියි, මම මගේ /var/log/auth.log ගොනුව පරීක්ෂා කර පහත සඳහන් දෑ සොයා ගතිමි.

sshd[17278]: userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]

OpenSSH හි නවතම අනුවාදයන් පෙරනිමියෙන් DSA යතුරු භාර නොගන්නා බව පෙනේ. මම ඩීඑස්ඒ සිට ආර්එස්ඒ යතුරකට මාරු වූ පසු, එය හොඳින් ක්‍රියාත්මක විය.

තවත් ප්‍රවේශයක්: ඩීඑස්ඒ යතුරු පිළිගැනීම සඳහා එස්එස්එච් සේවාදායකය වින්‍යාසගත කරන්නේ කෙසේද යන්න මෙම ප්‍රශ්නය සාකච්ඡා කරයි: /superuser/1016989/ssh-dsa-keys-no-longer-work-for-password-less-authentication?lq = 1

මෙම පියවර ඔබට උදව් විය යුතුය. බොහෝ 64bit උබුන්ටු 10.04 යන්ත්‍ර අතර මම මෙය නිතිපතා භාවිතා කරමි.

[ ! -f ~/.ssh/id_rsa.pub ] && ssh-keygen -t rsa;
ssh <username>@<remote_machine> 'mkdir -p ~/.ssh'
cat ~/.ssh/id_rsa.pub | ssh <username>@<remote_machine> 'cat >> ~/.ssh/authorized_keys'

ඔබට මෙය යම් විමසුමක් සහිත ස්ක්‍රිප්ට් එකක දමා එය ආයාචනා කළ හැකිය

script_name username remote_machine

මට ssh හා සමාන ගැටලුවක් තිබුණි. මගේ නඩුවේ ගැටළුව වූයේ මම හැඩූප් ක්ලවුඩරා ස්ථාපනය කිරීමයි (ආර්පීඑම් සිට සෙන්ටෝස් 6 සිට) සහ එය නිවාස නාමාවලිය සමඟ පරිශීලක HDF නිර්මාණය කළේය

/var/lib/hadoop-hdfs(සම්මත නොවේ /home/hdfs).

මම / etc / passwd /var/lib/hadoop-hdfsලෙස වෙනස් කර /home/hdfs, නිවාස නාමාවලිය නව ස්ථානයකට ගෙන ගිය අතර දැන් මට පොදු යතුරු සත්‍යාපනය සමඟ සම්බන්ධ විය හැකිය.

මම මේ ප්රශ්නය එම තිබූ අතර මා වෙනුවෙන් විසඳුමක් සකස් විය UsePAMකිරීමට no. බලන්න, PasswordAuthenticationසකසා තිබුණත් no, ඔබට තවමත් ලැබෙනු ඇත keyboard-interactive, මගේ නඩුවේදී මගේ දේශීය ssh වැඩසටහන කිසියම් හේතුවක් නිසා ඒ සඳහා පෙරනිමියෙන් සිටියි.

එකම තත්වයක් ඇති ඕනෑම කෙනෙකුට උපකාර කිරීම සඳහා අමතර පසුබිම: මම ඩ්‍රොප්බයර් ධාවනය කරන ධාරකයක සිට ධාවනය වන OpenSSH වෙත සම්බන්ධ කරමි. දුරස්ථ යන්ත්‍රය සමඟ PasswordAuthenticationසහ UsePAMදෙකම සකසා noඇති අතර, මම ඇතුළු කළහොත් පහත පණිවිඩය ලැබෙනු ඇත ssh user@server:

ssh: Connection to user@server:22 exited: Disconnect received

හැඳුනුම් ගොනුව සමඟ සැපයීම -i, සියල්ල අපේක්ෂිත පරිදි ක්‍රියාත්මක වේ.

මෙහි තව ටිකක් තොරතුරු තිබිය හැකිය.

සේවාදායකයේ:

$ ls -lh /home
$ sudo chmod 700 /home/$USER

ඒ directory permission issue. එය සේවාදායකයේ 777 ක් විය I changed it back to 700. සේවාදායකයට පිටපත් කිරීමෙන් පසුව පවා මෙය fixedමගේ ගැටලුවයි .ssh password less login failure$USER/.ssh/id_rsa.pub$USER/.ssh/authorized_keys

තවත් විකල්පයක් @Jagadish ගේ ක ප්රභේදයකි පිළිතුර කිරීමට: straceමෙම ssh daemon.

එයට සැලකිය යුතු වාසියක් ඇත, අපට sshd නැවැත්වීමට අවශ්‍ය නැත, යමක් නරක අතට හැරුණහොත් සම්පූර්ණ අගුලු දැමීමේ ප්‍රති result ලය කුමක් විය හැකිද?

පළමුව, අපි ප්‍රධාන sshd ක්‍රියාවලියේ pid සොයා ගනිමු. මෙහිදී අපට එය දැක ගත හැකිය a pstree -pa|less.

  |-sshd,633 -D  <-- THIS IS WHAT WE WANT!
  |   `-sshd,21973   
  |       `-sshd,21996    
  |           `-bash,22000
  |               `-screen,638 -r

දැනගත් පසු, පිඩ් 633 straceබව, එහි දරුවන් අනුගමනය කරමින් අපට එය කළ හැකිය :

strace -p 633 -s 4096 -f -o sux

මෙහි ප්‍රති result ලය වනුයේ මෙම sshd සහ එහි ළමා ක්‍රියාදාමයන් සිදු කර ඇති සෑම දෙයක්මsux දේශීය නාමාවලියෙහි නම් කර ඇති ගොනුවට සම්බන්ධ කිරීමයි.

ඉන්පසු ගැටළුව ප්රජනනය කරන්න.

එහි විශාල වශයෙන් කර්නල් ඇමතුම් ලොග් ලැයිස්තුවක් ඇත, එය බොහෝ දුරට අපට තේරුම්ගත නොහැකි / අදාළ නොවේ, නමුත් සෑම තැනකම නොවේ. මගේ නඩුවේ, වැදගත් දෙය මෙයයි:

6834  sendto(4, "<38>Jan 15 18:49:21 sshd[6834]: User cica not allowed because account is locked\0", 84, MSG_NOSIGNAL, NULL, 0) = 84

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

එය තවමත් විසඳුමක් නොවේ - දැන් අපට ගූගල් කිරීමට අවශ්‍යයි, sshd සම්බන්ධයෙන් "අගුළු දැමූ ගිණුමක්" යන්නෙහි තේරුම කුමක්ද? එය බොහෝ දුරට සුළු /etc/passwd, /etc/shadowමායාකාරියන් වනු ඇත, නමුත් වැදගත් දෙය සිදු කරනු ලැබේ - ගැටළුව අද්භූත දෙයක් නොව පහසුවෙන් නිදොස් කළ හැකි / ගොග්බෙල් කළ හැකි එකකි.

මගේ නඩුවේදී මට සියලු අවසරයන් නිවැරදිව තිබූ අතර -vvv ධජය සමඟ ssh ධාවනය කරන විට පවා ගැටලුව කුමක්දැයි මට සිතාගත නොහැකි විය.

එබැවින් මම දුරස්ථ ධාරකයේ නව සහතිකයක් ජනනය කළෙමි

ssh-keygen -t rsa -C "your_email@example.com"

සහ ජනනය කරන ලද යතුරු දේශීය යන්ත්‍රයට පිටපත් කර දුරස්ථ ධාරකයේ පොදු යතුර ~ / .ssh / Author_keys වෙත එක් කළේය

cat id_rsa.pub >> authorized_keys

දුරස්ථ ධාරක යන්ත්‍ර සම්බන්ධතාවයෙන් ජනනය කළ යතුරු භාවිතා කිරීම දැන් ක්‍රියාත්මක වේ. එබැවින් වෙනත් විසඳුම් අසමත් වුවහොත් මෙය උත්සාහ කළ යුතු තවත් දෙයකි.

මගේ තත්වය නම් backupbot, මගේ ප්‍රාථමික ගිණුම නිර්මාණය කිරීමෙන් පසුව, පරිශීලකයෙකු නිර්මාණය කළ NAS සේවාදායකයක් මා සතුව backupbotතිබීමයි , එමඟින් මුලින් පරිශීලකයා නිර්මාණය කිරීම සඳහා ලොග් වීමට හැකි විය . අත ගගා පසු sudo vim /etc/ssh/sshd_config, සහ නිර්මාණය backupbotපරිශීලක, vimඅවම වශයෙන් උබුන්ටු 16,04 මත, නිර්මාණය, සහ ඔබේ මත පදනම් හැකි ~/.vimrcconfig, එය swap ගොනුවක් ඔබේ විම් සැසිය ගේ සංස්කරණය ඉතිරි /etc/ssh/sshd_config.

තිබේදැයි පරීක්ෂා කර බලන්න: /etc/ssh/.sshd_config.swpපවතින අතර, එය ඉවත් කර sshdඩීමන් නැවත ආරම්භ කරන්නේ නම් :

$ sudo rm /etc/ssh/.sshd_config.swp
$ sudo service sshd restart

මෙය මගේ ප්‍රශ්නය ඉන්ද්‍රජාලිකව විසඳීය. මම මීට පෙර මගේ සියලු අවසරයන් සහ පොදු සහ පෞද්ගලික යතුරු වල RSA ඇඟිලි සලකුණු පවා පරීක්ෂා කර ඇත්තෙමි. මෙය අමුතු හා බොහෝ විට දෝෂයකි sshd, විශේෂයෙන් මෙම අනුවාදය:

OpenSSH_7.4p1 උබුන්ටු -10, OpenSSL 1.0.2g 1 මාර්තු 2016