Send SSH-passordet på samme linje med sshpass-pakken

For de av oss som bruker SSHdet vil si at de av oss som trenger å få tilgang til eksterne datamaskiner eller servere hele tiden i vårt daglige liv, kommer til å bli lei av å skrive passord, det vil være:

  1. Tast inn en terminal: ssh user @ server
  2. Vent noen sekunder
  3. Serveren der vi vil koble til vil be om passordet
  4. Når vi setter passordet og trykker på [Enter], får vi tilgang til den eksterne serveren

Og nå er spørsmålet mitt, er det ikke enklere å bare skrive?:

sshpass -p «PASSWORD» ssh root@servidor

Anta for eksempel at brukeren er det root, serveren er: dev.desdelinux. Net og passordet er xunil ... da ville linjen være:

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

For å oppnå dette må vi bare installere pakken sshpassDebian / Ubuntu eller derivater ville være med sudo apt-get installer sshpass I mellomtiden i Arch Linux eller derivater ville være tilstrekkelig med sudo pacman -S sshpass

Hvis vi vil spesifisere porten (siden SSH ikke er i port 22) vi legger til -p «PORT» ... det vil si forutsatt at det er port 9122:

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

For å forenkle alt dette enda mer vi kan lage aliaserFor eksempel, når du kjører server1, blir hele linjen utført for å koble SSH til server1 (sshpass -p passord bruker @ server1) eller noe lignende, så vi sparer også å sette en linje for lenge 😉

Uansett håper jeg dette har vært nyttig for deg.

Forresten, en annen måte å unngå å måtte skrive passordet når vi får tilgang til med SSH, er å bruke offentlige og private nøkler.

Hilsen


29 kommentarer, legg igjen dine

Legg igjen kommentaren

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *

*

*

  1. Ansvarlig for dataene: Miguel Ángel Gatón
  2. Formålet med dataene: Kontroller SPAM, kommentaradministrasjon.
  3. Legitimering: Ditt samtykke
  4. Kommunikasjon av dataene: Dataene vil ikke bli kommunisert til tredjeparter bortsett fra ved juridisk forpliktelse.
  5. Datalagring: Database vert for Occentus Networks (EU)
  6. Rettigheter: Når som helst kan du begrense, gjenopprette og slette informasjonen din.

  1.   linuxito sa

    Jeg beklager, men dette er en forferdelig sikkerhetsavvik !! Du har passordet fast i skript, vanlige tekstfiler, bash-historie osv.
    For det støtter openssh autentisering av offentlig nøkkel ved hjelp av RSA.
    Takket være denne typen praksis (implementert av fag som kaller seg "administratorer") er det så mye datamaskinusikkerhet.
    Hilsener.

    1.    livlig sa

      La oss se. Ja, det er et sikkerhetsproblem, men det betyr ikke at "fag" som er administratorer eller ikke trenger å bruke denne metoden. Metoden eksisterer og vises i tilfelle den må brukes i et miljø der sikkerhet ikke er et problem. I butikken selger de deg kniven, du bestemmer deg for om du bruker den til å kutte grønnsaker eller drepe noen.

      1.    linuxito sa

        Jeg forstår din posisjon, men jeg er lei meg for at de i en blogg med en slik anerkjennelse fremmer denne typen praksis, det er nesten som en "unnskyldning for den forferdelige systemadministrasjonen" hehe.
        En klem!!

        1.    livlig sa

          Jeg forstår fortsatt ikke hva problemet er 🙁

          Ettersom vi har snakket om "hvordan få mer sikkerhet" i forskjellige aspekter, kan vi også snakke om andre "mindre sikre" emner. Målet vårt er å tilby informasjonen, det er opp til deg å vite hva du skal gjøre med den. I tillegg kan ikke forfatteren av det mest paranoide innlegget med sikkerhet være, tro meg, når det gjelder systemadministrasjon, gjør det ikke denne typen ting.

          Hilsen 😉

          1.    linuxito sa

            Først, da jeg sa "implementert av fag som kaller seg" administratorer ", henviste jeg ikke på noe tidspunkt til forfatteren av artikkelen, jeg forstår ikke hvorfor de er så utsatt.

            Problemet, fra mitt synspunkt, er at dette verktøyet strider mot all god sikkerhetspraksis. Jeg tror at fra GNU / Linux-fellesskapet må vi holde vårt dyrebare operativsystem så sikkert som mulig. Jeg mener, jeg vil ikke se GNU / Linux omgjort til Windows (sikkerhetsmessig).

            Dessverre er det mange nybegynnere som ikke vet riktig måte å gjøre ting på, og ender opp med å bruke disse verktøyene på kritiske systemer.

            Selvfølgelig har du rett til å publisere hva du vil, men jeg gjentar, det er trist for meg at denne bloggen (en av de viktigste spansktalende bloggene) gir vei for verktøy som truer sikkerhet.

            Hilsener !!

            1.    livlig sa

              Og gi Juana med bassenget. Nettopp fordi det er en referanseblogg, liker vi å gi all slags informasjon. Jeg forstår dette:

              En bruker kommer og spør: Hvordan kan jeg koble til en server via SSH uten å be om passordet?
              De svarer ham i ethvert forum: Noooo, det er et sikkerhetsproblem, ingen gjør det.

              Aún sabiendo, el usuario no le dice porque es un problema de seguridad. Mal, muy mal, es bueno que se sepa como hacer las cosas, por eso en Desdelinux:

              En bruker kommer og spør: Hvordan kan jeg koble til en server via SSH uten å be om passordet?
              Vi skriver et innlegg og sier: Du kan bruke denne metoden, den fungerer på denne måten, men den er IKKE SIKKER. Det tryggeste er å bruke denne andre.

              Hvilken mener du er bedre?


            2.    linuxito sa

              Ok, jeg respekterer holdningen din. Med vennlig hilsen!!


            3.    KZKG ^ Gaara sa

              SSHPass truer faktisk ikke sikkerheten, den som i alle fall truer sikkerheten er brukeren som misbruker den.
              For eksempel, her er et utmerket eksempel på at SSHPass ikke bare brukes til det jeg kommenterer i innlegget, det kan brukes til (for eksempel) sprekking av OpenSSH-Server: http://paste.desdelinux.net/4810

              Søknaden er ikke noe mer enn det, en applikasjon, bruken som gis til den er det som vil forårsake feil som kompromitterer sikkerheten eller ikke.

              Når det gjelder nervøs eller mottakelig, i det hele tatt, var det kanskje slik du sa det (eller at lesing gjør det vanskelig å forstå riktig), men jeg tolket at kommentaren var rettet mot meg, hvis ikke, beklager jeg.

              PS: Det vil sikkert være flere som vil finne manuset som jeg la interessant og til og med morsomt LOL!


            4.    linuxito sa

              Ok, jeg er glad vi kom til enighet. Jubel!!


    2.    KZKG ^ Gaara sa

      Sa jeg noen gang at denne metoden er sikrere enn å bruke offentlige og private nøkler?

      I en annen artikkel delte jeg allerede hvordan jeg skulle bruke dem [1], nå forklarer jeg ganske enkelt en annen måte å oppnå det samme eller noe lignende.

      Alle bruker den som passer dem best, den de foretrekker. Her forklarte jeg ganske enkelt en av bruksområdene som kan gis til sshpass, en annen kan være gjennom et Bash-skript for å knekke SSH gjennom bruk av en ordbok ... men kom igjen, dette er bare en annen bruk.

      Jeg gjentar, jeg deler bare min kunnskap relatert til GNU / Linux. SSHPass er kanskje ikke det ideelle valget i alle tilfeller, men det har nytte, ikke nøl.

      BTW, med henvisning til: (implementert av fag som kaller seg "administratorer") ... he ... he ... he ... Jeg foretrekker ikke å kommentere, jeg har ingenting å bevise for noen, for ikke å nevne at din venn av meg, du har ikke den fjerneste ideen om hvem jeg er, mye mindre enn det jeg vet 😉

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

      1.    linuxito sa

        Ikke vær nervøs, det hender at jeg i mitt felt kjenner folk som baserer sitt arbeid på Google, og når de løser problemer kopierer og limer de inn denne typen ting. Da er sikkerhetsadministratoren den som "setter hjulene i rattet" når han oppdager slike avvik. Jubel!!

      2.    MSX sa

        Slapp av mann, det er ikke verdt det 😉

  2.   xykyz sa

    Jada, men da blir passordet registrert i kommandoene som brukes. Av sikkerhetsmessige grunner bør dette ikke gjøres ...

    1.    davidlg sa

      Det var det jeg tenkte da jeg leste innlegget

    2.    KZKG ^ Gaara sa

      Hvis du legger til dette i .bashrc, lagres ikke sshpass-relaterte kommandoer:
      HISTIGNORE='sshpass *'

      Jeg skal gjøre et innlegg om hvordan jeg kan ignorere kommandoer, slik at de ikke blir lagret i bash-historien snart :)

      1.    engelblad sa

        En annen måte for kommandoer som ikke skal lagres, er å alltid plassere et mellomrom foran kommandoen. ^ __ ^

  3.   Ignacio sa

    Jeg tror det er tryggere å bruke nøkler til å koble til via SSH uten å måtte oppgi passordet.

    På den annen side kan det være et sikkerhetsproblem å opprette et fullstendig kommandoalias der passordet lagres.

  4.   Saito sa

    Hvis det virker som en feil i datasikkerhet, men vi skal sørge for at de ikke blir lagret i bash-historien, er ikke det så mye problemet vi gjør (bortsett fra et alias som ville være stort), også som elav sier i butikken selg oss kniven vi er de som vil se hva vi skal bruke den

  5.   truko22 sa

    Interessant, men bruk bedre den offentlige og private nøkkelen som du viste i en annen oppføring.

  6.   MSX sa

    @KZKG
    Jeg tror det er mer praktisk - og trygt! - bruk RSA / ECDSA-nøkler sammen med en nøkkelring (SSH-agent) for automatisk autentisering.
    I mitt tilfelle bruker jeg en SSH-nøkkelring til nøkkelring, utviklet av folkene på Funtoo, som fungerer veldig bra, bruker svært få ressurser og er veldig sikker:
    http://www.funtoo.org/Keychain

    Eksempel:

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

    Hvordan å bruke:
    SSHKEYGEN {ecdsa, rsa}
    SSHCOPYID {ecdsa, rsa} bruker @ {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'

    Hvor:
    -p #: port
    usr1 @ server1: bruker @ AVAHI-server
    usr1@server1.local: bruker @ AVAHI-server (avhengig av hvordan serveren er konfigurert i noen systemer, er det nødvendig å legge til suffikset .local)
    usr1 @ [addr. ip] .101: fast ip-adresse.

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

    Jeg håper det serverer deg, hilsener!

    1.    KZKG ^ Gaara sa

      Jeg bruker faktisk nøkler, ikke SSHPass for å få tilgang til serverne mine ... Jeg oppdaget SSHPass da jeg trengte en måte å gjøre dette skriptet på: http://paste.desdelinux.net/4810

      Men ... vel, jeg ønsket å dele SSHPass med alle, men tydeligvis kunne jeg ikke legge et skript her som tillater å bruke en ordbok for å prøve å bryte OpenSSH-Server HAHAHA!

      1.    MSX sa

        «[…] Jeg kunne ikke legge et skript her som lar en ordbok prøve å bryte OpenSSH-Server HAHAHA!"
        Men hvorfor ikke!!?
        Er ikke hacking og sprekker en del av å lære god sikkerhetspraksis [0]!?
        Vennligst mann, fortsett!

        [0] Er det ikke vakkert å bruke ord for å bety det stikk motsatte av hva de bokstavelig talt betyr!? Hack språkvitenskapen !!! ;-D

      2.    guzmanweb sa

        Hei, jeg får denne feilen:

        Den tester passord til 192.168.20.11 på port 22 med rotbrukeren
        cat: con-letters.txt: Ingen slik fil eller katalog

        filen med letters.txt Jeg oppretter dem?

        hilsen

  7.   Eduardo sa

    Dette gjøres ikke, siden passordet er lagret i bash_history som ren tekst, bortsett fra at det kunne bli funnet ut på en annen måte. Så at ssh ikke ber deg om passord, er den riktige måten med "offentlige og private nøkler".

  8.   oscar meza sa

    Jeg bruker RSA for å koble til serverne mine eksternt, selv om jeg tror at å koble til en datamaskin der vi ikke trenger så sterk sikkerhet er et godt verktøy, takk for tipset!

  9.   Nelson sa

    Chiuuuu

  10.   Nebukadnesar sa

    Og hvorfor må jeg ikke publisere passordet mitt slik at det er tilgjengelig for noen?

  11.   mario sa

    Utmerket så bra !!!!!! og på spansk.

  12.   Gonzalo jarjury sa

    Utmerket artikkel, som alltid klager folk i stedet for å takke, selv om metoden er usikker, kommer det an på hvor og hvordan du bruker den, tusen takk 🙂