Dërgoni fjalëkalimin e SSH në të njëjtën linjë me paketën sshpass

Për ata prej nesh që përdorin SSH, domethënë, ata prej nesh që kanë nevojë për të hyrë në kompjuterë ose servera të largët vazhdimisht në jetën tonë të përditshme arrijnë deri në pikën që të ngopen me fjalëkalimet e shkruara, do të ishte:

  1. Kryesore në një terminal: përdoruesi ssh @ serveri
  2. Prisni disa sekonda
  3. Serveri ku duam të lidhemi do të kërkojë fjalëkalimin
  4. Pasi të vendosim fjalëkalimin dhe të shtypim [Enter] atëherë do të hyjmë në serverin e largët

Dhe tani pyetja ime, nuk është më e thjeshtë të shkruash thjesht?:

sshpass -p «PASSWORD» ssh root@servidor

Për shembull, supozoni se përdoruesi është rrënjë, serveri është: devdesdelinux. Net dhe fjalëkalimi është xunil ... atëherë rreshti do të ishte:

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

Për ta arritur këtë, ne thjesht duhet të instalojmë paketën sshpassDebian / Ubuntu ose derivatet do të ishin me sudo apt-get instaloni sshpass Ndërkohë në ArchLinux ose derivatet do të mjaftonin me sudo pacman -S sshpass

Nëse duam të specifikojmë portin (sepse SSH nuk është në portin 22) shtojmë -p «PORTI» ... domethënë, duke supozuar se është porti 9122:

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

Për ta thjeshtuar edhe më shumë gjithë këtë ne mund të krijojmë pseudonimePër shembull, gjatë ekzekutimit të serverit1, e gjithë linja ekzekutohet për t'u lidhur nga SSH me serverin1sshpass -p përdorues fjalëkalimi @ server1) ose diçka të ngjashme, kështu që ne gjithashtu ruajmë duke vendosur një vijë shumë të gjatë

Sidoqoftë, shpresoj se kjo ka qenë e dobishme për ju.

Nga rruga, një mënyrë tjetër për të shmangur nevojën për të shkruar fjalëkalimin kur kemi qasje nga SSH është duke përdorur çelësat publik dhe privat.

të fala


Lini komentin tuaj

Adresa juaj e emailit nuk do të publikohet. Fusha e kërkuar janë shënuar me *

*

*

  1. Përgjegjës për të dhënat: Miguel Ángel Gatón
  2. Qëllimi i të dhënave: Kontrolloni SPAM, menaxhimin e komenteve.
  3. Legjitimimi: Pëlqimi juaj
  4. Komunikimi i të dhënave: Të dhënat nuk do t'u komunikohen palëve të treta përveç me detyrim ligjor.
  5. Ruajtja e të dhënave: Baza e të dhënave e organizuar nga Occentus Networks (BE)
  6. Të drejtat: Në çdo kohë mund të kufizoni, rikuperoni dhe fshini informacionin tuaj.

  1.   linuxito dijo

    Faljet e mia por ky është një devijim i tmerrshëm i sigurisë !! Ju keni fjalëkalimin të mbërthyer në skripta, skedarë me tekst të thjeshtë, histori bash, etj.
    Për këtë, openssh mbështet vërtetimin e çelësit publik duke përdorur RSA.
    Falë kësaj lloj praktike (zbatuar nga subjektet që e quajnë veten "administratorë") ka kaq shumë pasiguri në kompjuter.
    Përshëndetje.

    1.    i gjallë dijo

      Le të shohim. Po, është një problem sigurie por nuk do të thotë që "subjektet" që janë administratorë ose nuk duhet të përdorin këtë metodë. Metoda ekziston dhe tregohet në rast se duhet të përdoret në një mjedis ku siguria nuk është çështje. Në dyqan ata ju shesin thikën, ju vendosni nëse e përdorni për të prerë perimet apo për të vrarë dikë.

      1.    linuxito dijo

        Unë e kuptoj pozicionin tuaj, por më vjen keq që në një blog me famë të tillë ata promovojnë këtë lloj praktike, është pothuajse si një "falje për administrimin e tmerrshëm të sistemit" hehe.
        Nje perqafim!!

        1.    i gjallë dijo

          Ende nuk e kuptoj cili është problemi

          Ndërsa kemi folur për "si të sigurojmë më shumë siguri" në aspekte të ndryshme, ne gjithashtu mund të flasim për tema të tjera "më pak të sigurta". Qëllimi ynë është të ofrojmë informacionin, varet nga ju që të dini se çfarë të bëni me të. Përveç kësaj, autori i postit më paranojak me siguri nuk mund të jetë, më besoni, kur bëhet fjalë për Administrimin e Sistemit, ai nuk e bën këtë lloj gjëje.

          Pershendetje

          1.    linuxito dijo

            Së pari, kur thashë 'zbatuar nga subjekte që e quajnë veten "administratorë", nuk iu referova në asnjë moment autorit të artikullit, nuk e kuptoj pse janë kaq të ndjeshëm.

            Problemi, nga këndvështrimi im, është se ky mjet shkon kundër të gjitha praktikave të mira të sigurisë. Unë besoj se nga bashkësia GNU / Linux ne duhet ta mbajmë sistemin tonë të çmuar operativ sa më të sigurt që të jetë e mundur. Dua të them, nuk do të doja të shihja GNU / Linux të kthyer në Windows (për siguri).

            Fatkeqësisht ka shumë administratorë fillestarë të cilët nuk e dinë mënyrën e duhur për të bërë gjërat dhe përfundojnë duke përdorur këto mjete në sistemet kritike.

            Sigurisht që ju keni të drejtë të botoni çfarë të doni, por e përsëris, më trishton fakti që ky blog (një nga bloget më të rëndësishëm spanjishtfolës) u jep vendin mjeteve që kërcënojnë sigurinë.

            Përshëndetje!

            1.    i gjallë dijo

              Dhe jepi Juana me legen. Pikërisht, sepse është një blog referimi, ne dëshirojmë të sigurojmë të gjitha llojet e informacionit. Unë e kuptoj këtë:

              Një përdorues arrin dhe pyet: Si mund të lidhem me një server përmes SSH pa kërkuar fjalëkalimin?
              Ata i përgjigjen atij në çdo forum: Noooo, kjo është një çështje sigurie, askush nuk e bën atë.

              Edhe duke e ditur, përdoruesi nuk i thotë pse është problem sigurie. Keq, shumë keq, është mirë që di t'i bësh gjërat, prandaj brenda Desdelinux:

              Një përdorues arrin dhe pyet: Si mund të lidhem me një server përmes SSH pa kërkuar fjalëkalimin?
              Ne shkruajmë një postim dhe themi: Ju mund ta përdorni këtë metodë, funksionon në këtë mënyrë por NUK SHT E SIGURT. Gjëja më e sigurt është të përdorni këtë tjetër.

              Cila mendoni se është më e mirë?


            2.    linuxito dijo

              Mirë, unë respektoj qëndrimin tuaj. Përshëndetje !!


            3.    KZKG ^ Gaara dijo

              SSHPass në fakt nuk kërcënon sigurinë, personi që kërcënon sigurinë në çdo rast është përdoruesi që e keqpërdor atë.
              Për shembull, këtu është një shembull i shkëlqyeshëm që SSHPass nuk përdoret vetëm për ato që komentoj në postim, por mund të përdoret për (për shembull) plasaritje të OpenSSH-Server: http://paste.desdelinux.net/4810

              Aplikimi nuk është asgjë më shumë se kaq, një aplikacion, përdorimi që jepet është ai që do të shkaktojë dështime që kompromentojnë sigurinë ose jo.

              Lidhur me nervozizmin ose të ndjeshëm, në të gjitha, mbase ishte mënyra se si e thatë ju (ose që leximi e bën të vështirë për të kuptuar saktë), por unë interpretova që komenti ishte drejtuar ndaj meje, nëse nuk ishte, unë kërkoj falje.

              PS: Me siguri do të ketë disa që do të gjejnë skenarin që unë vë LOL interesante dhe madje qesharake!


            4.    linuxito dijo

              Ok, jam i lumtur që arritëm një marrëveshje. Brohoritje !!


    2.    KZKG ^ Gaara dijo

      A kam thënë ndonjëherë që kjo metodë është më e sigurt sesa përdorimi i çelësave publikë dhe privatë?

      Në një artikull tjetër unë tashmë ndava mënyrën e përdorimit të tyre [1], tani thjesht shpjegoj një mënyrë tjetër për të arritur të njëjtën gjë ose diçka të ngjashme.

      Të gjithë përdorin atë që i përshtatet më shumë, atë që preferojnë. Këtu thjesht shpjegova një nga përdorimet që mund t'i jepet sshpass, një tjetër mund të jetë përmes një skenari Bash për të thyer SSH përmes përdorimit të një fjalori ... por hajde, ky është vetëm një përdorim tjetër.

      E përsëris, unë ndaj vetëm njohuritë e mia në lidhje me GNU / Linux. SSHPass mund të mos jetë zgjedhja ideale për çdo rast, por ka dobi, mos hezitoni.

      BTW, duke iu referuar: (implementuar nga subjekte që e quajnë veten "administratorë") ... heh ... heh ... heh ... Unë preferoj të mos komentoj, nuk kam asgjë për t'i provuar askujt, për të mos përmendur që shoku im, ti nuk ke idenë më të largët se kush jam, aq më pak se sa di unë 😉

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

      1.    linuxito dijo

        Mos u bëj nervoz, ndodh që në fushën time të njoh njerëz që bazojnë punën e tyre në Google dhe kur zgjidhin probleme ata kopjojnë dhe ngjisin këtë lloj gjëje. Atëherë administratori i sigurisë është ai që "vendos rrotat në timon" kur zbulon këto lloj anomalish. Të fala!!

      2.    MSX dijo

        Çlodhu njeri, nuk ia vlen

  2.   xykyz dijo

    Sigurisht, por atëherë fjalëkalimi regjistrohet në komandat e përdorura. Për arsye sigurie, kjo nuk duhet të bëhet ...

    1.    davidlg dijo

      Kjo është ajo që po mendoja kur lexoja postimin

    2.    KZKG ^ Gaara dijo

      Shtimi i kësaj në .bashrc tonë nuk do të ruante komandat e lidhura me sshpass:
      HISTIGNORE='sshpass *'

      Do të bëj një postim se si të injoroj komandat në mënyrë që ata të mos shpëtojnë për të bash historinë së shpejti :)

      1.    engjëllore dijo

        Një mënyrë tjetër që komandat të mos ruhen është që gjithmonë të vendosni një hapësirë ​​para komandës. ^ __ ^

  3.   Ignacio dijo

    Unë mendoj se është më e sigurt të përdorësh çelësat për t'u lidhur përmes SSH pa pasur nevojë të vendosësh fjalëkalimin.

    Nga ana tjetër, krijimi i një pseudonimi të plotë të komandës ku ruhet fjalëkalimi mund të jetë një çështje sigurie.

  4.   Saito dijo

    Nëse më duket një e metë në sigurinë e kompjuterit, por ne do të sigurohemi që ato të mos ruhen në historinë e bash nuk është aq problemi që ne bëjmë (përveç një pseudonimi që do të ishte i madh), gjithashtu siç thotë elav në dyqan na shes thikën ne jemi ata që do të shohim se çfarë ta përdorim

  5.   truko22 dijo

    Interesante, por përdor më mirë çelësin publik dhe privat që treguat në një hyrje tjetër.

  6.   MSX dijo

    @KZKG
    Unë mendoj se është më praktike - dhe e sigurt! - përdorni çelësat RSA / ECDSA së bashku me një keychain (agjent SSH) për vërtetimin automatik.
    Në rastin tim, unë përdor një Keychain SSH për Keychain, i zhvilluar nga njerëzit në Funtoo, i cili funksionon shumë mirë, përdor shumë pak burime dhe është shumë i sigurt:
    http://www.funtoo.org/Keychain

    Shembull:

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

    Si të përdorni:
    SSHKEYGEN {ecdsa, rsa}
    SSHCOPYID {ecdsa, rsa} përdorues @ {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'

    Ku:
    -p #: port
    usr1 @ server1: përdoruesi @ serveri AVAHI
    usr1@server1.lokale: server @ server AVAHI (në varësi të mënyrës se si konfigurohet serveri në disa sisteme është e nevojshme të shtoni prapashtesën. lokale)
    usr1 @ [shtuesi. ip] .101: adresa fikse e ip.

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

    Shpresoj të të shërbejë, përshëndetje!

    1.    KZKG ^ Gaara dijo

      Në të vërtetë unë përdor çelësa, jo SSHPass për të hyrë në serverat e mi ... Kam zbuluar SSHPass kur më duhej një mënyrë për ta bërë këtë skenar: http://paste.desdelinux.net/4810

      Por ... mirë, unë doja ta ndaja SSHPass me të gjithë, por padyshim që nuk mund të vendosja këtu një skenar që lejon përdorimin e një fjalori për të shkelur OpenSSH-Server HAHAHA!

      1.    MSX dijo

        «[…] Nuk mund të vendosja këtu një skenar që lejon përdorimin e një fjalori për të shkelur OpenSSH-Server HAHAHA!»
        Po pse jo !!?
        A nuk është hakimi dhe çarja pjesë e të mësuarit të praktikave të mira të sigurisë [0]!
        Të lutem njeri, vazhdo !!!

        [0] A nuk është bukur të përdorësh fjalë për të nënkuptuar saktësisht të kundërtën e asaj që ata do të thonë fjalë për fjalë!? Hack gjuhësinë !!! ;-D

      2.    guzmanweb dijo

        Përshëndetje, unë kam këtë gabim:

        Po teston fjalëkalimet në 192.168.20.11 në portin 22 me përdoruesin root
        cat: con-letters.txt: Asnjë skedar apo direktori e tillë

        skedarin me shkronja.txt I krijoj?

        regards

  7.   Eduardo dijo

    Kjo nuk është bërë, pasi fjalëkalimi është ruajtur në bash_history si tekst i thjeshtë, përveç që mund të zbulohet në një mënyrë tjetër. Kështu që ssh nuk ju kërkon një fjalëkalim, mënyra e saktë është me "çelësat publikë dhe privatë".

  8.   oscar meza dijo

    Unë përdor RSA për t'u lidhur me serverat e mi nga distanca, edhe pse mendoj se lidhja me ndonjë kompjuter ku nuk kërkojmë siguri kaq të fortë është një mjet i mirë, faleminderit për këshillën!

  9.   kapje me duart pas zverkut të kundërshtarit dijo

    Çiuuu

  10.   Nebukadnetsari dijo

    Dhe pse më mirë të mos e publikoj fjalëkalimin tim në mënyrë që të jetë në dispozicion për këdo?

  11.   mario dijo

    E shkëlqyeshme aq mirë !!!!!! dhe në spanjisht.

  12.   Jarjury Gonzalo dijo

    Artikull i shkëlqyeshëm, si gjithmonë njerëzit ankohen në vend që të falenderojnë, megjithëse metoda është e pasigurt varet nga vendi dhe mënyra se si e përdorni, faleminderit shumë