Invia la password SSH sulla stessa riga del pacchetto sshpass

Per quelli di noi che usano il SSH, cioè, quelli di noi che hanno bisogno di accedere costantemente a computer o server remoti nella nostra vita quotidiana arrivano al punto di stufarsi di digitare password, sarebbe:

  1. Digitare un terminale: ssh user @ server
  2. Aspetta qualche secondo
  3. Il server a cui vogliamo connetterci chiederà la password
  4. Una volta inserita la password e premuto [Invio], accederemo al server remoto

E ora la mia domanda, non è più semplice digitare?:

sshpass -p «PASSWORD» ssh root@servidor

Ad esempio, supponiamo che l'utente sia radice, il server è: sviluppatoredesdelinux.net e la password è xunil ... allora la linea sarebbe:

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

Per ottenere ciò dobbiamo semplicemente installare il pacchetto sshpassin Debian / Ubuntu o i derivati ​​sarebbero con sudo apt-get installa sshpass mentre dentro ArchLinux o derivati ​​sarebbero sufficienti con sudo pacman -S sshpass

Se vogliamo specificare la porta (perché SSH non è sulla porta 22) noi aggiungiamo -p «PORTA» ... cioè, supponendo che sia la porta 9122:

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

Per semplificare ancora di più tutto questo possiamo creare alias, ad esempio, quando si esegue server1 l'intera riga viene eseguita per connettersi da SSH al server1 (sshpass -p password utente @ server1) o qualcosa di simile, quindi risparmiamo anche di mettere una linea troppo lunga 😉

Comunque, spero che questo ti sia stato utile.

A proposito, un altro modo per evitare di dover scrivere la password quando accediamo tramite SSH è usare chiavi pubbliche e private.

saluti


Lascia un tuo commento

L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati con *

*

*

  1. Responsabile dei dati: Miguel Ángel Gatón
  2. Scopo dei dati: controllo SPAM, gestione commenti.
  3. Legittimazione: il tuo consenso
  4. Comunicazione dei dati: I dati non saranno oggetto di comunicazione a terzi se non per obbligo di legge.
  5. Archiviazione dati: database ospitato da Occentus Networks (UE)
  6. Diritti: in qualsiasi momento puoi limitare, recuperare ed eliminare le tue informazioni.

  1.   linuxito suddetto

    Mi scuso ma questa è una terribile aberrazione di sicurezza !! Hai la password bloccata in script, file di testo semplice, cronologia bash, ecc.
    Per questo, openssh supporta l'autenticazione con chiave pubblica utilizzando RSA.
    Grazie a questo tipo di pratica (messa in atto da soggetti che si definiscono "amministratori") c'è tanta insicurezza informatica.
    Saluti.

    1.    vivace suddetto

      Vediamo. Sì, è un problema di sicurezza ma non significa che "soggetti" che sono o non sono amministratori devono utilizzare questo metodo. Il metodo esiste e viene mostrato nel caso in cui debba essere utilizzato in un ambiente in cui la sicurezza non è un problema. Nel negozio ti vendono il coltello, decidi tu se usarlo per tagliare le verdure o uccidere qualcuno.

      1.    linuxito suddetto

        Capisco la tua posizione, ma mi dispiace che in un blog di tale fama promuovano questo tipo di pratica, è quasi come una "scusa per la terribile amministrazione dei sistemi" hehe.
        Un abbraccio!!

        1.    vivace suddetto

          Continuo a non capire qual è il problema 🙁

          Poiché abbiamo parlato di "come ottenere più sicurezza" in vari aspetti, possiamo parlare anche di altri argomenti "meno sicuri". Il nostro obiettivo è offrire le informazioni, sta a te sapere cosa farne. Inoltre, l'autore del post più paranoico con la sicurezza non può essere, credimi, quando si tratta di amministrazione del sistema, non fa questo genere di cose.

          Saluti 😉

          1.    linuxito suddetto

            Per prima cosa, quando ho detto 'attuato da soggetti che si definiscono "amministratori"', non mi sono mai riferito all'autore dell'articolo, non capisco perché siano così suscettibili.

            Il problema, dal mio punto di vista, è che questo strumento va contro tutte le buone pratiche di sicurezza. Credo che dalla comunità GNU / Linux dobbiamo mantenere il nostro prezioso sistema operativo il più sicuro possibile. Voglio dire, non mi piacerebbe vedere GNU / Linux trasformato in Windows (dal punto di vista della sicurezza).

            Sfortunatamente ci sono molti amministratori inesperti che non conoscono il modo corretto di fare le cose e finiscono per utilizzare questi strumenti su sistemi critici.

            Ovviamente hai il diritto di pubblicare quello che vuoi, ma ripeto, mi dispiace che questo blog (uno dei più importanti in lingua spagnola) dia il posto a strumenti che minacciano la sicurezza.

            Auguri !!

            1.    vivace suddetto

              E da Juana con il catino. Proprio perché è un blog di riferimento, ci piace fornire ogni tipo di informazione. Lo capisco:

              Un utente arriva e chiede: Come posso connettermi a un server tramite SSH senza chiedere la password?
              Gli rispondono in qualsiasi forum: Noooo, questo è un problema di sicurezza, nessuno lo fa.

              Pur sapendolo, l'utente non gli dice perché si tratta di un problema di sicurezza. Male, molto male, è un bene che tu sappia fare le cose, ecco perché Desdelinux:

              Un utente arriva e chiede: Come posso connettermi a un server tramite SSH senza chiedere la password?
              Scriviamo un post e diciamo: Puoi usare questo metodo, funziona in questo modo ma NON È SICURO. La cosa più sicura è usare quest'altro.

              Quale pensi sia meglio?


            2.    linuxito suddetto

              Ok, rispetto la tua postura. I migliori saluti!!


            3.    KZKG ^ Gaara suddetto

              SSHPass in realtà non minaccia la sicurezza, la persona che minaccia la sicurezza in ogni caso è l'utente che ne fa cattivo uso.
              Ad esempio, ecco un eccellente esempio che SSHPass non viene utilizzato solo per ciò che commento nel post, ma può essere utilizzato (ad esempio) per il cracking di OpenSSH-Server: http://paste.desdelinux.net/4810

              L'applicazione non è altro che questo, un'applicazione, l'uso che le viene dato è ciò che provocherà guasti che compromettono o meno la sicurezza.

              Per quanto riguarda nervoso o suscettibile, a tutti, forse è stato il modo in cui l'hai detto (o che la lettura rende difficile la comprensione corretta) ma ho interpretato che il commento era diretto a me, se non lo era, chiedo scusa.

              PS: Sicuramente ci saranno diversi che troveranno la sceneggiatura che ho messo interessante e anche divertente LOL!


            4.    linuxito suddetto

              Ok, sono contento che abbiamo raggiunto un accordo. Saluti!!


    2.    KZKG ^ Gaara suddetto

      Ho mai detto che questo metodo è più sicuro rispetto all'utilizzo di chiavi pubbliche e private?

      In un altro articolo ho già condiviso come usarli [1], ora spiego semplicemente un altro modo per ottenere lo stesso o qualcosa di simile.

      Ognuno usa quello che gli si addice meglio, quello che preferisce. Qui ho semplicemente spiegato uno degli usi che possono essere dati a sshpass, un altro potrebbe essere attraverso uno script Bash per crackare SSH attraverso l'uso di un dizionario ... ma dai, questo è solo un altro uso.

      Ripeto, condivido solo le mie conoscenze relative a GNU / Linux. SSHPass potrebbe non essere la scelta ideale per ogni caso, ma ha utilità, non esitate.

      A proposito, riferendosi a: (implementato da soggetti che si definiscono "amministratori") ... eh ... eh ... eh ... preferisco non commentare, non ho nulla da dimostrare a nessuno, senza contare che il tuo amico mio, tu non hai la più remota idea di chi sono, tanto meno di quello che so 😉

      , https://blog.desdelinux.net/ssh-sin-password-solo-3-pasos/

      1.    linuxito suddetto

        Non ti innervosire, capita che nel mio campo conosca persone che basano il loro lavoro su Google e quando risolvono problemi copiano e incollano questo tipo di cose. Quindi l'amministratore della sicurezza è colui che "mette le ruote al volante" quando rileva questi tipi di anomalie. Saluti!!

      2.    msx suddetto

        Rilassati amico, non ne vale la pena 😉

  2.   xykyz suddetto

    Certo, ma poi la password è registrata nei comandi utilizzati. Per motivi di sicurezza, questo non dovrebbe essere fatto ...

    1.    davide suddetto

      Questo è quello che stavo pensando leggendo il post

    2.    KZKG ^ Gaara suddetto

      L'aggiunta di questo al nostro .bashrc non salverebbe i comandi relativi a sshpass:
      HISTIGNORE='sshpass *'

      Farò un post su come ignorare i comandi in modo che non vengano salvati nella cronologia bash a breve :)

      1.    lama d'angelo suddetto

        Un altro modo per non salvare i comandi è mettere sempre uno spazio prima del comando. ^ __ ^

  3.   Ignacio suddetto

    Penso che sia più sicuro usare le chiavi per connettersi tramite SSH senza dover inserire la password.

    D'altra parte, la creazione di un alias di comando completo in cui viene salvata la password può essere un problema di sicurezza.

  4.   Saito suddetto

    Se mi sembra un difetto nella sicurezza informatica, ma ci accerteremo che non vengano salvati nella cronologia bash non è tanto il problema che facciamo (tranne che per un alias che sarebbe enorme), anche come elav dice in negozio vendici il coltello siamo noi che vedremo cosa usarlo

  5.   camion22 suddetto

    Interessante, ma meglio usare la chiave pubblica e privata che hai mostrato in un'altra voce.

  6.   msx suddetto

    @KZKG
    Penso che sia più pratico e sicuro! - utilizzare chiavi RSA / ECDSA insieme a un portachiavi (agente SSH) per l'autenticazione automatica.
    Nel mio caso, utilizzo un portachiavi SSH per portachiavi, sviluppato dalle persone di Funtoo, che funziona molto bene, utilizza pochissime risorse ed è molto sicuro:
    http://www.funtoo.org/Keychain

    Esempio:

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

    Come usare:
    SSHKEYGEN {ecdsa, rsa}
    SSHCOPYID {ecdsa, rsa} utente @ {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'

    Dove:
    -p #: porta
    usr1 @ server1: utente @ AVAHI server
    usr1@server1.local: user @ AVAHI server (a seconda di come il server è configurato in alcuni sistemi è necessario aggiungere il suffisso .local)
    usr1 @ [addr. ip] .101: indirizzo ip fisso.

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

    Spero ti serva, saluti!

    1.    KZKG ^ Gaara suddetto

      In effetti uso le chiavi, non SSHPass per accedere ai miei server ... Ho scoperto SSHPass quando avevo bisogno di un modo per fare questo script: http://paste.desdelinux.net/4810

      Ma ... beh, volevo condividere SSHPass con tutti, ma ovviamente non ho potuto mettere qui uno script che permetta di utilizzare un dizionario per tentare di violare OpenSSH-Server HAHAHA!

      1.    msx suddetto

        "[…] Non potrei mettere qui uno script che consenta di utilizzare un dizionario per tentare di violare OpenSSH-Server HAHAHA!"
        Ma perchè no!!?
        L'hacking e il cracking non fanno parte dell'apprendimento di buone pratiche di sicurezza [0] !?
        Per favore amico, vai avanti !!!

        [0] Non è bello usare le parole per indicare l'esatto opposto di ciò che significano letteralmente !? Hack la linguistica !!! ;-D

      2.    guzmanweb suddetto

        Ciao, ricevo questo errore:

        Sta testando le password per 192.168.20.11 sulla porta 22 con l'utente root
        cat: con-letters.txt: nessun file o directory di questo tipo

        il file con letters.txt li creo?

        saluti

  7.   Eduardo suddetto

    Questo non viene fatto, poiché la password è memorizzata in bash_history come testo normale, a parte questo potrebbe essere trovata in un altro modo. In modo che ssh non ti chieda una password, il modo corretto è con "chiavi pubbliche e private".

  8.   Oscar Mezza suddetto

    Uso RSA per connettermi ai miei server da remoto, anche se penso che connettermi a un computer dove non abbiamo bisogno di una sicurezza così forte sia un buon strumento, grazie per il suggerimento!

  9.   Nelson suddetto

    Chiuuuu

  10.   Nabucodonosor suddetto

    E perché è meglio non pubblicare la mia password in modo che sia disponibile a chiunque?

  11.   mario suddetto

    Eccellente che bravo !!!!!! e in spagnolo.

  12.   Gonzalo jarjury suddetto

    Ottimo articolo, come sempre le persone si lamentano invece di ringraziare, anche se il metodo non è sicuro dipende da dove e come lo usi, grazie mille 🙂