Ipadala ang SSH password sa parehong linya kasama ang sshpass package

Para sa atin na gumagamit ng SSH, iyon ay, ang mga sa atin na kailangang i-access ang mga malayong computer o server na patuloy sa ating pang-araw-araw na buhay na umabot sa punto na magsawa na sa pagta-type ng mga password, ito ay ang:

  1. Mag-key sa isang terminal: ssh user @ server
  2. Maghintay ng ilang segundo
  3. Ang server kung saan nais naming kumonekta ay hihilingin ang password
  4. Kapag inilagay na namin ang password at pinindot ang [Enter] pagkatapos ay maa-access namin ang remote server

At ngayon ang aking katanungan, hindi ba mas simple na mag-type lamang?:

sshpass -p «PASSWORD» ssh root@servidor

Halimbawa, ipagpalagay na ang gumagamit ay ugat, ang server ay: dev.desdelinux. Net at ang password ay xunil ... kung gayon ang linya ay magiging:

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

Upang makamit ito kailangan lang namin i-install ang package sshpassSa Debian / Ubuntu o mga derivatives ay makakasama sudo apt-get i-install ang sshpass Samantala sa Archlinux o derivatives ay sapat na sa sudo pacman -S sshpass

Kung nais naming tukuyin ang port (dahil wala sa port 22 ang SSH) idagdag namin -p «PORT» ... iyon ay, sa pag-aakalang ito ay port 9122:

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

Upang gawing mas simple ang lahat ng ito maaari kaming lumikha ng mga aliasHalimbawa, kapag nagpapatupad ng server1, ang buong linya ay naisasagawa upang kumonekta ng SSH sa server1 (sshpass -p password ng gumagamit @ server1) o isang bagay na katulad, kaya nakakatipid din kami ng paglalagay ng masyadong mahabang linya 😉

Gayunpaman, sana ay kapaki-pakinabang ito sa iyo.

Sa pamamagitan ng paraan, isa pang paraan upang maiwasan ang pagsulat ng password kapag na-access namin sa pamamagitan ng SSH ay sa pamamagitan ng paggamit pampubliko at pribadong mga susi.

Regards


Iwanan ang iyong puna

Ang iyong email address ay hindi nai-publish. Mga kinakailangang patlang ay minarkahan ng *

*

*

  1. Responsable para sa data: Miguel Ángel Gatón
  2. Layunin ng data: Kontrolin ang SPAM, pamamahala ng komento.
  3. Legitimation: Ang iyong pahintulot
  4. Komunikasyon ng data: Ang data ay hindi maiparating sa mga third party maliban sa ligal na obligasyon.
  5. Imbakan ng data: Ang database na naka-host ng Occentus Networks (EU)
  6. Mga Karapatan: Sa anumang oras maaari mong limitahan, mabawi at tanggalin ang iyong impormasyon.

  1.   linuxito dijo

    Humihingi ako ng paumanhin ngunit ito ay isang kahila-hilakbot na pagkaligalig sa seguridad !! Nalaglag mo ang password sa mga script, payak na mga file ng teksto, kasaysayan ng bash, atbp.
    Para doon, sinusuportahan ng opensh ang pampublikong key na pagpapatotoo gamit ang RSA.
    Salamat sa ganitong uri ng kasanayan (ipinatupad ng mga paksa na tumawag sa kanilang sarili na "mga tagapangasiwa") mayroong labis na kawalang-seguridad sa computer.
    Pagbati.

    1.    masigla dijo

      Tingnan natin. Oo, ito ay isang problema sa seguridad ngunit hindi ito nangangahulugan na ang "mga paksa" na o hindi mga administrador ay kailangang gumamit ng pamamaraang ito. Ang pamamaraan ay umiiral at ipinapakita kung sakaling kailangan itong magamit sa isang kapaligiran kung saan ang isyu ng seguridad ay hindi isang isyu. Sa tindahan ibinebenta ka nila ng kutsilyo, magpasya ka kung gagamitin mo ito upang mag-cut ng gulay o pumatay sa isang tao.

      1.    linuxito dijo

        Naiintindihan ko ang iyong posisyon, ngunit humihingi ako ng paumanhin na sa isang blog ng gayong katanyagan na isinusulong nila ang ganitong uri ng kasanayan, ito ay halos tulad ng isang "paghingi ng tawad para sa kahila-hilakbot na pangangasiwa ng mga system" hehe.
        Isang yakap!!

        1.    masigla dijo

          Hindi ko pa rin maintindihan kung ano ang problema 🙁

          Tulad ng pag-uusapan natin tungkol sa "kung paano makakuha ng higit na seguridad" sa iba't ibang mga aspeto, maaari din nating pag-usapan ang iba pang mga "hindi gaanong ligtas" na mga paksa. Ang aming layunin ay upang mag-alok ng impormasyon, nasa sa iyo na malaman kung ano ang gagawin dito. Bilang karagdagan, ang may-akda ng pinaka-paranoid na post na may seguridad ay hindi maaaring, maniwala ka sa akin, pagdating sa System Administration, hindi ito gumagawa ng ganitong uri ng bagay.

          Pagbati 😉

          1.    linuxito dijo

            Una, nang sinabi kong 'ipinatupad ng mga paksa na tumawag sa kanilang sarili na "mga tagapangasiwa"', hindi ako sumangguni sa anumang oras sa may-akda ng artikulo, hindi ko maintindihan kung bakit sila madaling kapitan.

            Ang problema, sa aking pananaw, ay ang tool na ito na laban sa lahat ng mahusay na kasanayan sa seguridad. Naniniwala ako na mula sa pamayanan ng GNU / Linux dapat nating panatilihin ang ating mahalagang operating system nang ligtas hangga't maaari. Ibig kong sabihin, ayokong makita ang GNU / Linux na naging Windows (security-wisdom).

            Sa kasamaang palad maraming mga administrador ng baguhan na hindi alam ang tamang paraan upang gumawa ng mga bagay, at nagtatapos sa paggamit ng mga tool na ito sa mga kritikal na sistema.

            Siyempre mayroon kang karapatang mai-publish kung ano ang gusto mo, ngunit inuulit ko, Humihingi ako ng paumanhin na ang blog na ito (isa sa pinakamahalaga sa wikang Espanyol) ay nagbibigay ng mga tool na nagbabanta sa seguridad.

            Pagbati!

            1.    masigla dijo

              At bigyan si Juana ng palanggana. Tiyak na, dahil ito ay isang sanggunian na blog, nais naming magbigay ng lahat ng uri ng impormasyon. Naintindihan ko ito:

              Dumating ang isang gumagamit at nagtanong: Paano ako makakonekta sa isang server sa pamamagitan ng SSH nang hindi hinihiling ang password?
              Sinasagot nila siya sa anumang forum: Noooo, problema sa seguridad iyan, walang gumagawa iyon.

              Kahit na alam, hindi sinasabi sa kanya ng user kung bakit ito ay isang problema sa seguridad. Masama, napakasama, mabuti na alam mo kung paano gawin ang mga bagay, kaya sa Desdelinux:

              Dumating ang isang gumagamit at nagtanong: Paano ako makakonekta sa isang server sa pamamagitan ng SSH nang hindi hinihiling ang password?
              Nagsusulat kami ng isang post at sinasabi: Maaari mong gamitin ang pamamaraang ito, gumagana ito sa ganitong paraan ngunit HINDI LIGTAS LIGTAS. Ang pinakaligtas na bagay ay ang paggamit ng isa pang ito.

              Alin sa tingin mo mas mabuti?


            2.    linuxito dijo

              Okay, iginagalang ko ang iyong pustura. Malugod na pagbati !!


            3.    KZKG ^ Gaara dijo

              Ang SSHPass ay hindi talaga nagbabanta sa seguridad, ang taong nagbabanta sa seguridad sa anumang kaso ay ang gumagamit na maling gumagamit dito.
              Halimbawa, narito ang isang mahusay na halimbawa na ang SSHPass ay hindi lamang ginagamit para sa kung ano ang ibinibigay ko sa post, maaari itong magamit para sa (halimbawa) pag-crack ng OpenSSH-Server: http://paste.desdelinux.net/4810

              Ang application ay walang hihigit sa iyon, isang application, ang paggamit na ibinigay dito ay kung ano ang magiging sanhi ng mga pagkabigo na ikompromiso ang seguridad o hindi.

              Tungkol sa kinakabahan o madaling kapitan, hindi naman, marahil ito ang paraan ng iyong nasabi (o ang pagbabasa na nagpapakahirap maunawaan nang tama) ngunit binigyang-kahulugan ko na ang komento ay nakadirekta sa akin, kung hindi, humihingi ako ng paumanhin.

              PS: Tiyak na maraming makakahanap ng script na inilagay ko na interesante at nakakatawa pa LOL!


            4.    linuxito dijo

              Ok, natutuwa akong nagkasundo kami. Cheers !!


    2.    KZKG ^ Gaara dijo

      Nasabi ko na ba na ang pamamaraan na ito ay mas ligtas kaysa sa paggamit ng pampubliko at pribadong mga susi?

      Sa isa pang artikulo na naibahagi ko na kung paano gamitin ang mga ito [1], ngayon ay simpleng paliwanag ko sa ibang paraan upang makamit ang pareho o isang bagay na katulad.

      Ginagamit ng bawat isa ang isa na pinakaangkop sa kanila, ang isa na gusto nila. Dito ko lang ipinaliwanag ang isa sa mga paggamit na maaaring ibigay sa sshpass, ang isa pa ay maaaring sa pamamagitan ng isang script ng Bash upang masira ang SSH sa pamamagitan ng paggamit ng isang diksyunaryo ... ngunit dumating, isa lamang itong paggamit.

      Uulitin ko, ibinabahagi ko lamang ang aking kaalaman na nauugnay sa GNU / Linux. Ang SSHPass ay maaaring hindi perpektong pagpipilian para sa anumang kaso, ngunit mayroon itong utility, huwag mag-atubiling.

      Ang BTW, na tumutukoy sa: (ipinatupad ng mga paksa na tumawag sa kanilang sarili na "mga administrador") ... heh ... he ... heh ... Mas gusto kong hindi magbigay ng puna, wala akong patunayan sa sinuman, hindi man sabihing ang iyong kaibigan ko, wala kang pinaka-malayong ideya ng kung sino ako, mas mababa kaysa sa alam ko 😉

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

      1.    linuxito dijo

        Huwag matakot, nangyayari na sa aking larangan may mga kilala akong mga tao na ibinase ang kanilang trabaho sa Google at kapag nalulutas ang mga problema kinopya nila at na-paste ang ganitong uri ng bagay. Pagkatapos ang tagapangasiwa ng seguridad ay ang "naglalagay ng mga gulong sa gulong" kapag nakita niya ang mga ganitong uri ng mga anomalya. Cheers !!

      2.    msx dijo

        Mamahinga ang tao, hindi sulit ito 😉

  2.   xykyz dijo

    Oo naman, ngunit pagkatapos ang password ay nakarehistro sa mga ginamit na utos. Para sa mga kadahilanang panseguridad, hindi ito dapat gawin ...

    1.    davidlg dijo

      Iyon ang iniisip ko habang binabasa ang post

    2.    KZKG ^ Gaara dijo

      Ang pagdaragdag nito sa aming .bashrc ay hindi mai-save ang mga kaugnay na utos na sshpass:
      HISTIGNORE='sshpass *'

      Gagawa ako ng isang post kung paano hindi papansinin ang mga utos upang hindi sila mai-save sa bash history sa ilang sandali :)

      1.    talim ng anghel dijo

        Ang isa pang paraan para hindi mai-save ang mga utos ay laging ilagay ang isang puwang bago ang utos. ^ __ ^

  3.   Ignacio dijo

    Sa palagay ko mas ligtas na gamitin ang mga key upang kumonekta sa pamamagitan ng SSH nang hindi kinakailangang ipasok ang password.

    Sa kabilang banda, ang paglikha ng isang buong alias ng utos kung saan nai-save ang password ay maaaring maging isang isyu sa seguridad.

  4.   Saito dijo

    Kung sa tingin ko isang kamalian sa seguridad ng computer, ngunit sisiguraduhin naming hindi sila nai-save sa kasaysayan ng bash ay hindi gaanong problema na ginagawa namin (maliban sa isang alyas na magiging napakalaki), pati na rin bilang elav sabi sa tindahan ibenta sa amin ang kutsilyo na kami ang makakakita kung ano ang gagamitin nito

  5.   truko22 dijo

    Kagiliw-giliw, ngunit mas mahusay na gamitin ang publiko at pribadong key na ipinakita mo sa isa pang entry.

  6.   msx dijo

    @KZKG
    Sa palagay ko mas praktikal ito - at ligtas! - Gumamit ng mga RSA / ECDSA key kasama ang isang keychain (SSH agent) para sa awtomatikong pagpapatotoo.
    Sa aking kaso, gumagamit ako ng isang SSH keychain sa Keychain, na binuo ng mga tao sa Funtoo, na gumagana nang mahusay, gumagamit ng napakakaunting mga mapagkukunan at napaka-ligtas:
    http://www.funtoo.org/Keychain

    Halimbawa:

    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)"'

    Paano gamitin:
    SSHKEYGEN {ecdsa, rsa}
    SSHCOPYID {ecdsa, rsa} gumagamit @ {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'

    Saan:
    -p #: port
    usr1 @ server1: server ng gumagamit @ AVAHI
    usr1@server1.local: user @ AVAHI server (depende sa kung paano naka-configure ang server sa ilang mga system kinakailangan upang idagdag ang panlapi .local)
    usr1 @ [addr. ip] .101: naayos ang ip address.

    / etc / ssh / sshd_config: http://paste.chakra-project.org/4974/
    ~ / .ssh / config: http://paste.chakra-project.org/4975/
    OS: Arch Linux/Chakra

    Sana maihatid ito sa iyo, pagbati!

    1.    KZKG ^ Gaara dijo

      Sa katunayan gumagamit ako ng mga susi, hindi SSHPass upang ma-access ang aking mga server ... Natuklasan ko ang SSHPass kapag kailangan ko ng isang paraan upang magawa ang script na ito: http://paste.desdelinux.net/4810

      Ngunit ... mabuti, nais kong ibahagi ang SSHPass sa lahat, ngunit malinaw naman na hindi ko mailagay dito ang isang script na nagpapahintulot sa paggamit ng isang diksyunaryo upang subukang labagin ang OpenSSH-Server HAHAHA!

      1.    msx dijo

        "[…] Hindi ko mailagay dito ang isang script na nagpapahintulot sa paggamit ng isang diksyunaryo upang subukang labagin ang OpenSSH-Server HAHAHA!"
        Ngunit bakit hindi!!?
        Ang pag-hack ba at pag-crack ay hindi bahagi ng pag-aaral ng mahusay na mga kasanayan sa seguridad [0]!?
        Mangyaring tao, sige !!!

        Hindi ba maganda kung gumamit ng mga salita na nangangahulugang eksaktong kabaligtaran ng literal na kahulugan nila!? Hack ang lingguwistika !!! ;-D

      2.    guzmanweb dijo

        Kumusta, nakakuha ako ng error na ito:

        Sinusubukan nito ang mga password sa 192.168.20.11 sa port 22 kasama ang root user
        cat: con-letters.txt: Walang ganoong file o direktoryo

        ang file na may mga titik.txt nilikha ko ang mga ito?

        tungkol

  7.   Eduardo dijo

    Hindi ito tapos, dahil ang password ay nakaimbak sa bash_history bilang payak na teksto, bukod sa maaari itong malaman sa ibang paraan. Kaya't hindi ka hiningi ng ssh ng isang password, ang tamang paraan ay sa "pampubliko at pribadong mga key".

  8.   oscar meza dijo

    Gumagamit ako ng RSA upang kumonekta sa aking mga server nang malayuan, kahit na sa tingin ko na upang kumonekta sa ilang computer kung saan hindi namin kailanganin ang gayong malakas na seguridad ay isang mahusay na tool, salamat sa tip!

  9.   Nelson dijo

    Chiuuuu

  10.   Nabucodonosor dijo

    At bakit mas mahusay na hindi mai-publish ang aking password upang magamit ito sa sinuman?

  11.   Mario dijo

    Mahusay na mahusay !!!!!! at sa Espanyol.

  12.   Gonzalo jarjury dijo

    Mahusay na artikulo, tulad ng laging nagrereklamo ang mga tao sa halip na magpasalamat, kahit na ang pamamaraan ay hindi sigurado nakasalalay ito sa kung saan at paano mo ito ginagamit, maraming salamat 🙂