使用變量的值作為scp，ssh等的密碼，而不是每次都提示用戶輸入

Question

AFAIK，命令ssh或scp沒有/接受密碼參數。 否則我可以將密碼保存在shell變量中，並可能擺脫輸入密碼提示。 如果我在shell腳本中編寫scp命令，則會提示用戶輸入密碼。 我的腳本中有多個ssh和scp命令，我不希望用戶每次都輸入密碼。 我更喜歡在開頭的shell變量中保存密碼（通過詢問密碼一次），然后將其用於每個ssh或scp。

我在這個問題中讀到了“公鑰識別”。 它與我正在尋找的解決方案有關嗎？

更新
我讀了如何在shell腳本中使用ssh命令？ 為什么在命令行上指定密碼是不安全的。 使用expect是否也存儲密碼並且是世界可見的（使用ps aux ）？ 這是使用expect的安全問題嗎？

進一步說明
為了進一步說清楚，我正在編寫這個shell腳本來自動執行代碼和數據庫備份，執行代碼上載，運行必要的數據庫查詢，完成從開發人員系統到LAMP項目的新版本發布所需的所有內容。遠程直播服務器。 我的shell腳本將存在於每個開發人員實例中項目的主代碼庫中。

需求

• 我希望所有開發人員（可能都是從不同的遠程系統工作）知道SSH / FTP密碼，只能在運行時輸入ssh / ftp密碼才能使用shell。 我更喜歡密碼是ssh / ftp密碼

  注意 -我不希望其他不知道SSH密碼的開發人員能夠使用它（所以我猜公鑰驗證不起作用，因為它將密碼存儲在系統中）。

• 我不希望任何命令行解決方案將密碼存儲在系統的某些日志中，並且可以使用ps aux或其他東西進行全局可見。

開放賞金
從目前為止的所有答案以及我對這些解決方案的分析來看，除了公鑰認證之外，其他所有其他都是不安全的。 我還不確定使用expect是不安全的。 我認為這對我來說是正確的解決方案。 在這種情況下，我在嘗試執行此操作時遇到命令未找到錯誤，因為已經對其中一個答案進行了評論。

來自http://www.debianadmin.com/sshpass-non-interactive-ssh-password-authentication.html -

首先，sshpass的用戶應該意識到ssh只能以交互方式獲取密碼並不是沒有理由的。 安全地存儲密碼幾乎是不可能的，sshpass的用戶應該考慮ssh的公鑰認證是否提供相同的最終用戶體驗，同時減少麻煩和更安全。

那么，是不是可以通過輸入ssh / ftp密碼安全地運行多個ssh，scp命令（如果在運行時只有一次？請再次閱讀我的需求部分。

此外，任何人都可以解釋這個 -

特別是，人們編寫滿足的程序是為了傳達上述要點。建議密碼以編程方式使用匿名管道並使用-d選項將管道的讀取端傳遞給sshpass。

這是否意味着什么是可能的？

Answer 1

實際上，你肯定想要研究設置ssh密鑰，而不是在bash腳本中保存密碼。 如果密鑰是無密碼的，則ssh / scp不需要用戶輸入。 您只需將其設置為在兩端使用密鑰，然后保護通信。

但是，如果我不這樣說的話，我會陷入地獄。 許多人認為無密碼ssh密鑰是Bad Idea（TM）。 如果有人拿到鑰匙，那么就可以完全進入。 這意味着您依賴其他安全措施（如文件權限）來保護您的密碼安全。

另外，看看ssh-agent。 它允許您進行設置，以便您擁有受密碼保護的ssh-key，但您只需要輸入一次，它將為您管理密鑰的密碼並在必要時使用它。 在我家的linux機器上，我已經設置ssh-agent在我的.xinitrc文件中運行，這樣它就會提示我一次，然后啟動X. YMMV。

更新：
關於您的要求，密碼保護的公鑰認證+ ssh-agent似乎仍然適合。 只有熟悉SSH / FTP密碼的開發人員才能啟動ssh-agent，輸入密碼，ssh-agent將管理會話其余部分的公鑰密碼，從不再需要交互。

當然，它如何存儲它完全是另一回事。 IANASE，但是有關使用ssh-agent的安全問題的更多信息，我發現賽門鐵克的文章內容非常豐富： http ： //www.symantec.com/connect/articles/ssh-and-ssh-agent

“ssh-agent創建一個unix域套接字，然后在此套接字上偵聽來自/ usr / bin / ssh的連接。它依賴於簡單的unix權限來阻止訪問此套接字，這意味着您放入代理的任何密鑰任何可以連接到此套接字的人都可以使用。[即.root]“...

“但是，[..]它們僅在代理運行時可用 - root可以使用您的代理對其他系統上的帳戶進行身份驗證，但它不能直接訪問密鑰本身。這意味着密鑰不能從機器上取下並無限期地從其他地方使用。“

希望你不是在嘗試使用不受信任的root系統的情況下。

Answer 2

正確的方法如下：

1. 確保所有用戶都使用ssh-agent（現在這是大多數Linux系統的默認設置）。 您可以檢查它運行以下命令：

   echo $ SSH_AUTH_SOCK

   如果該變量不為空，則表示用戶正在使用ssh-agent。

2. 為每個用戶創建一對身份驗證密鑰，確保它們受非空密碼短語保護。

3. 在遠程主機上安裝身份驗證密鑰的公共部分，以便用戶可以在那里登錄。

4. 你完成了！

現在，用戶第一次想要從某個會話登錄到遠程計算機時，必須輸入其私鑰的密碼。

在稍后來自同一會話的登錄中，ssh-agent將代表用戶提供解鎖的密鑰以進行身份​​驗證，而不需要再次引入密碼。

Answer 3

您可以使用expect將密碼傳遞給ssh執行此操作，或者如上所述已經使用公鑰認證，如果這是可行的選項。

Answer 4

啊。 我為此努力了。 這是我得到的：

在腳本開頭附近使用此代碼以靜默方式獲取ssh密碼：

read -p "Password: " -s SSHPASS # *MUST* be SSHPASS
export SSHPASS

然后使用sshpass為ssh如下：

sshpass -e ssh username@hostname

希望有所幫助。

Answer 5

對於那些設置密鑰對不是一個選項且絕對需要執行密碼驗證的人，請使用$SSH_ASKPASS ：

SSH_ASKPASS - 如果ssh需要密碼短語，它將從當前終端讀取密碼短語，如果它是從終端運行的話。 如果ssh沒有與之關聯的終端但是設置了DISPLAY和SSH_ASKPASS，它將執行SSH_ASKPASS指定的程序並打開X11窗口來讀取密碼。 從.xsession或相關腳本調用ssh時，這尤其有用。 （請注意，在某些計算機上，可能需要重定向/ dev / null中的輸入才能使其正常工作。）

例如：

$ echo <<EOF >password.sh
#!/bin/sh
echo 'password'
EOF
$ chmod 500 password.sh
$ echo $(DISPLAY=bogus SSH_ASKPASS=$(pwd)/password.sh setsid ssh user@host id </dev/null)

另請參閱告訴SSH使用圖形提示輸入密鑰密碼 。

Answer 6

對於密碼驗證，如您在說明中所述，您可以使用“sshpass”。 在Ubuntu上，您可以安裝為“sudo apt-get install sshpass”。

對於公鑰/私鑰對基本身份驗證，

• 首先使用“ssh-keygen”生成密鑰
• 然后使用“ssh-copy-id username @ remote-machine”將密鑰復制到遠程計算機

復制后，后續登錄不應要求輸入密碼。

Answer 7

期待是不安全的

它驅動一個交互式會話。 如果您要通過密碼傳遞密碼，那么在命令行上鍵入密碼與使用密碼沒有什么不同， 只是期望腳本會從某個地方檢索密碼。 它通常是不安全的，因為人們會將密碼放在腳本或配置文件中。

它也是眾所周知的脆弱因為它等待特定輸出作為輸入的事件機制。

SSH代理

如果這是一個總是手動驅動的腳本，ssh-agent是一個很好的解決方案。 如果有人將登錄以驅動腳本的執行，那么代理是一個很好的方法。 它不是一個很好的自動化解決方案，因為代理意味着一個會話。 您通常不會啟動會話以自動啟動腳本（即.cron）。

ssh命令鍵

Ssh命令鍵是自動解決方案的最佳選擇。 它不需要會話，並且命令鍵將服務器上運行的內容限制為僅在authorized_keys中指定的命令。 它們通常也沒有密碼設置。 如果您有數千台服務器，這可能是一個難以管理的解決方案。 如果您只有一些，那么設置和管理非常簡單。

服務ssh帳戶

我還看到了使用無密碼服務帳戶的設置。 而不是使用tehh authorized_keys文件中的命令條目，而是使用替代機制來限制訪問/命令。 這些解決方案通常使用sudo或限制shell。 但是，我認為正確管理這些更復雜，因此往往更不安全。

主機托管自動身份驗證

您還可以設置主機2主機自動身份驗證，但有很多事情要寫入才能正確執行此操作。 從正確設置網絡，使用堡壘主機進行主機密鑰傳播，正確的ssh服務器配置等。因此，這不是推薦的解決方案，除非您知道自己在做什么，並且具備正確設置所有內容的能力和能力並保持這樣。

Answer 8

今天，我通過crontab在bash腳本中執行此操作的唯一方法就是：

eval $(keychain --eval --agents ssh id_rsa id_dsa id_ed25519)
source $HOME/.keychain/$HOSTNAME-sh

這是因為ssh代理已經運行並且需要密碼短語。

Answer 9

是的，您需要pubkey身份驗證。

Answer 10

ssh ， ssh-keygen ， ssh-agent ， ssh-add和遠程系統上/etc/ssh_config的正確配置是保護遠程系統訪問的必要因素。

首先，需要使用ssh-keygen生成私有/公共密鑰對。 密鑰生成過程的結果是兩個文件： 公鑰和私鑰 。

通常存儲在~/.ssh/id_dsa.pub （或~/.ssh/id_rsa.pub ，用於RSA加密）的公鑰文件需要復制到將授予用戶遠程訪問權限的每個遠程系統。

私鑰文件應保留在原始系統上，或保留在從采購系統引用的便攜式USB（“拇指”）驅動器上。

生成密鑰對時，使用密碼短語來保護密碼對免受未經過身份驗證的用戶的使用。 在第一次建立ssh會話時，只能使用密碼解鎖私鑰。 解鎖后，原始系統可以使用ssh-agent記住解鎖的私鑰。 某些系統（例如，Mac OS X）將在登錄過程中自動啟動ssh-agent ，然后執行自動ssh-add -k ，使用先前存儲在keychain文件中的密碼來解鎖您的私有ssh密鑰。

與遠程系統的連接可以是直接的，也可以通過ssh 網關代理。 在前一種情況下，遠程系統僅需要具有與可用的未鎖定私鑰對應的公鑰。 在使用網關的情況下，中間系統必須具有公鑰以及最終目標系統。 另外，原始的ssh命令需要通過~/.ssh/config或命令選項-A來啟用代理轉發 。

例如，要通過名為“gw”的ssh網關系統登錄到遠程系統“app1”，可以執行以下操作：

ssh -At gw ssh -A app1

或者將以下節放在~/.ssh/config文件中：

Host app1
ForwardAgent = yes
ProxyCommand = ssh -At gw nc %h %p 2>/dev/null

它在ssh網關上運行“net cat”（aka nc ）作為網絡管道。

上面的設置將允許非常簡單的ssh命令，即使通過ssh網關：

ssh app1

有時候，比終端會話更重要的是用於安全地移動文件的scp和rsync命令。 例如，我使用類似的東西將我的個人環境同步到遠程系統：

rsync -vaut ~/.env* ~/.bash* app1:

如果沒有配置文件和nc proxy命令，rsync會變得更復雜：

rsync -vaut -e 'ssh -A gw' app1:

除非正確配置了遠程系統的/etc/ssh_config否則這些都不會正常工作。 一種這樣的配置是通過ssh刪除“root”訪問，這改善了當幾個員工可以執行根功能時的跟蹤和責任。

在無人參與的批處理腳本中，需要為運行腳本的非root用戶標識生成特殊的ssh密鑰對。 與ssh會話管理一樣，批處理用戶ssh密鑰對需要以類似方式部署，公鑰復制到遠程系統，私鑰駐留在源系統上。

根據系統管理員和/或開發人員的需要，可以使用密碼鎖定私鑰或解鎖私鑰。 即使在root下運行的腳本中，使用特殊批處理ssh密鑰的方法是在所有遠程訪問命令中使用“ ssh -i ~/.ssh/id_dsa ”命令選項。 例如，要使用特殊的“批處理”用戶訪問權限復制腳本中的文件：

rsync -vaut -e 'ssh -i ~batch/.ssh/id_dsa -A gw' $sourcefiles batch@app2:/Sites/www/

這會導致rsync使用特殊的ssh命令作為遠程訪問shell。 特殊情況ssh命令使用“批處理”用戶的DSA私鑰作為其標識。 將使用“批處理”用戶訪問rsync命令的目標遠程系統。