Za tiste, ki uporabljamo SSH, to pomeni, da tisti, ki moramo v vsakdanjem življenju nenehno dostopati do oddaljenih računalnikov ali strežnikov, dosežemo točko, da se naveličamo vnašanja gesel, bi bilo:
- Vtipkajte terminal: ssh user @ server
- Počakajte nekaj sekund
- Strežnik, na katerega se želimo povezati, bo zahteval geslo
- Ko vstavimo geslo in pritisnemo [Enter], bomo dostopali do oddaljenega strežnika
In zdaj moje vprašanje, ali ni preprosteje samo tipkati?:
sshpass -p «PASSWORD» ssh root@servidor
Denimo, da je uporabnik koren, strežnik je: razv.desdelinux.net in geslo je ksunil ... potem bi bila vrstica:
sshpass -p xunil ssh root@dev.desdelinux.net
Da bi to dosegli, moramo preprosto namestiti paket sshpassv Debian / Ubuntu ali izvedeni finančni instrumenti bi bili z sudo apt-get namestite sshpass Medtem v ArchLinux ali izvedeni finančni instrumenti bi zadostovali sudo pacman -S sshpass
Če želimo določiti vrata (ker SSH ni na pristanišču 22) dodamo -p «PORT» ... torej ob predpostavki, da gre za vrata 9122:
sshpass -p xunil ssh root@dev.desdelinux.net -p 9122
Da vse to še bolj poenostavim lahko ustvarimo vzdevkeNa primer, pri izvajanju strežnika1 se izvede celotna vrstica, da se SSH poveže s strežnikom1 (sshpass -p geslo uporabnik @ server1) ali kaj podobnega, zato prihranimo tudi postavitev predolge črte 😉
Vseeno upam, da vam je bilo to koristno.
Mimogrede, drug način, kako se izogniti pisanju gesla, ko dostopamo prek SSH, je uporaba javni in zasebni ključi.
pozdrav
Opravičujem se, ampak to je strašna varnostna napaka !! Geslo je zataknjeno v skripte, navadne besedilne datoteke, zgodovino bash itd.
Za to openssh podpira overjanje z javnim ključem z uporabo RSA.
Zahvaljujoč tej vrsti prakse (ki jo izvajajo subjekti, ki se imenujejo "skrbniki") obstaja toliko računalniške negotovosti.
Lep pozdrav.
Pa poglejmo. Da, gre za varnostni problem, vendar to ne pomeni, da morajo "subjekti", ki so ali niso skrbniki, uporabljati to metodo. Metoda obstaja in je prikazana, če jo je treba uporabiti v okolju, kjer varnost ni težava. V trgovini, kjer ti prodajo nož, se odločiš, ali ga boš uporabil za rezanje zelenjave ali nekoga.
Razumem vaše stališče, vendar mi je žal, da v tako znanem blogu, ki promovirajo tovrstno prakso, skorajda gre za "opravičilo za grozno sistemsko upravo" hehe.
Objem!!
Še vedno ne razumem, v čem je težava 🙁
Ker smo v različnih pogledih govorili o tem, "kako doseči večjo varnost", lahko govorimo tudi o drugih "manj varnih" temah. Naš cilj je ponuditi informacije, na vas je, da veste, kaj z njimi storiti. Poleg tega avtor najbolj paranoične objave z varnostjo ne more biti, verjemite mi, da ko gre za sistemsko administracijo, tega ne počne.
S spoštovanjem 😉
Prvič, ko sem rekel 'izvajajo subjekti, ki se imenujejo "skrbniki", se nikoli nisem skliceval na avtorja članka, ne razumem, zakaj so tako dovzetni.
Z mojega vidika je težava v tem, da je to orodje v nasprotju z dobro varnostno prakso. Verjamem, da moramo iz skupnosti GNU / Linux ohraniti naš dragoceni operacijski sistem čim bolj varen. Mislim, ne bi si želel, da bi se GNU / Linux spremenil v Windows (varnostno pametno).
Na žalost obstaja veliko skrbnikov začetnikov, ki ne vedo, kako pravilno ravnati, in na koncu ta orodja uporabljajo v kritičnih sistemih.
Seveda imate pravico objaviti, kar želite, vendar ponavljam, žal mi je, da ta spletni dnevnik (eden najpomembnejših v španskem jeziku) daje mesto orodjem, ki ogrožajo varnost.
Lep pozdrav!
In dajte Juano z umivalnikom. Ravno zato, ker gre za referenčni blog, radi posredujemo vse vrste informacij. Razumem to:
Uporabnik prispe in vpraša: Kako se lahko povežem s strežnikom prek SSH, ne da bi zahteval geslo?
Na katerem koli forumu mu odgovorijo: Neeee, to je varnostni problem, tega nihče ne počne.
Čeprav uporabnik ve, mu ne pove, zakaj gre za varnostni problem. Slabo, zelo slabo, dobro je, da znaš stvari delati, zato v Desdelinux:
Uporabnik prispe in vpraša: Kako se lahko povežem s strežnikom prek SSH, ne da bi zahteval geslo?
Napišemo objavo in rečemo: To metodo lahko uporabite, deluje na ta način, vendar NI VARNO. Najvarneje je uporabiti to drugo.
Kateri se vam zdi boljši?
V redu, spoštujem vašo držo. Lep pozdrav!!
SSHPass dejansko ne ogroža varnosti, oseba, ki v vsakem primeru ogroža varnost, je uporabnik, ki jo zlorablja.
Tu je na primer odličen primer, da se SSHPass ne uporablja samo za to, kar komentiram v prispevku, temveč se lahko uporablja tudi za (na primer) razbijanje strežnika OpenSSH: http://paste.desdelinux.net/4810
Aplikacija ni nič drugega kot to, aplikacija, ki je dana, bo povzročila napake, ki ogrozijo varnost ali ne.
Glede živčnega ali dovzetnega sploh je bilo morda tako, kot ste rekli (ali pa zaradi branja težko pravilno razumem), vendar sem razložil, da je bil komentar namenjen meni, če ni, pa se opravičujem.
PS: Zagotovo se bo našlo več takšnih, ki bodo našli scenarij, ki sem ga postavil zanimiv in celo smešen LOL!
Ok, vesel sem, da smo se dogovorili. S spoštovanjem!!
Ali sem kdaj rekel, da je ta metoda varnejša od uporabe javnih in zasebnih ključev?
V drugem članku sem že delil, kako jih uporabiti [1], zdaj pa preprosto razložim drug način, kako doseči enako ali kaj podobnega.
Vsak uporablja tistega, ki mu najbolj ustreza, tistega, ki mu je ljubši. Tu sem preprosto razložil eno od načinov uporabe, ki jo je mogoče dati sshpass-u, drugo pa lahko prek skripta Bash razbije SSH z uporabo slovarja ... ampak daj no, to je samo še ena uporaba.
Ponavljam, svoje znanje delim samo z GNU / Linuxom. SSHPass morda ni idealna izbira za vsak primer, vendar ima uporabnost, ne oklevajte.
BTW, ki se nanaša na: (izvajajo subjekti, ki se imenujejo "skrbniki") ... heh ... heh ... heh ... raje ne komentiram, nikomur nimam ničesar dokazovati, da ne omenjam, moj prijatelj, nimaš najbolj oddaljene predstave o tem, kdo sem, še manj kot o tem, kar vem 😉
[1] https://blog.desdelinux.net/ssh-sin-password-solo-3-pasos/
Ne bodite živčni, zgodi se, da na svojem področju poznam ljudi, ki svoje delo temeljijo na Googlu in pri reševanju problemov kopirajo in prilepijo to vrsto stvari. Potem je skrbnik varnosti tisti, ki "postavi kolesa v kolo", ko zazna tovrstne nepravilnosti. S spoštovanjem!!
Sprosti se človek, ni vredno 😉
Seveda, potem pa je geslo registrirano v uporabljenih ukazih. Iz varnostnih razlogov tega ne bi smeli storiti ...
To sem mislil ob branju prispevka
Če to dodate v naš .bashrc, ukazi, povezani s spass, ne bodo shranjeni:
HISTIGNORE='sshpass *'Bom objavil prispevek, kako prezreti ukaze, da se v kratkem ne shranijo v zgodovino bash :)
Drug način, da se ukazi ne shranijo, je, da pred ukazom vedno postavite presledek. ^ __ ^
Mislim, da je varneje uporabljati tipke za povezavo prek SSH, ne da bi morali vnesti geslo.
Po drugi strani pa je ustvarjanje popolnega vzdevka ukaza, kjer je geslo shranjeno, lahko varnostna težava.
Če se mi zdi napaka v računalniški varnosti, vendar se bomo prepričali, da niso shranjeni v zgodovini bash, ni toliko težava, ki jo počnemo (razen vzdevka, ki bi bil garrafal), tudi kot elav pravi, da nam v trgovini prodajo nož, mi bomo tisti, ki bomo videli, kaj uporabiti
Zanimivo, vendar bolje uporabite javni in zasebni ključ, ki ste ga prikazali v drugem prispevku.
@KZKG
Mislim, da je bolj praktično - in varno! - za samodejno preverjanje pristnosti uporabite ključe RSA / ECDSA skupaj z obeskom za ključe (agent SSH).
V mojem primeru za ključek uporabljam ključ SSH, ki so ga razvili ljudje iz Funtoo-a, ki deluje zelo dobro, uporablja zelo malo virov in je zelo varen:
http://www.funtoo.org/Keychain
Primer:
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)"'
Kako uporabiti:
SSHKEYGEN {ecdsa, rsa}
SSHCOPYID {ecdsa, rsa} uporabnik @ {strežnik, 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'
Kje:
-p #: vrata
usr1 @ server1: uporabnik @ AVAHI strežnik
usr1@server1.local: uporabnik @ strežnik AVAHI (odvisno od tega, kako je strežnik konfiguriran v nekaterih sistemih, je treba dodati pripono .local)
usr1 @ [addr. ip] .101: fiksni ip naslov.
/ etc / ssh / sshd_config: http://paste.chakra-project.org/4974/
~ / .ssh / config: http://paste.chakra-project.org/4975/
OS: Arch Linux / Čakra
Upam, da vam služi, lep pozdrav!
Pravzaprav za dostop do strežnikov uporabljam ključe in ne SSHPass ... SSHPass sem odkril, ko sem potreboval način za izvajanje tega skripta: http://paste.desdelinux.net/4810
Ampak ... no, hotel sem deliti SSHPass z vsemi, toda očitno nisem mogel postaviti skripta, ki omogoča uporabo slovarja, da bi poskušal kršiti OpenSSH-Server HAHAHA!
«[…] Nisem mogel postaviti skripta, ki omogoča uporabo slovarja za poskus kršitve OpenSSH-strežnika HAHAHA!"
Zakaj pa ne !!?
Ali ni hekanje in razbijanje del učenja dobrih varnostnih praks [0]!?
Prosim človek, pojdi naprej !!!
[0] Ali ni lepo uporabljati besede, da pomenijo ravno nasprotno od tega, kar dobesedno pomenijo!? Hack jezikoslovje !!! ;-D
Živjo, dobil sem to napako:
S korenskim uporabnikom preizkuša gesla do 192.168.20.11 na vratih 22
cat: con-letters.txt: Takšne datoteke ali imenika ni
datoteko z букваmi.txt jih ustvarim?
pozdrav
To se ne naredi, ker je geslo shranjeno v bash_history kot navadno besedilo, razen tega, da bi ga lahko našli na drug način. Če vas ssh ne vpraša za geslo, je pravi način "javni in zasebni ključi".
Za oddaljeno povezavo s strežniki uporabljam RSA, čeprav menim, da je dobra povezava z nekaterim računalnikom, kjer ne potrebujemo tako močne varnosti, hvala za namig!
Chiuuuu
In zakaj bolje, da ne objavim svojega gesla, da bo na voljo vsem?
Odlično, dobro !!!!!! in v španščini.
Odličen članek, saj se ljudje vedno pritožujejo, namesto da bi se zahvalili, čeprav je metoda negotova, je odvisno od tega, kje in kako jo uporabljate, lepa hvala 🙂