故障排查:SSH連接失效的四大常見原因
譯文【51CTO.com快譯】作為DevOps或者IT專業(yè)人士，人們往往困擾于為何無法通過SSH接入服務(wù)器。這種情況時有發(fā)生，且相當(dāng)令人頭痛。
在今天的文章中，我們將嘗試匯總各類常見SSH故障原因，從而幫助大家更為順暢地加以解決。
1.我們的SSH公鑰未被注入至服務(wù)器
以密碼形式實現(xiàn)的SSH非常危險。目前，絕大多數(shù)服務(wù)器都僅接受以密鑰文件為載體的SSH。以下為具體流程：
我們生成一個SSH密鑰對(也可以更進(jìn)一步，以密碼保護(hù)私鑰)。
將SSH公鑰發(fā)送至服務(wù)器管理者處。
管理員將我們的SSH公鑰進(jìn)行注入(通常為~/.ssh/authorized_keys)。
之后即可使用SSH。
好了，下面正式來看各類最常見的SSH故障!
- denny@laptop:/# ssh root@www.dennyzhang.com
- Permission denied (publickey).
以上故障信息可能存在兩種原因：
(1). 私鑰不具備登錄權(quán)限。 公鑰未被正確注入或者公鑰已經(jīng)丟失。
注意：如果暫時聯(lián)系不到運維/DevOps人員，可先考慮團(tuán)隊中還有誰能夠進(jìn)行SSH接入。事實上，任何可以SSH接入的人員都可執(zhí)行此類變更。
(2). 本地SSH公鑰與私鑰未正確配對。
在連接之前，SSH會檢查我們的公鑰與私鑰是否正確進(jìn)行了配對。如果沒有，其會以靜默方式拒絕使用私鑰。沒錯，靜默方式。
這種錯誤很可能源自某些指生成的自動化腳本。另外，如果我們只使用一條未匹配公鑰的有效私鑰，并不會引發(fā)錯誤。
2.防火墻阻止我們進(jìn)行連接
出于安全考量，人們可能會執(zhí)行一項較為嚴(yán)格的防火墻策略，這意味著只有特定IP能夠建立SSH連接。
- denny@laptop:/# ssh root@www.dennyzhang.com
- ssh: connect to host www.dennyzhang.com port 22: Connection refused
- # Confirm with telnet. Usually it shall connect in seconds
- denny@laptop:/# telnet www.dennyzhang.com
- Trying 104.237.149.124...
遇到上述情況，大家可能希望馬上尋求幫助——先別急。
人們可能重新配置SSHD以監(jiān)聽其它端口。您是否確定其為端口22?另外，也應(yīng)當(dāng)再次檢查服務(wù)器IP與DNS名稱。
在確認(rèn)之后，與DevOps取得聯(lián)系。這就引發(fā)了此類故障的第二種可能原因：SHHD并未上線運行。雖然很少見，但這一問題確實可能出現(xiàn)。這時DevOps與運維人員需要立即采取行動。
3. 主機(jī)密鑰檢查失敗
當(dāng)初次看到以下警報時，大家可能感到困惑。簡單來說，其能夠幫助我們避免中間人攻擊。
- denny@laptop:/# ssh root@www.dennyzhang.com
- @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
- @ WARNING: POSSIBLE DNS SPOOFING DETECTED! @
- @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
- The ECDSA host key for [www.dennyzhang.com]:22 has changed,
- and the key for the corresponding IP address [45.33.87.74]:22
- is unknown. This could either mean that
- DNS SPOOFING is happening or the IP address for the host
- and its host key have changed at the same time.
- @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
- @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
- @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
- IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
- Someone could be eavesdropping on you right now (man-in-the-middle attack)!
- It is also possible that a host key has just been changed.
- The fingerprint for the ECDSA key sent by the remote host is
- 37:df:b3:af:54:a3:57:05:aa:32:65:fc:a8:e7:f9:3a.
- Please contact your system administrator.
- Add correct host key in /root/.ssh/known_hosts to get rid of this message.
- Offending ECDSA key in /root/.ssh/known_hosts:2
- remove with: ssh-keygen -f "/root/.ssh/known_hosts" -R [www.dennyzhang.com]:22
- ECDSA host key for [www.dennyzhang.com]:22 has changed and you have requested strict checking.
- Host key verification failed.
每臺服務(wù)器都擁有一條指紋。如果該服務(wù)器被重新配置或者單純被更換為另一臺不同服務(wù)器，則指紋亦將有所變化。在成功登錄之后，我們的筆記本會本地保存服務(wù)器指紋。在下一次登錄時，其將首先進(jìn)行比較。如果指紋不匹配，我們就會收到以上警報。
如果我們砍服務(wù)器最近進(jìn)行過重新配置，則可忽略該警報。從~/.ssh/known_hosts中移除此入口，或者直接清空該文件。大家甚至可以關(guān)閉一切SSH主機(jī)密鑰檢查(當(dāng)然，不建議采取這種方法)。
4. SSH密鑰文件模式存在問題
SSH密鑰文件具備自我保護(hù)屬性，這意味著其無法被隨意打開。該文件模式為0600或者0400。
- denny@laptop:/# ssh -i id_rsa root@www.dennyzhang.com
- @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
- @ WARNING: UNPROTECTED PRIVATE KEY FILE! @
- @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
- Permissions 0644 for 'id_rsa' are too open.
- It is required that your private key files are NOT accessible by others.
- This private key will be ignored.
- bad permissions: ignore key: id_rsa
- Permission denied (publickey).
大家可以使用-v輸出詳盡信息：ssh -v $user@$server_ip。
原文標(biāo)題：4 Reasons Why SSH Connections Fail，作者：Denny Zhang
【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】
