Za one koji koristimo SSH, to jest, oni od nas koji u svakodnevnom životu moramo stalno pristupati udaljenim računarima ili serverima dolazimo do te mjere da se zasitimo kucanja lozinki, to bi bilo:
- Utipkajte terminal: ssh user @ server
- Pričekajte nekoliko sekundi
- Server na koji se želimo povezati tražit će lozinku
- Jednom kada stavimo lozinku i pritisnemo [Enter], pristupit ćemo udaljenom serveru
A sad moje pitanje, nije li jednostavnije samo otkucati?:
sshpass -p «PASSWORD» ssh root@servidor
Na primjer, pretpostavimo da je korisnik korijen, server je: Dev.desdelinux.net a lozinka je xunil ... tada bi linija bila:
sshpass -p xunil ssh root@dev.desdelinux.net
Da bismo to postigli, jednostavno moramo instalirati paket sshpassu Debian / Ubuntu ili derivati bi bili sa sudo apt-get instalirajte sshpass U međuvremenu u ArchLinux ili derivati bili dovoljni sudo pacman -S sshpass
Ako želimo odrediti port (jer SSH nije na portu 22) dodajemo -p «LUKA» ... to jest, pod pretpostavkom da je to port 9122:
sshpass -p xunil ssh root@dev.desdelinux.net -p 9122
Da sve ovo još više pojednostavim možemo stvoriti pseudonimeNa primjer, kada se izvršava server1, izvodi se cijela linija za SSH povezivanje sa serverom1 (sshpass -p lozinka korisnik @ server1) ili nešto slično, pa štedimo i predugo stavljanje reda 😉
U svakom slučaju, nadam se da vam je ovo bilo korisno.
Usput, drugi način da izbjegnemo pisanje lozinke kada pristupamo putem SSH-a je korištenje javni i privatni ključevi.
Saludos
Izvinjavam se, ali ovo je užasna sigurnosna aberacija !! Lozinka vam je zaglavljena u skriptama, običnim tekstualnim datotekama, bash povijesti itd.
Za to 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 računarska nesigurnost.
Pozdrav.
Da vidimo. Da, to je sigurnosni problem, ali ne znači da „subjekti“ koji su administratori ili ne 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 prodavnici 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, to je gotovo kao "izvinjenje za strašnu administraciju sistema", hehe.
Zagrljaj!!
Još uvijek ne razumijem u čemu je problem 🙁
Kako smo u raznim aspektima razgovarali i o tome "kako postići veću sigurnost", možemo razgovarati i o drugim "manje sigurnim" temama. Cilj nam je ponuditi informacije, na vama je da znate što s njima učiniti. Pored toga, autor najparanoičnijeg posta sa sigurnošću ne može biti, vjerujte mi, kada je u pitanju Administracija sistema, 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 tačke gledišta, problem je u tome što se ovaj alat kosi sa svakom dobrom sigurnosnom praksom. Vjerujem da iz GNU / Linux zajednice moramo održavati svoj dragocjeni operativni sistem š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 ove alate na kritičnim sistemima.
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.
Saludos !!
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 na server putem SSH-a bez traženja lozinke?
Odgovaraju mu na bilo kojem forumu: Neeee, to je sigurnosni problem, to niko ne radi.
Čak i znajući, korisnik mu ne kaže zašto je to sigurnosni problem. Loše, jako loše, dobro je što znaš da radiš stvari, zato unutra Desdelinux:
Korisnik dolazi i pita: Kako se mogu povezati na server 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. Srdačan pozdrav!!
SSHPass zapravo ne prijeti sigurnosti, osoba koja prijeti sigurnosti u svakom je slučaju korisnik koji ga zloupotrijebi.
Na primjer, ovdje je izvrstan primjer da se SSHPass ne koristi samo za ono što komentarišem u postu, on se može koristiti i za (na primjer) pucanje OpenSSH-servera: http://paste.desdelinux.net/4810
Aplikacija nije ništa više od toga, aplikacija koja je dana uzrokuje kvarove koji ugrožavaju sigurnost ili ne.
Što se tiče nervoze ili osjetljivosti, 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, izvinjavam se.
PS: Sigurno će biti nekolicina koji će pronaći scenarij za 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 ovaj metod sigurniji od korištenja javnih i privatnih ključeva?
U drugom sam članku već podijelio kako ih koristiti [1], sada jednostavno objašnjavam drugi način da se postigne isto ili nešto slično.
Svatko koristi onaj koji mu najviše odgovara, onaj koji više voli. 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 upotreba.
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: (implementiraju subjekti koji sebe nazivaju "administratorima") ... he ... he ... he ... ja radije ne komentiram, nemam šta nikome dokazivati, a da ne spominjem da vaš moj prijatelj nema udaljena ideja o tome ko sam, mnogo 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 polju znam ljude koji svoj rad temelje na Googleu i prilikom rješavanja problema kopiraju i lijepe takve stvari. Tada je administrator sigurnosti taj koji "stavlja točkove u točak" kada otkrije ove vrste anomalija. Živjeli !!
Opusti se čovječe, ne vrijedi 😉
Svakako, ali tada se lozinka registrira u korištenim naredbama. Iz sigurnosnih razloga to ne bi trebalo raditi ...
Na to sam razmišljao čitajući post
Dodavanjem ovog u naš .bashrc ne bi se sačuvale naredbe povezane sa sshpass-om:
HISTIGNORE='sshpass *'Radit ću post o tome kako ignorirati naredbe kako se uskoro ne bi sačuvale u bash povijesti :)
Drugi način da se naredbe ne sačuvaju je uvijek stavljanje razmaka ispred naredbe. ^ __ ^
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čunarskoj sigurnosti, ali pobrinut ćemo se da oni ne budu sačuvani 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 šta ć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 funkcionira 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 @ {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'
Gde:
-p #: port
usr1 @ server1: korisnik @ AVAHI server
usr1@server1.local: user @ AVAHI server (ovisno o tome kako je server konfiguriran u nekim sistemima 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 serverima ... SSHPass sam otkrio kada 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 nisam mogao ovdje staviti skriptu koja omogućava korištenje rječnika za pokušaj kršenja OpenSSH-servera HAHAHA!
"[...] Nisam mogao ovdje staviti skriptu koja omogućava korištenje rječnika za pokušaj kršenja OpenSSH-servera HAHAHA!"
Ali zašto ne !!?
Nije li hakiranje i hakiranje dio učenja dobrih sigurnosnih praksi [0]!?
Molim te, samo naprijed !!!
[0] Nije li lijepo koristiti riječi da znače upravo suprotno od onoga što doslovno znače!? Hakirajte lingvistiku !!! ;-D
Zdravo, primio sam ovu greš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 Letters.txt Stvaram ih?
pozdravi
To nije učinjeno, jer je lozinka pohranjena 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 serverima, čak i zato mislim da je dobro povezivanje s nekim računarom 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 na španskom.
Odličan članak, kao i uvijek ljudi se žale umjesto da zahvaljuju, iako je metoda nesigurna, ovisi o tome gdje i kako je koristite, hvala puno 🙂