Za one koji koristimo SSH, to jest, oni od nas koji svakodnevno trebamo stalno pristupati udaljenim računalima ili poslužiteljima, doći do točke da se zasitimo tipkanja lozinki, to bi bilo:
- Utipkajte terminal: ssh user @ server
- Pričekajte nekoliko sekundi
- Poslužitelj na koji se želimo povezati tražit će lozinku
- Jednom kada stavimo lozinku i pritisnemo [Enter], pristupit ćemo udaljenom poslužitelju
A sad moje pitanje, nije li jednostavnije samo tipkati?:
sshpass -p «PASSWORD» ssh root@servidor
Na primjer, pretpostavimo da je korisnik korijen, poslužitelj je: razv.desdelinux.net a lozinka je ksunil ... tada bi linija bila:
sshpass -p xunil ssh root@dev.desdelinux.net
Da bismo to postigli, jednostavno moramo instalirati paket sshpassNa Debian / Ubuntu ili bi derivati bili sa sudo apt-get instalirati sshpass U međuvremenu u ArchLinux ili bi derivati bili dovoljni za sudo pacman -S sshpass
Ako želimo odrediti port (budući da SSH nije na portu 22) mi dodajemo -p «LUKA» ... to jest, pod pretpostavkom da je to luka 9122:
sshpass -p xunil ssh root@dev.desdelinux.net -p 9122
Da sve to još više pojednostavim možemo stvoriti pseudonimeNa primjer, kada se izvršava server1, izvršava se cijela linija za SSH povezivanje s serverom1 (sshpass -p lozinka korisnik @ server1) ili nešto slično, pa štedimo i stavljanje crte predugo 😉
U svakom slučaju, nadam se da vam je ovo bilo korisno.
Usput, drugi način za izbjegavanje pisanja lozinke kada pristupamo putem SSH-a je pomoću javni i privatni ključevi.
pozdravi
Izvinjavam se, ali ovo je užasna sigurnosna aberacija !! Lozinka je zaglavljena u skriptama, običnim tekstualnim datotekama, povijesti basha itd.
Zbog toga openssh podržava provjeru autentičnosti javnog ključa pomoću RSA.
Zahvaljujući ovoj vrsti prakse (koju provode subjekti koji sebe nazivaju "administratorima") postoji toliko velika računalna nesigurnost.
Pozdrav.
Da vidimo. Da, to je sigurnosni problem, ali ne znači da "subjekti" koji jesu ili nisu administratori moraju koristiti ovu metodu. Metoda postoji i prikazuje se u slučaju da je treba koristiti u okruženju u kojem sigurnost nije problem. U trgovini vam prodaju nož, vi odlučujete hoćete li ga koristiti za rezanje povrća ili ubijanje nekoga.
Razumijem vaš stav, ali žao mi je što na takvom blogu koji promovira ovu vrstu prakse gotovo da je poput "isprike za užasnu administraciju sustava" hehe.
Zagrljaj!!
Još uvijek ne razumijem u čemu je problem 🙁
Kao što smo govorili o "kako postići veću sigurnost" u različitim aspektima, možemo govoriti i o drugim "manje sigurnim" temama. Cilj nam je ponuditi informacije, na vama je da znate što s njima učiniti. Uz to, autor najparanoičnijeg posta sa sigurnošću ne može biti, vjerujte mi, kada je u pitanju Administracija sustava, on ne radi takve stvari.
Pozdrav 😉
Prvo, kad sam rekao 'primjenjuju subjekti koji sebe nazivaju "administratorima", ni u jednom trenutku se nisam pozvao na autora članka, ne razumijem zašto su tako podložni.
S moje točke gledišta, problem je u tome što se ovaj alat protivi dobroj sigurnosnoj praksi. Vjerujem da iz zajednice GNU / Linux moramo čuvati svoj dragocjeni operativni sustav što sigurnijim. Mislim, ne bih želio vidjeti GNU / Linux pretvoren u Windows (sigurnosno).
Nažalost, postoji mnogo administratora početnika koji ne znaju ispravan način postupanja i na kraju koriste te alate na kritičnim sustavima.
Naravno da imate pravo objavljivati što god želite, ali ponavljam, žalosti me što ovaj blog (jedan od najvažnijih blogova koji govore španjolski) ustupa mjesto alatima koji prijete sigurnosti.
Pozdrav!
I dajte Juanu s lavorom. Upravo zato što je to referentni blog, volimo pružati sve vrste informacija. Razumijem ovo:
Korisnik dolazi i pita: Kako se mogu povezati s poslužiteljem putem SSH-a bez traženja lozinke?
Odgovaraju mu na bilo kojem forumu: Neeee, to je sigurnosni problem, to nitko ne radi.
Čak i znajući, korisnik mu ne govori zašto je to sigurnosni problem. Loše, jako loše, dobro je što znaš raditi stvari, zato in Desdelinux:
Korisnik dolazi i pita: Kako se mogu povezati s poslužiteljem putem SSH-a bez traženja lozinke?
Napišemo post i kažemo: Možete koristiti ovu metodu, ona djeluje na ovaj način, ali NIJE SIGURNA. Najsigurnije je koristiti ovaj drugi.
Koji je po vama bolji?
U redu, poštujem vaše držanje. Lijepi Pozdrav!!
SSHPass zapravo ne prijeti sigurnosti, osoba koja ugrožava sigurnost u svakom je slučaju korisnik koji ga zloupotrijebi.
Na primjer, ovdje je izvrstan primjer da se SSHPass ne koristi samo za ono što komentiram u postu, on se može koristiti i za (na primjer) probijanje OpenSSH-servera: http://paste.desdelinux.net/4810
Aplikacija nije ništa više od toga, aplikacija koja joj se daje je ono što će uzrokovati kvarove koji ugrožavaju sigurnost ili ne.
Što se tiče živčanog ili osjetljivog, uopće, možda je to bio način na koji ste to rekli (ili to čitanje otežava pravilno razumijevanje), ali protumačio sam da je komentar bio usmjeren na mene, ako nije, ispričavam se.
PS: Sigurno će biti nekoliko onih koji će pronaći scenarij koji sam stavio zanimljiv, pa čak i smiješan LOL!
Ok, drago mi je da smo postigli dogovor. Živjeli!!
Jesam li ikad rekao da je ova metoda sigurnija od upotrebe javnih i privatnih ključeva?
U drugom sam članku već podijelio kako ih koristiti [1], sada jednostavno objašnjavam drugi način postizanja istog ili nečeg sličnog.
Svatko koristi onu koja mu najviše odgovara, onu koja mu je draža. Ovdje sam jednostavno objasnio jednu od upotreba koje se mogu dati sshpass-u, druga bi mogla biti putem Bash skripte za probijanje SSH-a korištenjem rječnika ... ali hajde, ovo je samo još jedna uporaba.
Ponavljam, dijelim samo svoje znanje vezano za GNU / Linux. SSHPass možda nije idealan izbor za svaki slučaj, ali ima korisnost, ne ustručavajte se.
BTW, pozivajući se na: (provode subjekti koji sebe nazivaju "administratorima") ... heh ... heh ... heh ... Više volim ne komentirati, nemam što nikome dokazivati, a da ne spominjem da je vaš prijatelju moj, nemaš najudaljeniju ideju o tome tko sam, a još manje od onoga što znam 😉
[1] https://blog.desdelinux.net/ssh-sin-password-solo-3-pasos/
Ne budite nervozni, događa se da u svom području znam ljude koji svoj rad temelje na Googleu i prilikom rješavanja problema kopiraju i lijepe ovu vrstu stvari. Tada je administrator sigurnosti onaj koji "stavlja kotače u kotač" kada otkrije ove vrste anomalija. Pozdrav!!
Opusti se čovječe, ne vrijedi 😉
Naravno, ali tada se lozinka registrira u korištenim naredbama. Iz sigurnosnih razloga to se ne smije raditi ...
Na to sam razmišljao čitajući post
Dodavanjem ovog u naš .bashrc ne bi se spasile naredbe povezane sa sshpass-om:
HISTIGNORE='sshpass *'Radit ću post o tome kako ignorirati naredbe kako se ne bi ubrzo spremili u bash povijest :)
Drugi način da se naredbe ne spremaju jest da se ispred naredbe uvijek stavlja razmak. ^ __ ^
Mislim da je sigurnije koristiti tipke za povezivanje putem SSH-a bez unošenja lozinke.
S druge strane, stvaranje potpunog zamjenskog imena naredbe gdje se lozinka sprema može biti sigurnosni problem.
Ako mi se čini greška u računalnoj sigurnosti, ali pobrinut ćemo se da oni nisu spremljeni u bash povijesti, nije toliko problem koji mi radimo (osim aliasa koji bi bio ogroman), također kao što elav kaže u prodajte nam prodajte nož mi smo ti koji ćemo vidjeti što ćemo koristiti
Zanimljivo, ali bolje da koristim javni i privatni ključ koji ste pokazali u drugom zapisu.
@KZKG
Mislim da je praktičnije - i sigurnije! - koristite RSA / ECDSA ključeve zajedno s privjeskom (SSH agent) za automatsku provjeru autentičnosti.
U mom slučaju koristim SSH privjesak za privjesak, koji su razvili ljudi iz Funtoo-a, koji djeluje vrlo dobro, koristi vrlo malo resursa i vrlo je siguran:
http://www.funtoo.org/Keychain
primjer:
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 koristiti:
SSHKEYGEN {ecdsa, rsa}
SSHCOPYID {ecdsa, rsa} korisnik @ {poslužitelj, 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'
gdje je:
-p #: priključak
usr1 @ server1: korisnik @ AVAHI poslužitelj
usr1@server1.local: user @ AVAHI poslužitelj (ovisno o tome kako je poslužitelj konfiguriran u nekim sustavima potrebno je dodati sufiks .local)
usr1 @ [adr. ip] .101: fiksna ip adresa.
/ etc / ssh / sshd_config: http://paste.chakra-project.org/4974/
~ / .ssh / config: http://paste.chakra-project.org/4975/
OS: Arch Linux / Čakra
Nadam se da će vam poslužiti, pozdrav!
Zapravo koristim ključeve, a ne SSHPass za pristup svojim poslužiteljima ... SSHPass sam otkrio kad mi je trebao način za izvršavanje ove skripte: http://paste.desdelinux.net/4810
Ali ... dobro, želio sam podijeliti SSHPass sa svima, ali očito ovdje nisam mogao staviti skriptu koja omogućuje korištenje rječnika za pokušaj kršenja OpenSSH-poslužitelja HAHAHA!
"[...] Nisam mogao ovdje staviti skriptu koja omogućuje korištenje rječnika za pokušaj kršenja OpenSSH-poslužitelja HAHAHA!"
Ali zašto ne !!?
Nije li hakiranje i hakiranje dio učenja dobrih sigurnosnih praksi [0]!?
Molim te čovječe, samo naprijed !!!
[0] Nije li lijepo koristiti riječi da znače upravo suprotno od onoga što doslovno znače!? Hakirajte lingvistiku !!! ;-D
Pozdrav, shvaćam ovu pogrešku:
Testira lozinke za 192.168.20.11 na portu 22 s root korisnikom
cat: con-letters.txt: Nema takve datoteke ili direktorija
datoteku sa slovima.txt Stvaram li ih?
pozdravi
To nije učinjeno, jer se lozinka pohranjuje u bash_history kao običan tekst, osim što bi se mogla saznati na drugi način. Kako vas ssh ne bi pitao za lozinku, ispravan je način s "javnim i privatnim ključevima".
Koristim RSA za daljinsko povezivanje sa svojim poslužiteljima, čak i zato smatram da je dobar alat za spajanje na neko računalo na kojem nam nije potrebna tako jaka sigurnost, hvala na savjetu!
Chiuuuu
I zašto bolje ne objaviti moju lozinku tako da bude dostupna svima?
Izvrsno, dobro !!!!!! i to na španjolskom.
Izvrstan članak, kao i uvijek ljudi se žale umjesto da zahvaljuju, iako je metoda nesigurna, ovisi o tome gdje i kako je koristite, puno hvala 🙂