Saada SSH parool sshpass paketiga samal real

Neile meist, kes kasutavad SSHsee tähendab, et need meist, kellel on igapäevaselt vaja kaugarvutitele või serveritele juurde pääseda, jõuavad paroolide sisestamisest tüdimuseni, see oleks:

  1. Sisestage terminal: ssh kasutaja @ server
  2. Oodake mõni sekund
  3. Server, kuhu soovime ühenduse luua, küsib parooli
  4. Kui oleme parooli pannud ja vajutanud [Enter], pääseme kaugserverisse

Ja nüüd minu küsimus, kas pole lihtsam lihtsalt sisestada?

sshpass -p «PASSWORD» ssh root@servidor

Oletame näiteks, et kasutaja on juur, server on: arendajadesdelinux. Net ja parool on xunil ... siis oleks rida järgmine:

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

Selle saavutamiseks peame lihtsalt paketi installima sshpasssisse Debian / Ubuntu või tuletised oleksid koos sudo apt-get installige sshpass Vahepeal sisse ArchLinux või derivaatidest piisaks sudo pacman -S sshpass

Kui soovime täpsustada porti (sest SSH pole 22. sadamas) lisame -p «SADAM» ... see tähendab, eeldades, et see on port 9122:

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

Selle kõige veelgi lihtsustamiseks saame luua varjunimesidNäiteks server1 käivitamisel käivitatakse kogu rida SSH-ga ühenduse loomiseks serveriga1 (sshpass -p parool kasutaja @ server1) või midagi sarnast, seega säästame ka liiga pika rea ​​panemist 😉

Igatahes loodan, et see on teile kasulik olnud.

Muide, veel üks viis, kuidas vältida parooli kirjutamist, kui SSH kaudu juurde pääseme, on avalikud ja privaatvõtmed.

seoses


Jäta oma kommentaar

Sinu e-postiaadressi ei avaldata. Kohustuslikud väljad on tähistatud *

*

*

  1. Andmete eest vastutab: Miguel Ángel Gatón
  2. Andmete eesmärk: Rämpsposti kontrollimine, kommentaaride haldamine.
  3. Seadustamine: teie nõusolek
  4. Andmete edastamine: andmeid ei edastata kolmandatele isikutele, välja arvatud juriidilise kohustuse alusel.
  5. Andmete salvestamine: andmebaas, mida haldab Occentus Networks (EL)
  6. Õigused: igal ajal saate oma teavet piirata, taastada ja kustutada.

  1.   linuxito DIJO

    Vabandust, aga see on kohutav turvalisuse kõrvalekalle !! Teil on parool kinni skriptides, lihttekstifailides, bashi ajaloos jne.
    Selleks toetab openssh avaliku võtme autentimist RSA abil.
    Tänu seda tüüpi praktikale (mida rakendavad subjektid, kes nimetavad end "administraatoriteks") on nii palju arvuti ebakindlust.
    Tervitused.

    1.    elav DIJO

      Vaatame. Jah, see on turbeprobleem, kuid see ei tähenda, et "subjektid", kes on administraatorid või ei peaks seda meetodit kasutama. Meetod on olemas ja seda näidatakse juhuks, kui seda on vaja kasutada keskkonnas, kus turvalisus pole probleem. Poes müüvad nad teile nuga, otsustate, kas kasutate seda köögiviljade lõikamiseks või kellegi tapmiseks.

      1.    linuxito DIJO

        Mõistan teie seisukohta, kuid mul on kahju, et sellise mainega ajaveebis nad sellist tüüpi praktikat propageerivad, see on peaaegu nagu "vabandus kohutava süsteemiadministratsiooni eest" hehe.
        Kallistus !!

        1.    elav DIJO

          Ma ei saa siiani aru, milles probleem on 🙁

          Kuna oleme erinevates aspektides rääkinud "kuidas saada rohkem turvalisust", võime rääkida ka muudest "vähem turvalistest" teemadest. Meie eesmärk on pakkuda teavet, teie asi on teada, mida sellega teha. Lisaks ei saa kõige paranoilisema ja turvalisusega postituse autor olla, uskuge mind, et kui tegemist on süsteemihaldusega, siis ta ei tee sellist asja.

          Tervitused 😉

          1.    linuxito DIJO

            Esiteks, kui ma ütlesin, et „rakendavad subjektid, kes nimetavad end„ administraatoriteks “, ei viidanud ma artikli autorile mitte kunagi, ma ei saa aru, miks nad nii vastuvõtlikud on.

            Minu seisukohast on probleem selles, et see tööriist on vastuolus kõigi heade turbetavadega. Usun, et GNU / Linuxi kogukonnast peame oma kalli operatsioonisüsteemi võimalikult turvalisena hoidma. Ma ei taha näha, et GNU / Linux muutuks Windowsiks (turvalisuse mõttes).

            Kahjuks on palju algajaid administraatoreid, kes ei tea õiget toimimisviisi ja kasutavad neid tööriistu kriitilistes süsteemides.

            Muidugi on teil õigus avaldada mida iganes soovite, kuid kordan, et see teeb mind kurvaks, et see ajaveeb (üks olulisemaid hispaaniakeelseid ajaveebe) annab koha turvalisust ohustavatele tööriistadele.

            Tervitused!

            1.    elav DIJO

              Ja anna Juana koos kraanikaussiga. Just sellepärast, et see on teatmeteemaline ajaveeb, meeldib meile pakkuda igasugust teavet. Ma saan sellest aru:

              Saabub kasutaja ja küsib: Kuidas saan SSH kaudu serveriga ühendust luua, ilma parooli küsimata?
              Nad vastavad talle igas foorumis: Noooo, see on turvaküsimus, keegi ei tee seda.

              Isegi teades ei ütle kasutaja talle, miks see on turvaprobleem. Halb, väga halb, hea, et oskad asju teha, sellepärast sisse Desdelinux:

              Saabub kasutaja ja küsib: Kuidas saan SSH kaudu serveriga ühendust luua, ilma parooli küsimata?
              Me kirjutame postituse ja ütleme: Võite seda meetodit kasutada, see töötab nii, kuid see pole EI OLE. Kõige kindlam on kasutada seda teist.

              Kumb on teie arvates parem?


            2.    linuxito DIJO

              Okei, ma austan teie rühti. Parimate soovidega!!


            3.    KZKG ^ Gaara DIJO

              SSHPass ei ohusta tegelikult turvalisust, turvalisust igal juhul ohustav isik on kasutaja, kes seda kuritarvitab.
              Näiteks on siin suurepärane näide, et SSHPassi ei kasutata ainult postituses kommenteerituks, vaid seda saab kasutada näiteks OpenSSH-Serveri kräkkimiseks: http://paste.desdelinux.net/4810

              Rakendus pole midagi muud kui rakendus, rakendus, mille kasutamine on see, mis põhjustab rikkeid, mis ohustavad turvalisust või mitte.

              Närvilise või vastuvõtliku osas pole see üldse nii, võib-olla oli see nii, nagu te seda ütlesite (või et lugemine muudab selle õigesti mõistmise keeruliseks), kuid ma tõlgendasin, et kommentaar oli suunatud mulle, kui seda ei olnud, siis vabandan.

              PS: Kindlasti on mitu, kes leiavad stsenaariumi, mille ma panin huvitava ja isegi naljaka LOL-i!


            4.    linuxito DIJO

              Ok, mul on hea meel, et jõudsime kokkuleppele. Terviseks !!


    2.    KZKG ^ Gaara DIJO

      Kas ma ütlesin kunagi, et see meetod on turvalisem kui avalike ja privaatvõtmete kasutamine?

      Ühes teises artiklis, kus ma juba jagasin, kuidas neid kasutada, [1] selgitan nüüd lihtsalt ühte võimalust sama või millegi sarnase saavutamiseks.

      Igaüks kasutab seda, mis sobib kõige paremini, seda, mida ta eelistab. Siin ma lihtsalt selgitasin ühte kasutust, mida sshpassile anda saab, teine ​​võib olla Bashi skripti kaudu SSH-i lõhkumine sõnastiku abil ... aga tule nüüd, see on lihtsalt üks teine ​​kasutusala.

      Kordan, et jagan ainult oma teadmisi, mis on seotud GNU / Linuxiga. SSHPass ei pruugi ühelgi juhul olla ideaalne valik, kuid sellel on kasulikkust, ärge kartke.

      BTW, viidates: (rakendavad subjektid, kes nimetavad end "administraatoriteks") ... heh ... heh ... heh ... Ma eelistan mitte kommenteerida, mul pole kellelegi midagi tõestada, rääkimata sellest, et teie mu sõber, teil pole kõige rohkem kauge idee sellest, kes ma olen, palju vähem kui see, mida ma tean 😉

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

      1.    linuxito DIJO

        Ära ole närvis, juhtub, et minu valdkonnas tean inimesi, kes põhinevad oma tööl Google'is ning probleemide lahendamisel kopeerivad ja kleebivad seda tüüpi asju. Siis on turvat administraator see, kes "paneb rattad rooli", kui ta tuvastab seda tüüpi kõrvalekaldeid. Terviseks !!

      2.    MSX DIJO

        Lõdvestu mees, see pole seda väärt 😉

  2.   xykyz DIJO

    Muidugi, kuid siis registreeritakse parool kasutatavates käskudes. Turvalisuse huvides ei tohiks seda teha ...

    1.    davidlg DIJO

      Seda mõtlesin postitust lugedes

    2.    KZKG ^ Gaara DIJO

      Selle lisamine meie .bashrc-sse ei salvesta sshpassiga seotud käske:
      HISTIGNORE='sshpass *'

      Ma teen postituse selle kohta, kuidas ignoreerida käske, et neid ei salvestataks peagi ajalukku :)

      1.    inglitera DIJO

        Teine võimalus, kuidas käske ei salvestata, on käsu ette alati tühiku asetamine. ^ __ ^

  3.   Ignacio DIJO

    Ma arvan, et SSH kaudu ühenduse loomiseks on turvalisem kasutada võtmeid ilma parooli sisestamata.

    Teisalt võib turvaküsimuseks olla parooli salvestamise täielik käsunime loomine.

  4.   Saito DIJO

    Kui mulle tundub, et see on viga arvutiturvalisuses, kuid me veendume, et neid ei salvestata bashi ajalukku, pole probleem niivõrd, nagu me teeme (välja arvatud alias, mis oleks tohutu), ka nagu elav ütleb pood müü meile nuga, meie oleme need, kes näevad, mida seda kasutada

  5.   truko22 DIJO

    Huvitav, kuid ma kasutan paremini avalikku ja privaatvõtit, mida näitasite teises kirjes.

  6.   MSX DIJO

    @KZKG
    Ma arvan, et see on praktilisem - ja ohutu! - kasutage automaatseks autentimiseks RSA / ECDSA võtmeid koos võtmehoidjaga (SSH agent).
    Minu puhul kasutan võtmehoidja jaoks SSH-võtmehoidjat, mille on välja töötanud Funtoo inimesed ja mis töötab väga hästi, kasutab väga vähe ressursse ja on väga turvaline:
    http://www.funtoo.org/Keychain

    Näide:

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

    Kuidas kasutada:
    SSHKEYGEN {ecdsa, rsa}
    SSHCOPYID {ecdsa, rsa} kasutaja @ {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'

    Kui:
    -p #: port
    usr1 @ server1: kasutaja @ AVAHI server
    usr1@server1.local: kasutaja @ AVAHI server (sõltuvalt sellest, kuidas server mõnes süsteemis on konfigureeritud, on vaja lisada järelliide .local)
    usr1 @ [addr. ip] .101: fikseeritud IP-aadress.

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

    Loodan, et see teenib teid, tervitused!

    1.    KZKG ^ Gaara DIJO

      Tegelikult kasutan oma serveritele juurdepääsemiseks võtmeid, mitte SSHPassi ... Avastasin SSHPassi, kui mul oli vaja seda skripti teha: http://paste.desdelinux.net/4810

      Aga ... noh, tahtsin SSHPassi jagada kõigiga, kuid ilmselgelt ei suutnud ma siia panna skripti, mis võimaldab sõnastiku abil proovida rikkuda OpenSSH-serverit HAHAHA!

      1.    MSX DIJO

        "[...] Ma ei suutnud siia panna skripti, mis võimaldab sõnastiku abil proovida rikkuda OpenSSH-serverit HAHAHA!"
        Aga miks mitte !!
        Kas häkkimine ja kräkkimine ei ole osa heade turbetavade õppimisest [0]!
        Palun mees, mine edasi !!!

        [0] Kas pole ilus kasutada sõnu, mis tähendavad täpselt vastupidist sellele, mida nad sõna otseses mõttes tähendavad!? Häkkige lingvistika !!! ;-D

      2.    guzmanweb DIJO

        Tere, ma saan selle vea:

        See testib porti 192.168.20.11 juurkasutajaga paroole 22
        cat: con-letters.txt: Sellist faili ega kataloogi pole

        faili kirjad.txt kas ma loon need?

        osas

  7.   Eduardo DIJO

    Seda ei tehta, kuna parool on bash_history'is salvestatud lihttekstina, peale selle võiks selle leida muul viisil. Nii et ssh ei küsi teilt parooli, on õige viis "avalike ja privaatsete võtmetega".

  8.   oscar meza DIJO

    Ma kasutan RSA-d oma serveritega kaugühenduse loomiseks, isegi nii, et arvan, et ühenduse loomine mõne arvutiga, kus me ei vaja nii tugevat turvalisust, on hea tööriist, aitäh vihje eest!

  9.   Nelson DIJO

    Chiuuuu

  10.   Nebukadnetsar DIJO

    Ja miks mitte parem oma parooli avaldada, et see oleks kõigile kättesaadav?

  11.   Mario DIJO

    Suurepärane, nii hea !!!!!! ja hispaania keeles.

  12.   Gonzalo jarjury DIJO

    Suurepärane artikkel, nagu alati inimesed kaebavad tänamise asemel, kuigi meetod on ebakindel, sõltub see sellest, kus ja kuidas te seda kasutate, suur aitäh 🙂