SSH şifresini sshpass paketi ile aynı satırda gönderin

Kullananlar için SSHyani, günlük hayatımızda sürekli olarak uzak bilgisayarlara veya sunuculara erişmesi gerekenler, şifreleri yazmaktan sıkılma noktasına gelirler, bu şöyle olur:

  1. Bir terminal girin: ssh user @ server
  2. Birkaç saniye bekleyin
  3. Bağlanmak istediğimiz sunucu şifreyi isteyecek
  4. Şifreyi girip [Enter] tuşuna bastıktan sonra uzak sunucuya erişeceğiz

Ve şimdi sorum, sadece yazmak daha kolay değil mi?

sshpass -p «PASSWORD» ssh root@servidor

Örneğin, kullanıcının kök, sunucu: geliştiricidesdelinux. Net ve şifre Xunil ... o zaman satır şöyle olacaktır:

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

Bunu başarmak için sadece paketi kurmamız gerekiyor sshpassiçinde Debian / Ubuntu veya türevler ile olacaktır sudo uygun-get sshpass'ı yükle Bu arada Arch Linux veya türevler yeterli olacaktır sudo pacman -S sshpass

Bağlantı noktasını belirtmek istersek (SSH 22 numaralı bağlantı noktasında olmadığı için) ekleriz -p «LİMAN» ... yani, 9122 numaralı bağlantı noktası olduğunu varsayarsak:

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

Bütün bunları daha da basitleştirmek için takma adlar oluşturabilirizörneğin, sunucu1 yürütülürken tüm satır SSH tarafından sunucu1'e bağlanmak için yürütülür (sshpass -p parola kullanıcı @ sunucu1) veya benzer bir şey, bu yüzden çok uzun bir satır koymayı da kaydediyoruz 😉

Her neyse, umarım bu sizin için yararlı olmuştur.

Bu arada, SSH ile eriştiğimizde şifreyi yazmak zorunda kalmamanın başka bir yolu da kullanmaktır. genel ve özel anahtarlar.

selamlar


Yorumunuzu bırakın

E-posta hesabınız yayınlanmayacak. Gerekli alanlar ile işaretlenmiştir *

*

*

  1. Verilerden sorumlu: Miguel Ángel Gatón
  2. Verilerin amacı: Kontrol SPAM, yorum yönetimi.
  3. Meşruiyet: Onayınız
  4. Verilerin iletilmesi: Veriler, yasal zorunluluk dışında üçüncü kişilere iletilmeyecektir.
  5. Veri depolama: Occentus Networks (AB) tarafından barındırılan veritabanı
  6. Haklar: Bilgilerinizi istediğiniz zaman sınırlayabilir, kurtarabilir ve silebilirsiniz.

  1.   linuxito dijo

    Özür dilerim ama bu korkunç bir güvenlik sapması !! Şifreniz komut dosyalarına, düz metin dosyalarına, bash geçmişine vb. Sıkışmış durumda.
    Bunun için openssh, RSA kullanarak ortak anahtar kimlik doğrulamasını destekler.
    Bu tür uygulamalar sayesinde (kendilerini "yönetici" olarak adlandıran denekler tarafından uygulanan) çok fazla bilgisayar güvensizliği var.
    Selamlar.

    1.    ela dijo

      Bakalım. Evet, bu bir güvenlik sorunudur, ancak yönetici olan veya olmayan "öznelerin" bu yöntemi kullanması gerektiği anlamına gelmez. Yöntem vardır ve güvenliğin bir sorun olmadığı bir ortamda kullanılması gerektiğinde gösterilir. Mağazada size bıçak satarlar, onu sebzeleri kesmek veya birini öldürmek için kullanıp kullanmayacağınıza siz karar verirsiniz.

      1.    linuxito dijo

        Durumunuzu anlıyorum, ancak böylesine ünlü bir blogda bu tür uygulamaları teşvik ettikleri için üzgünüm, neredeyse "korkunç sistem yönetimi için bir özür" hehe gibi.
        Sarılmak!!

        1.    ela dijo

          Hala sorunun ne olduğunu anlamıyorum 🙁

          Çeşitli yönlerden "nasıl daha fazla güvenlik elde edileceğinden" söz ettiğimiz gibi, diğer "daha az güvenli" konulardan da bahsedebiliriz. Amacımız bilgiyi sunmaktır, onunla ne yapacağınızı bilmek size kalmıştır. Ayrıca, güvenlikle en paranoyak gönderinin yazarı olamaz, inanın Sistem Yönetimi söz konusu olduğunda, bu tür bir şey yapmaz.

          Selamlar 😉

          1.    linuxito dijo

            Birincisi, 'kendilerine yönetici diyen denekler tarafından uygulandı' dediğimde, makalenin yazarına hiçbir zaman atıfta bulunmadım, neden bu kadar duyarlı olduklarını anlamıyorum.

            Benim bakış açıma göre sorun, bu aracın tüm iyi güvenlik uygulamalarına aykırı olmasıdır. GNU / Linux topluluğundan değerli işletim sistemimizi olabildiğince güvenli tutmamız gerektiğine inanıyorum. Demek istediğim, GNU / Linux'un Windows'a dönüştüğünü (güvenlik açısından) görmek istemem.

            Ne yazık ki, işleri yapmanın doğru yolunu bilmeyen ve bu araçları kritik sistemlerde kullanan birçok acemi yönetici var.

            Elbette istediğinizi yayınlama hakkınız var, ancak tekrar ediyorum, bu blog (İspanyolca'daki en önemli bloglardan biri) güvenliği tehdit eden araçların ortaya çıkmasına neden olduğu için üzgünüm.

            Selamlar!

            1.    ela dijo

              Ve Juana'ya leğeni ver. Kesinlikle bir referans blog olduğu için her türlü bilgiyi vermeyi seviyoruz. Bunu anladım:

              Bir kullanıcı gelir ve sorar: Şifre sormadan SSH aracılığıyla bir sunucuya nasıl bağlanabilirim?
              Ona herhangi bir forumda cevap veriyorlar: Noooo, bu bir güvenlik sorunu, kimse bunu yapmıyor.

              Kullanıcı bunu bilse bile bunun neden bir güvenlik sorunu olduğunu ona söylemiyor. Kötü, çok kötü, işlerin nasıl yapılacağını bilmen iyi, bu yüzden Desdelinux:

              Bir kullanıcı gelir ve sorar: Şifre sormadan SSH aracılığıyla bir sunucuya nasıl bağlanabilirim?
              Bir gönderi yazıp diyoruz: Bu yöntemi kullanabilirsiniz, bu şekilde çalışır ancak GÜVENLİ DEĞİLDİR. En güvenli şey diğerini kullanmaktır.

              Sence hangisi daha iyi?


            2.    linuxito dijo

              Tamam, duruşuna saygı duyuyorum. Saygılarımla!!


            3.    KZKG ^ Gaara dijo

              SSHPass aslında güvenliği tehdit etmez, her durumda güvenliği tehdit eden kişi onu kötüye kullanan kullanıcıdır.
              Örneğin, burada SSHPass'ın yalnızca gönderide yorumladığım şeyler için değil, (örneğin) OpenSSH-Server'ı kırmak için kullanılabileceğine dair mükemmel bir örnek var: http://paste.desdelinux.net/4810

              Uygulama bundan başka bir şey değil, bir uygulama, verilen kullanım, güvenliği tehlikeye atan ya da olmayan arızalara neden olacak olan şeydir.

              Gergin ya da duyarlı olmakla ilgili olarak, hiç de değil, belki de bunu söyledin (ya da okumak doğru anlamayı zorlaştırıyor) ama yorumun bana yönelik olduğunu yorumladım, değilse özür dilerim.

              Not: Elbette koyduğum senaryoyu ilginç ve hatta komik LOL bulacak birkaç kişi olacak!


            4.    linuxito dijo

              Tamam, bir anlaşmaya vardığımıza sevindim. Şerefe !!


    2.    KZKG ^ Gaara dijo

      Bu yöntemin genel ve özel anahtarları kullanmaktan daha güvenli olduğunu hiç söylemiş miydim?

      Başka bir makalede, bunların nasıl kullanılacağını zaten paylaşmıştım [1], şimdi basitçe aynısını veya benzerini elde etmenin başka bir yolunu açıklıyorum.

      Herkes kendisine en çok uyanı, tercih ettiği birini kullanır. Burada sshpass'a verilebilecek kullanımlardan birini basitçe açıkladım, diğeri bir Bash betiği aracılığıyla SSH'yi bir sözlük kullanarak kırmak olabilir ... ama hadi, bu başka bir kullanım.

      Tekrar ediyorum, sadece GNU / Linux ile ilgili bilgilerimi paylaşıyorum. SSHPass herhangi bir durum için ideal seçim olmayabilir, ancak faydası vardır, tereddüt etmeyin.

      BTW, atıfta bulunarak: (kendilerini "yöneticiler" olarak adlandıran denekler tarafından uygulandı) ... heh ... heh ... heh ... Bir fikir vermeyi tercih etmiyorum, kimseye kanıtlayacak hiçbir şeyim yok, arkadaşımın, senin en fazlasına sahip olmadığını bile kim olduğuma dair uzaktan bir fikir, bildiğimden çok daha az 😉

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

      1.    linuxito dijo

        Endişelenmeyin, benim alanımda çalışmalarını Google'a dayandıran insanları tanıyorum ve sorunları çözerken bu tür şeyleri kopyalayıp yapıştırıyorlar. O halde güvenlik yöneticisi, bu tür anormallikleri tespit ettiğinde "tekerlekleri tekerleğe koyan" kişidir. Şerefe !!

      2.    msx dijo

        Rahatla dostum, buna değmez 😉

  2.   xykyz dijo

    Elbette, ancak daha sonra şifre kullanılan komutlara kaydedilir. Güvenlik nedeniyle bu yapılmamalıdır ...

    1.    Davidlg dijo

      Yazıyı okurken düşündüğüm buydu

    2.    KZKG ^ Gaara dijo

      Bunu .bashrc dosyamıza eklemek sshpass ile ilgili komutları kaydetmez:
      HISTIGNORE='sshpass *'

      Kısa bir süre bash geçmişine kaydedilmemeleri için komutların nasıl yok sayılacağına dair bir yazı yapacağım :)

      1.    melek bıçağı dijo

        Komutların kaydedilmemesinin bir başka yolu da komuttan önce her zaman bir boşluk bırakmaktır. ^ __ ^

  3.   Ignacio dijo

    Şifreyi girmek zorunda kalmadan SSH üzerinden bağlanmak için anahtarları kullanmanın daha güvenli olduğunu düşünüyorum.

    Öte yandan, parolanın kaydedildiği tam bir komut takma adı oluşturmak bir güvenlik sorunu olabilir.

  4.   Saito dijo

    Bana bilgisayar güvenliğinde bir kusur gibi görünüyorsa, ancak onların bash geçmişine kaydedilmediklerinden emin olacağız, bizim yaptığımız sorun (garrafal olacak bir takma ad dışında), elav'ın da dediği gibi mağaza bize bıçağı sat biz onu ne kullanacağını görecek olan biziz

  5.   Truko22 dijo

    İlginç, ancak başka bir girişte gösterdiğiniz genel ve özel anahtarı daha iyi kullanın.

  6.   msx dijo

    @KZKG
    Bence daha pratik - ve güvenli! - Otomatik kimlik doğrulama için bir anahtarlık (SSH aracısı) ile birlikte RSA / ECDSA anahtarlarını kullanın.
    Benim durumumda, Funtoo'dakiler tarafından geliştirilen, çok iyi çalışan, çok az kaynak kullanan ve çok güvenli bir SSH Keychain to Keychain kullanıyorum:
    http://www.funtoo.org/Keychain

    Örnek:

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

    Nasıl kullanılır:
    SSHKEYGEN {ecdsa, rsa}
    SSHCOPYID {ecdsa, rsa} kullanıcı @ {sunucu, 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'

    Nerede:
    -p #: bağlantı noktası
    usr1 @ sunucu1: kullanıcı @ AVAHI sunucusu
    usr1@server1.yerel: kullanıcı @ AVAHI sunucusu (sunucunun bazı sistemlerde nasıl yapılandırıldığına bağlı olarak .local sonekinin eklenmesi gerekir)
    usr1 @ [adres. ip] .101: sabit ip adresi.

    / etc / ssh / sshd_config: http://paste.chakra-project.org/4974/
    ~ / .ssh / config: http://paste.chakra-project.org/4975/
    İşletim Sistemi: Arch Linux / Chakra

    Umarım size hizmet eder, selamlar!

    1.    KZKG ^ Gaara dijo

      Aslında sunucularıma erişmek için SSHPass değil anahtarlar kullanıyorum ... Bu komut dosyasını yapmanın bir yolunu bulmam gerektiğinde SSHPass'ı keşfettim: http://paste.desdelinux.net/4810

      Ama ... evet, SSHPass'ı herkesle paylaşmak istedim, ama açıkçası buraya bir sözlük kullanarak OpenSSH-Server HAHAHA'yı ihlal etmeye izin veren bir komut dosyası koyamadım!

      1.    msx dijo

        "[…] Buraya bir sözlük kullanarak OpenSSH-Server HAHAHA'yı ihlal etmeye izin veren bir komut dosyası koyamadım!"
        Ama neden olmasın !!?
        Bilgisayar korsanlığı ve program kırma, iyi güvenlik uygulamalarını [0] öğrenmenin bir parçası değil mi?
        Lütfen dostum, devam et !!!

        [0] Kelimeleri kelimenin tam anlamıyla ifade ettiklerinin tam tersini ifade edecek şekilde kullanmak güzel değil mi? Dilbilimi kesmek !!! ; -D

      2.    Guzmanweb dijo

        Merhaba, bu hatayı alıyorum:

        Kök kullanıcı ile 192.168.20.11 numaralı bağlantı noktasında 22 şifrelerini test ediyor
        cat: con-letters.txt: Böyle bir dosya veya dizin yok

        harfleri.txt içeren dosyayı oluşturabilir miyim?

        Saygılarımızla

  7.   Eduardo dijo

    Bu yapılmaz, çünkü şifre bash_history'de düz metin olarak saklanır, bunun dışında başka bir yolla bulunabilir. Böylece ssh sizden parolanızı istemez, doğru yol "genel ve özel anahtarlar" dır.

  8.   oscar mezası dijo

    Sunucularıma uzaktan bağlanmak için RSA kullanıyorum, bu yüzden bu kadar güçlü bir güvenlik gerektirmeyen bir bilgisayara bağlanmanın iyi bir araç olduğunu düşünüyorum, ipucu için teşekkürler!

  9.   Nelson dijo

    chiuuu

  10.   Nebuchadnezzar dijo

    Ve şifremi herkesin kullanımına açık olması için neden daha iyi yayınlamayayım?

  11.   mario dijo

    Mükemmel, o kadar iyi !!!!!! ve İspanyolca.

  12.   Gonzalo jarjury dijo

    Mükemmel makale, her zaman olduğu gibi insanlar teşekkür etmek yerine şikayet eder, yöntem güvensiz olsa da, nerede ve nasıl kullandığınıza bağlıdır, çok teşekkür ederim 🙂