Küldje el az SSH jelszót ugyanazon a soron az sshpass csomaggal

Nekünk, akik használjuk a SSH, vagyis azoknak, akiknek nap mint nap folyamatosan hozzáférnünk kell a távoli számítógépekhez vagy szerverekhez, el kell jutnunk ahhoz, hogy elegük legyen a jelszavak beírásából, ez a következő lenne:

  1. Írja be a terminált: ssh user @ server
  2. Várjon néhány másodpercet
  3. Az a szerver, ahová csatlakozni akarunk, meg fogja kérni a jelszót
  4. Miután feltettük a jelszót és megnyomtuk az [Enter] gombot, akkor hozzáférünk a távoli szerverhez

És most a kérdésem, nem egyszerűbb-e egyszerűen beírni?:

sshpass -p «PASSWORD» ssh root@servidor

Tegyük fel például, hogy a felhasználó az gyökér, a szerver: Dev.desdelinux. Net és a jelszó az xunil ... akkor a sor a következő lenne:

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

Ennek eléréséhez egyszerűen telepítenünk kell a csomagot sshpass-On Debian / Ubuntu vagy származékai lennének sudo apt-get telepítse az sshpass programot Közben be ArchLinux vagy származékok elegendőek lennének sudo pacman -S sshpass

Ha meg akarjuk adni a portot (mert az SSH nincs a 22. porton) hozzátesszük -p «PORT» ... vagyis feltételezve, hogy a 9122-es port:

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

Hogy mindezt még jobban leegyszerűsítsem álneveket hozhatunk létrePéldául az 1. kiszolgáló végrehajtásakor a teljes sort úgy hajtják végre, hogy az SSH kapcsolódjon az 1. kiszolgálóhoz (sshpass -p jelszó user @ server1) vagy valami hasonló, tehát a túl hosszú sor putting betételével is spórolunk

Egyébként remélem, hogy ez hasznos volt az Ön számára.

Egyébként a jelszó megadásának elkerülése, amikor SSH-n keresztül férünk hozzá, az a nyilvános és magánkulcsok.

Üdvözlet


29 hozzászólás, hagyd a tiedet

Hagyja megjegyzését

E-mail címed nem kerül nyilvánosságra. Kötelező mezők vannak jelölve *

*

*

  1. Az adatokért felelős: Miguel Ángel Gatón
  2. Az adatok célja: A SPAM ellenőrzése, a megjegyzések kezelése.
  3. Legitimáció: Az Ön beleegyezése
  4. Az adatok közlése: Az adatokat csak jogi kötelezettség alapján továbbítjuk harmadik felekkel.
  5. Adattárolás: Az Occentus Networks (EU) által üzemeltetett adatbázis
  6. Jogok: Bármikor korlátozhatja, helyreállíthatja és törölheti adatait.

  1.   linuxito dijo

    Elnézést, de ez egy szörnyű biztonsági eltérés !! A jelszó meg van ragadva a szkriptekben, az egyszerű szöveges fájlokban, a bash előzményekben stb.
    Ehhez az openssh támogatja a nyilvános kulcs hitelesítését RSA segítségével.
    Az ilyen típusú gyakorlatoknak köszönhetően (amelyeket a magukat "rendszergazdának" nevező alanyok hajtanak végre) annyi a számítógépes bizonytalanság.
    Üdvözlet.

    1.    élénk dijo

      Lássuk. Igen, ez biztonsági probléma, de nem jelenti azt, hogy a rendszergazdának minősülő vagy nem „alanyoknak” ezt a módszert kell használniuk. A módszer létezik és megjelenik abban az esetben, ha olyan környezetben kell használni, ahol a biztonság nem kérdés. A boltban eladják neked a kést, te döntöd el, hogy zöldségvágásra vagy valakire ölsz-e.

      1.    linuxito dijo

        Megértem álláspontját, de sajnálom, hogy egy ilyen hírű blogban népszerűsítik ezt a fajta gyakorlatot, ez szinte olyan, mint egy "bocsánatkérés a szörnyű rendszeradminisztrációért" hehe.
        Egy ölelés!!

        1.    élénk dijo

          Még mindig nem értem, mi a probléma 🙁

          Mivel különféle szempontokban beszéltünk arról, hogy "hogyan lehet nagyobb biztonságot szerezni", beszélhetünk más "kevésbé biztonságos" témákról is. Célunk az információk felajánlása, rajtad múlik, hogy mit kezdj vele. Ezen túlmenően, a biztonsággal kapcsolatos legparanoiásabb bejegyzés szerzője nem lehet, hidd el, ha a Rendszeradminisztrációról van szó, akkor nem csinál ilyesmit.

          Üdvözlet 😉

          1.    linuxito dijo

            Először is, amikor azt mondtam, hogy „magukat„ rendszergazdának ”nevező alanyok hajtják végre”, soha nem utaltam a cikk szerzőjére, nem értem, miért ilyen fogékonyak.

            Véleményem szerint a probléma az, hogy ez az eszköz minden jó biztonsági gyakorlattal ellentétes. Úgy gondolom, hogy a GNU / Linux közösség részéről meg kell tartanunk a lehető legbiztonságosabbra értékes operációs rendszerünket. Úgy értem, nem szeretném, ha a GNU / Linux Windows-ba alakulna (biztonság szempontjából).

            Sajnos sok kezdő rendszergazda van, aki nem tudja a dolgok helyes módját, és végül ezeket az eszközöket kritikus rendszereken használja.

            Természetesen jogod van közzé tenni, amit akarsz, de ismétlem, sajnálom, hogy ez a blog (az egyik legfontosabb a spanyol nyelvben) helyet ad a biztonságot fenyegető eszközöknek.

            Üdvözlet!

            1.    élénk dijo

              És add Juana-t a medencével. Pontosan azért, mert referenciablogról van szó, ezért szívesen adunk mindenféle információt. Értem:

              Megérkezik egy felhasználó, és megkérdezi: Hogyan tudok SSH-n keresztül csatlakozni egy kiszolgálóhoz anélkül, hogy jelszót kérnék?
              Bármely fórumon válaszolnak neki: Nem, ez biztonsági kérdés, ezt senki sem teszi.

              A felhasználó ennek tudatában sem mondja meg neki, hogy ez miért biztonsági probléma. Rossz, nagyon rossz, jó, hogy tudod, hogyan kell csinálni a dolgokat, ezért be Desdelinux:

              Megérkezik egy felhasználó, és megkérdezi: Hogyan tudok SSH-n keresztül csatlakozni egy kiszolgálóhoz anélkül, hogy jelszót kérnék?
              Írunk egy bejegyzést, és ezt mondjuk: Használhatja ezt a módszert, így működik, de NEM BIZTONSÁGOS. A legbiztonságosabb ezt a másikat használni.

              Szerinted melyik a jobb?


            2.    linuxito dijo

              Oké, tisztelem a testtartásodat. Üdvözlettel!!


            3.    KZKG ^ Gaara dijo

              Az SSHPass valójában nem fenyegeti a biztonságot, a biztonságot mindenképpen veszélyezteti az a felhasználó, aki visszaél vele.
              Például itt van egy kiváló példa arra, hogy az SSHPass nem csak arra szolgál, amit a bejegyzésben kommentálok, hanem az OpenSSH-Server feltörésére is használható (például): http://paste.desdelinux.net/4810

              Az alkalmazás nem más, mint egy alkalmazás, a megadott használat az, ami hibákat okoz, amelyek veszélyeztetik a biztonságot.

              Az ideges vagy hajlamosakkal kapcsolatban egyáltalán talán az volt a módja, ahogy te mondtad (vagy az olvasás megnehezíti a helyes megértést), de értelmeztem, hogy a megjegyzés rám irányult, ha nem, akkor elnézést kérek.

              PS: Biztosan többen lesznek, akik megtalálják azt a forgatókönyvet, amelyet érdekes, sőt vicces LOL-nak adtam!


            4.    linuxito dijo

              Ok, örülök, hogy megállapodásra jutottunk. Egészségére!!


    2.    KZKG ^ Gaara dijo

      Mondtam már, hogy ez a módszer biztonságosabb, mint a nyilvános és a magánkulcs használata?

      Egy másik cikkben már megosztottam, hogyan kell használni őket [1], most egyszerűen elmagyarázom egy másik módját ugyanez vagy valami hasonló elérésének.

      Mindenki a neki legmegfelelőbbet használja, azt, amelyet jobban szeret. Itt egyszerűen elmagyaráztam az sshpass egyik felhasználási lehetőségét, egy másik lehet egy Bash szkript, az SSH feltörése egy szótár használatával ... de tessék, ez csak egy újabb felhasználás.

      Ismétlem, csak a GNU / Linux-tal kapcsolatos ismereteimet osztom meg. Lehet, hogy az SSHPass nem minden esetben ideális választás, de hasznossága van, ne habozzon.

      BTW, hivatkozva a következőkre: (olyan alanyok hajtják végre, akik "rendszergazdának" hívják magukat) ... heh ... heh ... heh ... Inkább nem kommentálok, nincs mit bizonyítanom senkinek, nem beszélve arról, hogy a barátom, nincs még a legtávolabbi elképzelésed arról, hogy ki vagyok, annál kevésbé, mint amit ismerek 😉

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

      1.    linuxito dijo

        Ne légy ideges, előfordul, hogy a szakterületemen ismerek olyan embereket, akik munkájukat a Google-n alapítják, és a problémák megoldása során másolják és illesztik be az ilyen típusú dolgokat. Ekkor a biztonsági rendszergazda az, aki "a kerekeket a kerékbe rakja", amikor ilyen típusú rendellenességeket észlel. Egészségére!!

      2.    MSX dijo

        Nyugi ember, nem éri meg 😉

  2.   xykyz dijo

    Persze, de akkor a jelszó regisztrálásra kerül a használt parancsokban. Biztonsági okokból ezt nem szabad megtenni ...

    1.    davidlg dijo

      Erre gondoltam, amikor elolvastam a bejegyzést

    2.    KZKG ^ Gaara dijo

      Ha ezt hozzáadnánk a .bashrc fájlhoz, az nem mentené az sshpass fájlhoz kapcsolódó parancsokat:
      HISTIGNORE='sshpass *'

      Készítek egy bejegyzést arról, hogy hogyan lehet figyelmen kívül hagyni a parancsokat, nehogy hamarosan elmentődjenek a történelembe

      1.    angyalpenge dijo

        A parancsok elmentésének másik módja az, hogy a szó elé mindig egy szóközt helyezünk. ^ __ ^

  3.   Ignacio dijo

    Szerintem biztonságosabb, ha a kulcsokat használjuk az SSH-n keresztüli csatlakozáshoz, anélkül, hogy meg kellene adnunk a jelszót.

    Másrészről a teljes jelszó létrehozása, ahol a jelszó mentésre kerül, biztonsági problémát jelenthet.

  4.   Saito dijo

    Ha számomra hibának tűnik a számítógépes biztonságban, de biztosítani fogjuk, hogy ne kerüljenek mentésre a bash történelemben, nem annyira a probléma, mint mi (kivéve egy hatalmas álnevet), mint elav azt mondja a boltban adja el nekünk a kést, mi vagyunk azok, akik meglátják, mit kell használni

  5.   truko22 dijo

    Érdekes, de jobban használja a nyilvános és a magánkulcsot, amelyet egy másik bejegyzésben mutatott meg.

  6.   MSX dijo

    @KZKG
    Szerintem praktikusabb - és biztonságos! - használja az RSA / ECDSA kulcsokat egy kulcstartóval (SSH ügynök) együtt az automatikus hitelesítéshez.
    Esetemben egy SSH kulcstartót használok a kulcstartóhoz, amelyet a Funtoo emberei fejlesztettek ki, ami nagyon jól működik, nagyon kevés erőforrást használ fel és nagyon biztonságos:
    http://www.funtoo.org/Keychain

    Példa:

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

    Hogyan kell használni:
    SSHKEYGEN {ecdsa, rsa}
    SSHCOPYID {ecdsa, rsa} felhasználó @ {kiszolgáló, 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'

    ahol:
    -p #: port
    usr1 @ server1: felhasználó @ AVAHI szerver
    usr1@szerver1.local: user @ AVAHI szerver (attól függően, hogy a szerver hogyan van konfigurálva egyes rendszerekben, hozzá kell adni a .local utótagot)
    usr1 @ [addr. ip] .101: fix IP-cím.

    / etc / ssh / sshd_config: http://paste.chakra-project.org/4974/
    ~ / .ssh / config: http://paste.chakra-project.org/4975/
    Operációs rendszer: Arch Linux / Chakra

    Remélem, ez szolgál téged, üdvözlet!

    1.    KZKG ^ Gaara dijo

      Valójában kulcsokat használok, nem SSHPass-ot a szervereim eléréséhez ... Felfedeztem az SSHPass-ot, amikor szükségem volt egy módra a szkript végrehajtására: http://paste.desdelinux.net/4810

      De ... Nos, mindenkivel meg akartam osztani az SSHPass-t, de nyilvánvalóan nem tudtam ide tenni olyan szkriptet, amely lehetővé teszi egy szótár használatát az OpenSSH-Server HAHAHA megsértésére!

      1.    MSX dijo

        "[…] Nem tudtam ide tenni egy szkriptet, amely lehetővé teszi egy szótár használatát az OpenSSH-Server HAHAHA megsértésére!"
        De miért nem!!?
        A hackelés és a feltörés nem része a helyes biztonsági gyakorlatok elsajátításának [0]!
        Kérlek ember, hajrá !!!

        [0] Nem szép, ha szavakkal pontosan az ellenkezőjét értjük ahhoz, amit szó szerint értünk!? Hack a nyelvészet !!! ;-D

      2.    guzmanweb dijo

        Szia, ezt a hibát kapom:

        Jelszavakat tesztel a 192.168.20.11-re a 22. porton a root felhasználóval
        cat: con-letters.txt: Nincs ilyen fájl vagy könyvtár

        a letter.txt fájlt létrehozom?

        tekintetében

  7.   Eduardo dijo

    Ez nem történik meg, mivel a jelszót egyszerű szövegként tárolja a bash_history, eltekintve attól, hogy más módon megtudható. Tehát az ssh nem kér tőled jelszót, a helyes módszer a "nyilvános és magánkulcs".

  8.   oscar meza dijo

    Az RSA-t használom a távoli kapcsolódáshoz a szervereimhez, mégpedig úgy gondolom, hogy egy olyan számítógéphez való csatlakozás, ahol nincs szükségünk ilyen erős biztonságra, jó eszköz, köszönöm a tippet!

  9.   nelson dijo

    Chiuuuu

  10.   Nabukodonozor dijo

    És miért ne tenné közzé a jelszavamat, hogy bárki számára elérhető legyen?

  11.   Mario dijo

    Kiváló, hogy jó !!!!!! és spanyolul.

  12.   Gonzalo jarjury dijo

    Kiváló cikk, mint mindig, az emberek panaszkodnak ahelyett, hogy köszönnének, bár a módszer nem biztonságos, attól függ, hol és hogyan használod, nagyon köszönöm 🙂