在sshpass軟件包的同一行上發送SSH密碼

對於那些使用 SSH,也就是說,我們中那些每天需要不斷訪問遠程計算機或服務器的人,到了被輸入密碼煩死的地步,那就是:

  1. 鍵入終端:ssh user @ server
  2. 等待幾秒鐘
  3. 我們要連接的服務器將要求輸入密碼
  4. 輸入密碼並按[Enter]後,我們將訪問遠程服務器

現在我的問題是,只鍵入不是更簡單嗎?:

sshpass -p «PASSWORD» ssh root@servidor

例如,假設用戶是 ,服務器是: 開發。desdelinux淨 密碼是 il ...那麼該行將是:

sshpass -p xunil ssh root@dev.desdelinux.net

為此,我們只需安裝軟件包 密碼於Debian / Ubuntu 或衍生品將與 須藤apt-get 安裝sshpass 同時在 ArchLinux的 或衍生品就足以 須藤pacman -S sshpass

如果我們要指定端口(因為SSH不在端口22上) 我們增加 -p«端口» ...即假設它是端口9122:

sshpass -p xunil ssh root@dev.desdelinux.net -p 9122

為了簡化所有這些 我們可以創建別名例如,執行server1時,將執行整行以通過SSH連接到server1(sshpass -p密碼用戶@ server1)或類似的內容,因此我們也省去了太長的線😉

無論如何,我希望這對您有用。

順便說一句,當我們通過SSH訪問時避免寫密碼的另一種方法是使用 公鑰和私鑰.

問候


發表您的評論

您的電子郵件地址將不會被發表。 必填字段標有 *

*

*

  1. 負責數據:MiguelÁngelGatón
  2. 數據用途:控制垃圾郵件,註釋管理。
  3. 合法性:您的同意
  4. 數據通訊:除非有法律義務,否則不會將數據傳達給第三方。
  5. 數據存儲:Occentus Networks(EU)託管的數據庫
  6. 權利:您可以隨時限制,恢復和刪除您的信息。

  1.   linuxito 他說:

    抱歉,這是一個可怕的安全異常! 您的密碼卡在腳本,純文本文件,bash歷史記錄等中。
    為此,openssh支持使用RSA的公鑰身份驗證。
    由於這種類型的實踐(由自稱“管理員”的主體實施),因此計算機安全性非常高。
    問候。

    1.    拉夫 他說:

      讓我們來看看。 是的,這是一個安全問題,但這並不意味著無論是不是管理員的“主題”都必須使用此方法。 該方法存在並在需要在安全性不成問題的環境中使用時顯示。 在他們向您出售刀的商店中,您可以決定是否使用它來切菜或殺死某人。

      1.    linuxito 他說:

        我理解您的立場,但是很抱歉,在如此享有盛名的博客中,他們倡導這種做法,這幾乎就像是“為糟糕的系統管理道歉”。
        擁抱!

        1.    拉夫 他說:

          我還是不明白問題是什麼🙁

          正如我們在各個方面都討論了“如何獲得更多安全性”一樣,我們也可以討論其他“不太安全”的主題。 我們的目標是提供信息,由您決定如何處理。 另外,相信我,最偏執的關於安全性的文章的作者不能相信,在系統管理方面,它不會做這種事情。

          問候😉

          1.    linuxito 他說:

            首先,當我說“由自稱“管理員”的主題實現”時,我沒有任何時間提及該文章的作者,我不明白為什麼他們如此容易受到影響。

            從我的角度來看,問題在於該工具違背了所有良好的安全慣例。 我相信,從GNU / Linux社區中,我們必須保持我們寶貴的操作系統盡可能的安全。 我的意思是,我不想看到GNU / Linux變成Windows(出於安全考慮)。

            不幸的是,許多新手管理員不知道正確的處理方法,最終在關鍵系統上使用了這些工具。

            當然,您有權發布想要的內容,但是我重複一遍,對不起,此博客(西班牙語中最重要的博客)為威脅安全的工具提供了地方。

            您好!

            1.    拉夫 他說:

              並給胡安娜與盆地。 確切地說,因為它是參考博客,所以我們希望提供各種信息。 我了解這一點:

              用戶到達並詢問: 如何在不要求密碼的情況下通過SSH連接到服務器?
              他們在任何論壇上回答他: 不,這是一個安全問題,沒有人這樣做。

              即使知道,使用者也沒有告訴他為什麼這是一個安全問題。糟糕,非常糟糕,你知道如何做事是件好事,這就是為什麼 Desdelinux:

              用戶到達並詢問: 如何在不要求密碼的情況下通過SSH連接到服務器?
              我們寫一篇文章說: 您可以使用此方法,它可以這種方式工作,但並不安全。 最安全的方法是使用另一種方​​法。

              您認為哪一個更好?


            2.    linuxito 他說:

              好吧,我尊重你的姿勢。 最好的祝福!!


            3.    KZKG ^ Gaara 他說:

              SSHPass實際上並不威脅安全,無論如何,威脅安全的人都是濫用安全的用戶。
              例如,這是一個很好的示例,SSHPass不僅用於我在帖子中評論,還可以用於(例如)OpenSSH-Server破解: http://paste.desdelinux.net/4810

              該應用程序無非就是一個應用程序,使用該應用程序將導致失敗或不損害安全性。

              關於緊張或易感,也許這就是您說的那樣(或者閱讀很難正確理解),但我認為這是針對我的,如果不是,我對此表示歉意。

              PS:當然會有幾個人會找到我所寫的有趣甚至有趣的LOL腳本!


            4.    linuxito 他說:

              好的,我很高興我們達成協議。 乾杯!!


    2.    KZKG ^ Gaara 他說:

      我曾經說過這種方法比使用公鑰和私鑰更安全嗎?

      在另一篇文章中,我已經分享瞭如何使用它們[1],現在我僅說明實現相同或相似事物的另一種方法。

      每個人都使用最適合他們的一種,他們更喜歡的一種。 在這裡,我只是簡單地解釋了sshpass可以使用的一種用法,另一種可能是通過Bash腳本通過使用字典來破解SSH……但是,這只是另一種用法。

      我再說一遍,我只分享與GNU / Linux有關的知識。 SSHPass在任何情況下都不是理想的選擇,但它具有實用性,請不要猶豫。

      順便說一句,指的是:(由自稱“管理員”的主體實現)...呵呵...呵呵...我不想發表評論,我沒有向任何人證明,更不用說你是我的朋友了,你沒有最多對我是誰的遙遠想法遠不如我所知道的😉

      [1] https://blog.desdelinux.net/ssh-sin-password-solo-3-pasos/

      1.    linuxito 他說:

        別緊張,在我的領域裡,我認識一些人,他們的工作都基於Google,並且在解決問題時會復制並粘貼此類內容。 然後,安全管理員會在檢測到此類異常時“將車輪放入車輪”。 乾杯!!

      2.    MSX 他說:

        放鬆男人,這不值得worth

  2.   西克茲 他說:

    可以,但是密碼已在使用的命令中註冊。 出於安全原因,不應這樣做...

    1.    大衛 他說:

      這就是我在閱讀帖子時的想法

    2.    KZKG ^ Gaara 他說:

      將此添加到我們的.bashrc中將不會保存sshpass相關命令:
      HISTIGNORE='sshpass *'

      我將發表一篇有關如何忽略命令的文章,以便它們不會很快保存在bash歷史記錄中:)

      1.    天使之刃 他說:

        不保存命令的另一種方法是始終在命令前放置一個空格。 ^ __ ^

  3.   伊格納西奧 他說:

    我認為使用密鑰通過SSH進行連接而不需要輸入密碼更為安全。

    另一方面,創建用於保存密碼的完整命令別名可能是安全問題。

  4.   齋藤 他說:

    如果在我看來,計算機安全性方面的缺陷,但是我們將確保它們沒有保存在bash歷史記錄中,那麼我們要做的問題就不多了(除了別名會很大),就像elav一樣說在商店裡賣給我們刀,我們就是那些會看到用什麼的人

  5.   特魯科22 他說:

    有趣,但最好使用您在另一個條目中顯示的公鑰和私鑰。

  6.   MSX 他說:

    @KZKG
    我認為這更實用-更安全! -將RSA / ECDSA密鑰與密鑰鏈(SSH代理)一起使用以進行自動身份驗證。
    就我而言,我使用的是SSH鑰匙串到鑰匙串,該鑰匙串是由Funtoo的人開發的,效果很好,使用的資源很少,並且非常安全:
    http://www.funtoo.org/Keychain

    例如:

    j:0 ~ > AliasSearch ssh
    # SSH management
    alias SSHCOPYIDecdsa='ssh-copy-id -i ~/.ssh/id_ecdsa.pub'
    alias SSHCOPYIDrsa='ssh-copy-id -i ~/.ssh/id_rsa.pub'
    alias SSHKEYGENecdsa='ssh-keygen -t ecdsa -b 521 -C "$(whoami)@$(hostname)-$(date -I)"'
    alias SSHKEYGENrsa='ssh-keygen -t rsa -b 4096 -C "$(whoami)@$(hostname)-$(date -I)"'

    格式:
    SSHKEYGEN {ecdsa,rsa}
    SSHCOPYID {ecdsa,rsa}用戶@ {server,ip}


    # SSH servers
    alias SERVER1mosh='eval $(keychain --eval --agents ssh -Q --quiet id_ecdsa) && mosh -p # usr1@server1'
    alias SERVER1='eval $(keychain --eval --agents ssh -Q --quiet id_ecdsa) && ssh -v -p # usr1@server1.local'
    alias SERVER101='eval $(keychain --eval --agents ssh -Q --quiet id_ecdsa) && ssh -v -p # usr1@[direc. ip].101'

    其中:
    -p#:端口
    usr1 @ server1:用戶@ AVAHI服務器
    usr1@server1.local:user @ AVAHI服務器(取決於某些系統中服務器的配置方式,必須添加後綴.local)
    usr1 @ [addr。 ip] .101:固定的ip地址。

    / etc / ssh / sshd_config: http://paste.chakra-project.org/4974/
    〜/ .ssh /配置: http://paste.chakra-project.org/4975/
    操作系統:Arch Linux / Chakra

    希望它能為您服務,問候!

    1.    KZKG ^ Gaara 他說:

      實際上,我使用密鑰而不是SSHPass來訪問服務器...當我需要一種執行此腳本的方法時,我發現了SSHPass: http://paste.desdelinux.net/4810

      但是...好吧,我想與所有人共享SSHPass,但是顯然我不能在這裡放一個腳本,該腳本允許使用字典來嘗試違反OpenSSH-Server HAHAHA!

      1.    MSX 他說:

        «[…]我無法在此處放置允許通過字典嘗試破壞OpenSSH-Server HAHAHA的腳本!”
        但是為什麼不呢!
        黑客與破解不是學習良好安全實踐[0]的一部分嗎?
        拜託,繼續吧!

        [0]用單詞來表示與它們的字面意思完全相反的詞不是很好嗎? 破解語言學!!! ;-D

      2.    古茲曼網 他說:

        嗨,我收到此錯誤:

        它正在使用root用戶在端口192.168.20.11上測試22的密碼
        cat:con-letters.txt:沒有這樣的文件或目錄

        我創建的具有letters.txt的文件?

        問候

  7.   愛德華多 他說:

    之所以不會這樣做,是因為密碼以純文本形式存儲在bash_history中,除此之外還可以通過其他方式找到它。 因此,ssh不會要求您輸入密碼,正確的方法是使用“公鑰和私鑰”。

  8.   奧斯卡·梅薩(Oscar Meza) 他說:

    我使用RSA遠程連接到我的服務器,即使如此,我也認為連接到我們不需要如此強大安全性的計算機是一個很好的工具,謝謝!

  9.   Nelson 他說:

    基烏

  10.   尼布甲尼撒 他說:

    為什麼最好不公開我的密碼,以便任何人都可以使用?

  11.   馬里奧 他說:

    優秀,好! 和西班牙語。

  12.   貢薩洛·賈瑞裡 他說:

    一如既往的好文章,人們總是抱怨而不是感謝,儘管這種方法並不安全,但要取決於您在何處以及如何使用它,非常感謝🙂