Skicka SSH-lösenordet på samma rad med sshpass-paketet

För oss som använder SSH, det vill säga de av oss som ständigt behöver komma åt fjärrdatorer eller servrar i vår dagliga dag kommer till att bli trötta på att skriva lösenord, det skulle vara:

  1. Knappa in en terminal: ssh user @ server
  2. Vänta några sekunder
  3. Servern där vi vill ansluta kommer att be om lösenordet
  4. När vi väl har lagt in lösenordet och tryckt på [Enter] kommer vi åt fjärrservern

Och nu min fråga, är det inte enklare att bara skriva?:

sshpass -p «PASSWORD» ssh root@servidor

Antag till exempel att användaren är rotservern är: dev.desdelinux. Net och lösenordet är xunil ... då skulle linjen vara:

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

För att uppnå detta måste vi helt enkelt installera paketet sshpassVid Debian / Ubuntu eller derivat skulle vara med sudo apt-get installera sshpass samtidigt i archlinux eller derivat skulle räcka med sudo pacman -S sshpass

Om vi ​​vill ange porten (eftersom SSH inte finns på port 22) vi lägger till -p «PORT» ... det vill säga förutsatt att det är port 9122:

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

För att förenkla allt detta ännu mer vi kan skapa aliasTill exempel, när server1 körs, körs hela raden för att ansluta med SSH till server1 (sshpass -p lösenord användare @ server1) eller något liknande, så vi sparar också att sätta en för lång rad 😉

Hur som helst, jag hoppas att det här har varit användbart för dig.

Förresten, ett annat sätt att undvika att behöva skriva lösenordet när vi får åtkomst med SSH är att använda offentliga och privata nycklar.

hälsningar


Lämna din kommentar

Din e-postadress kommer inte att publiceras. Obligatoriska fält är markerade med *

*

*

  1. Ansvarig för uppgifterna: Miguel Ángel Gatón
  2. Syftet med uppgifterna: Kontrollera skräppost, kommentarhantering.
  3. Legitimering: Ditt samtycke
  4. Kommunikation av uppgifterna: Uppgifterna kommer inte att kommuniceras till tredje part förutom enligt laglig skyldighet.
  5. Datalagring: databas värd för Occentus Networks (EU)
  6. Rättigheter: När som helst kan du begränsa, återställa och radera din information.

  1.   linuxito sade

    Jag ber om ursäkt men detta är en fruktansvärd säkerhetsavvikelse !! Du har lösenordet fastnat i skript, vanliga textfiler, bash-historik etc.
    För det stöder openssh autentisering av offentlig nyckel med RSA.
    Tack vare denna typ av övning (implementerad av ämnen som kallar sig "administratörer") finns det så mycket datorosäkerhet.
    Hälsningar.

    1.    livlig sade

      Låt oss se. Ja, det är ett säkerhetsproblem men det betyder inte att "ämnen" som är administratörer eller inte behöver använda den här metoden. Metoden finns och visas om den behöver användas i en miljö där säkerhet inte är ett problem. I butiken säljer de dig kniven, du bestämmer dig för om du använder den för att skära grönsaker eller döda någon.

      1.    linuxito sade

        Jag förstår din ståndpunkt, men jag är ledsen att de i en sådan blogg uppmuntrar denna typ av praktik, det är nästan som en "ursäkt för den fruktansvärda systemadministrationen" hehe.
        En kram!!

        1.    livlig sade

          Jag förstår fortfarande inte vad problemet är 🙁

          Eftersom vi har talat om "hur man får mer säkerhet" i olika aspekter kan vi också tala om andra "mindre säkra" ämnen. Vårt mål är att erbjuda informationen, det är upp till dig att veta vad du ska göra med den. Dessutom kan författaren till det mest paranoida inlägget med säkerhet inte vara, tro mig, när det gäller systemadministration gör den inte den här typen av saker.

          Hälsningar 😉

          1.    linuxito sade

            Först när jag sa "implementerad av ämnen som kallar sig" administratörer "" hänvisade jag inte någon gång till författaren till artikeln, jag förstår inte varför de är så mottagliga.

            Problemet, ur min synvinkel, är att detta verktyg strider mot all säkerhetspraxis. Jag tror att vi från GNU / Linux-communityn måste hålla vårt värdefulla operativsystem så säkert som möjligt. Jag menar, jag skulle inte vilja se GNU / Linux förvandlas till Windows (säkerhetsmässigt).

            Tyvärr finns det många nybörjare som inte vet rätt sätt att göra saker och slutar använda dessa verktyg på kritiska system.

            Naturligtvis har du rätt att publicera vad du vill, men jag upprepar, jag är ledsen att den här bloggen (en av de viktigaste på det spanska språket) ger plats för verktyg som hotar säkerheten.

            Hälsningar!

            1.    livlig sade

              Och ge Juana med handfatet. Precis, eftersom det är en referensblogg, vill vi tillhandahålla all slags information. Jag förstår det här:

              En användare anländer och frågar: Hur kan jag ansluta till en server via SSH utan att fråga efter lösenordet?
              De svarar honom i vilket forum som helst: Nej, det är en säkerhetsfråga, ingen gör det.

              Även om han vet, berättar användaren inte varför det är ett säkerhetsproblem. Dåligt, väldigt dåligt, det är bra att du vet hur man gör saker, det är därför in Desdelinux:

              En användare anländer och frågar: Hur kan jag ansluta till en server via SSH utan att fråga efter lösenordet?
              Vi skriver ett inlägg och säger: Du kan använda den här metoden, den fungerar så men den är INTE SÄKER. Det säkraste är att använda den här andra.

              Vilken tycker du är bättre?


            2.    linuxito sade

              Okej, jag respekterar din hållning. Vänliga hälsningar!!


            3.    KZKG ^ Gaara sade

              SSHPass hotar faktiskt inte säkerheten, den som i alla fall hotar säkerheten är användaren som missbrukar den.
              Här är till exempel ett utmärkt exempel på att SSHPass inte bara används för det jag kommenterar i inlägget, det kan användas för (till exempel) krackning av OpenSSH-Server: http://paste.desdelinux.net/4810

              Applikationen är inget mer än det, en applikation, användningen som ges till det kommer att orsaka fel som äventyrar säkerheten eller inte.

              När det gäller nervös eller mottaglig, inte alls, kanske var det som du sa det (eller att läsning gör det svårt att förstå rätt) men jag tolkade att kommentaren riktades till mig, om det inte var så ber jag om ursäkt.

              PS: Visst kommer det att finnas flera som kommer att hitta manuset som jag lägger intressant och till och med roligt LOL!


            4.    linuxito sade

              Okej, jag är glad att vi nådde en överenskommelse. Skål!!


    2.    KZKG ^ Gaara sade

      Sa jag någonsin att den här metoden är säkrare än att använda offentliga och privata nycklar?

      I en annan artikel delade jag redan hur man använder dem [1], nu förklarar jag helt enkelt ett annat sätt att uppnå samma eller något liknande.

      Alla använder den som passar dem bäst, den de föredrar. Här förklarade jag helt enkelt en av användningarna som kan ges till sshpass, en annan kan vara genom ett Bash-skript för att knäcka SSH genom användning av en ordlista ... men kom igen, det här är bara en annan användning.

      Jag upprepar, jag delar bara min kunskap relaterad till GNU / Linux. SSHPass är kanske inte det perfekta valet i alla fall, men det har nytta, tveka inte.

      BTW, med hänvisning till: (implementerad av ämnen som kallar sig "administratörer") ... he ... he ... he ... Jag föredrar att inte kommentera, jag har inget att bevisa för någon, för att inte tala om att din min vän, du har inte den mest avlägsna idén om vem jag är, mycket mindre än vad jag vet 😉

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

      1.    linuxito sade

        Var inte nervös, det händer att jag inom mitt område känner människor som baserar sitt arbete på Google och när de löser problem kopierar och klistrar de in den här typen av saker. Då är säkerhetsadministratören den som "sätter hjulen i ratten" när han upptäcker sådana typer av avvikelser. Skål!!

      2.    MSX sade

        Koppla av man, det är inte värt det 😉

  2.   xykyz sade

    Visst, men då registreras lösenordet i de kommandon som används. Av säkerhetsskäl bör detta inte göras ...

    1.    davidlg sade

      Det var vad jag tänkte när jag läste inlägget

    2.    KZKG ^ Gaara sade

      Att lägga till detta i vår .bashrc skulle inte spara sshpass-relaterade kommandon:
      HISTIGNORE='sshpass *'

      Jag ska göra ett inlägg om hur man ignorerar kommandon så att de inte sparas i bash-historien snart :)

      1.    ängelblad sade

        Ett annat sätt för kommandon som inte ska sparas är att alltid placera ett mellanslag före kommandot. ^ __ ^

  3.   Ignacio sade

    Jag tror att det är säkrare att använda nycklar för att ansluta via SSH utan att behöva ange lösenordet.

    Å andra sidan kan det vara ett säkerhetsproblem att skapa ett fullständigt kommandoalias där lösenordet sparas.

  4.   Saito sade

    Om det för mig verkar ett fel i datasäkerheten, men vi kommer att se till att de inte sparas i bash-historien inte är så mycket det problemet vi gör (förutom ett alias som skulle vara enormt), också som elav säger i butik säljer oss kniven vi är de som kommer att se vad vi ska använda den

  5.   truko22 sade

    Intressant, men använd bättre den offentliga och privata nyckeln som du visade i en annan post.

  6.   MSX sade

    @KZKG
    Jag tycker att det är mer praktiskt - och säkert! - använd RSA / ECDSA-nycklar tillsammans med en nyckelring (SSH-agent) för automatisk autentisering.
    I mitt fall använder jag en SSH-nyckelring till nyckelring, utvecklad av folket på Funtoo, som fungerar mycket bra, använder mycket få resurser och är mycket säker:
    http://www.funtoo.org/Keychain

    Exempelvis:

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

    Hur man använder:
    SSHKEYGEN {ecdsa, rsa}
    SSHCOPYID {ecdsa, rsa} användare @ {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'

    Var:
    -p #: port
    usr1 @ server1: användare @ AVAHI-server
    usr1@server1.local: användare @ AVAHI-server (beroende på hur servern är konfigurerad i vissa system är det nödvändigt att lägga till suffixet .local)
    usr1 @ [addr. ip] .101: fast ip-adress.

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

    Jag hoppas att det tjänar dig, hälsningar!

    1.    KZKG ^ Gaara sade

      Jag använder faktiskt nycklar, inte SSHPass för att komma åt mina servrar ... Jag upptäckte SSHPass när jag behövde ett sätt att göra detta skript: http://paste.desdelinux.net/4810

      Men ... ja, jag ville dela SSHPass med alla, men uppenbarligen kunde jag inte lägga här ett skript som gör det möjligt att använda en ordlista för att försöka bryta mot OpenSSH-Server HAHAHA!

      1.    MSX sade

        «[...] Jag kunde inte sätta här ett skript som gör det möjligt att använda en ordbok för att försöka bryta mot OpenSSH-Server HAHAHA!»
        Men varför inte!!?
        Är hackning och sprickbildning inte en del av att lära sig bra säkerhetspraxis [0]!?
        Snälla man, fortsätt !!!

        [0] Är det inte vackert att använda ord för att betyda raka motsatsen till vad de bokstavligen betyder!? Hacka språkvetenskapen !!! ;-D

      2.    guzmanweb sade

        Hej, jag får det här felet:

        Det testar lösenord till 192.168.20.11 på port 22 med rotanvändaren
        cat: con-letters.txt: Ingen sådan fil eller katalog

        filen med letters.txt Jag skapar dem?

        gäller

  7.   Eduardo sade

    Detta görs inte, eftersom lösenordet lagras i bash_history som vanlig text, förutom vilket det kunde hittas på ett annat sätt. Så att ssh inte ber dig om ett lösenord, rätt sätt är med "offentliga och privata nycklar".

  8.   oscar meza sade

    Jag använder RSA för att fjärransluta till mina servrar, trots det tror jag att det är ett bra verktyg att ansluta till någon dator där vi inte behöver så stark säkerhet, tack för tipset!

  9.   nelson sade

    Chiuuuu

  10.   Nebukadnessar sade

    Och varför bättre inte publicera mitt lösenord så att det är tillgängligt för någon?

  11.   mario sade

    Utmärkt så bra !!!!!! och på spanska.

  12.   Gonzalo jarjury sade

    Utmärkt artikel, som alltid klagar folk istället för att tacka, även om metoden är osäker beror det på var och hur du använder den, tack så mycket 🙂