Pro ty z nás, kteří používají SSH, to znamená, že ti z nás, kteří potřebují mít neustálý každodenní přístup ke vzdáleným počítačům nebo serverům, se dostáváme do bodu, kdy se dostáváme zadáváním hesel, bylo by to:
- Zadejte terminál: ssh uživatel @ server
- Počkejte několik sekund
- Server, ke kterému se chceme připojit, požádá o heslo
- Jakmile zadáme heslo a stiskneme [Enter], přejdeme na vzdálený server
A teď moje otázka, není snadnější jen psát?:
sshpass -p «PASSWORD» ssh root@servidor
Předpokládejme například, že uživatel je kořen, server je: Dev.desdelinux. net a heslo je xunil ... pak linka bude:
sshpass -p xunil ssh root@dev.desdelinux.net
Abychom toho dosáhli, musíme balíček jednoduše nainstalovat sshpassv Debian / Ubuntu nebo deriváty by byly s sudo apt-get nainstalovat sshpass Mezitím v archlinux nebo deriváty by stačily s sudo pacman -S sshpass
Pokud chceme určit port (protože SSH není na portu 22) přidali jsme -p «PORT» ... to znamená, za předpokladu, že je to port 9122:
sshpass -p xunil ssh root@dev.desdelinux.net -p 9122
To vše ještě více zjednodušit můžeme vytvořit aliasyNapříklad při provádění serveru1 se provede celý řádek pro připojení pomocí SSH k serveru1 (sshpass -p heslo uživatel @ server1) nebo něco podobného, takže uložíme také uvedení příliš dlouhé řady 😉
Doufám, že to pro vás bylo užitečné.
Mimochodem, dalším způsobem, jak se vyhnout nutnosti psát heslo, když přistupujeme pomocí SSH, je použití veřejné a soukromé klíče.
pozdravy
Omlouvám se, ale toto je hrozná bezpečnostní aberace !! Heslo máte zaseknuté ve skriptech, souborech prostého textu, historii bash atd.
Proto openssh podporuje ověřování veřejného klíče pomocí RSA.
Díky tomuto typu praxe (implementované subjekty, které si říkají „administrátoři“) existuje tolik počítačové nejistoty.
Zdravím.
Uvidíme. Ano, jedná se o bezpečnostní problém, ale to neznamená, že „subjekty“, které jsou správci nebo nemusí tuto metodu používat. Metoda existuje a zobrazuje se v případě, že je třeba ji použít v prostředí, kde není problém se zabezpečením. V obchodě, kde vám prodávají nůž, se rozhodnete, zda jej použijete k krájení zeleniny nebo někoho zabijete.
Chápu váš postoj, ale je mi líto, že v blogu s takovou pověstí propagují tento typ praktik, je to skoro jako „omluva za strašlivou správu systému“ hehe.
Objetí!!
Stále nechápu, v čem je problém 🙁
Jelikož jsme také hovořili o „jak získat větší bezpečnost“ v různých aspektech, můžeme hovořit také o dalších „méně bezpečných“ tématech. Naším cílem je nabídnout informace, je jen na vás, abyste věděli, co s nimi budete dělat. Navíc autorem nejvíce paranoidního příspěvku o bezpečnosti nemůže být, věřte mi, pokud jde o správu systému, tento druh věcí nedělá.
Zdravím 😉
Zaprvé, když jsem řekl „implementováno subjekty, které si říkají„ administrátoři ““, nikdy jsem neodkazoval na autora článku, nechápu, proč jsou tak náchylní.
Z mého pohledu je problém v tom, že tento nástroj je v rozporu se všemi dobrými bezpečnostními postupy. Věřím, že z komunity GNU / Linux musíme udržovat náš drahocenný operační systém co nejbezpečnější. Chtěl bych říct, že bych nechtěl, aby se GNU / Linux změnil na Windows (z hlediska bezpečnosti).
Bohužel existuje mnoho začínajících administrátorů, kteří neznají správný způsob, jak dělat věci, a nakonec tyto nástroje používají v kritických systémech.
Samozřejmě máte právo publikovat, co chcete, ale opakuji, mrzí mě, že tento blog (jeden z nejdůležitějších španělsky mluvících blogů) ustupuje nástrojům, které ohrožují bezpečnost.
Zdravím !!
A dejte Juanu s umyvadlem. Právě proto, že se jedná o referenční blog, rádi poskytujeme všechny druhy informací. Rozumím tomu:
Přijde uživatel a zeptá se: Jak se mohu připojit k serveru přes SSH bez požadavku na heslo?
Odpovídají mu na jakémkoli fóru: Noooo, to je bezpečnostní problém, nikdo to nedělá.
I když to uživatel ví, neřekne mu, proč se jedná o bezpečnostní problém. Špatné, velmi špatné, je dobře, že víš, jak věci dělat, proto in Desdelinux:
Přijde uživatel a zeptá se: Jak se mohu připojit k serveru přes SSH bez požadavku na heslo?
Napíšeme příspěvek a řekneme: Tuto metodu můžete použít, funguje to tak, ale NENÍ to bezpečné. Nejbezpečnější je použít tento druhý.
Který z nich je podle vás lepší?
Dobře, respektuji tvé držení těla. S pozdravem!!
SSHPass ve skutečnosti neohrožuje bezpečnost, osobou, která v každém případě ohrožuje bezpečnost, je uživatel, který ji zneužije.
Zde je například vynikající příklad, že SSHPass se nepoužívá pouze k tomu, co v příspěvku komentuji, ale lze jej použít například k prolomení OpenSSH-Serveru: http://paste.desdelinux.net/4810
Aplikace není nic víc než to, že aplikace, která je uvedena, způsobí selhání, které ohrožuje zabezpečení nebo ne.
Pokud jde o nervozitu nebo vnímavost, možná to bylo tak, jak jste to řekl (nebo že čtení ztěžuje správné pochopení), ale já jsem si vyložil, že ten komentář směřoval na mě, pokud tomu tak nebylo, omlouvám se.
PS: Určitě se najde několik, kteří najdou scénář, který jsem dal zajímavý a dokonce i vtipný LOL!
Dobře, jsem rád, že jsme se dohodli. Na zdraví!!
Řekl jsem někdy, že tato metoda je bezpečnější než používání veřejných a soukromých klíčů?
V jiném článku, který jsem již sdílel, jak je používat [1], nyní jednoduše vysvětlím jiný způsob, jak dosáhnout stejného nebo něčeho podobného.
Každý používá ten, který mu nejlépe vyhovuje, ten, který mu vyhovuje. Zde jsem jednoduše vysvětlil jedno z použití, které lze použít sshpass, jiné by mohlo být prostřednictvím skriptu Bash k prasknutí SSH pomocí slovníku ... ale no tak, toto je jen další použití.
Opakuji, sdílím pouze své znalosti týkající se GNU / Linuxu. SSHPass nemusí být ideální volbou pro každý případ, ale má užitečnost, neváhejte.
BTW, s odkazem na: (implementováno subjekty, které si říkají „administrátoři“) ... heh ... heh ... heh ... raději nebudu komentovat, nemám nikomu co dokazovat, nemluvě o tom, že můj přítel, nemáte nejvíce vzdálená představa o tom, kdo jsem, mnohem méně než to, co vím 😉
[1] https://blog.desdelinux.net/ssh-sin-password-solo-3-pasos/
Nebuďte nervózní, stává se, že v mém oboru znám lidi, kteří svou práci zakládají na Google a při řešení problémů tento typ věcí kopírují a vkládají. Správce zabezpečení je ten, kdo „zjistí, že se jedná o kolo“, když zjistí tyto typy anomálií. Na zdraví!!
Uvolněte se, člověče, nestojí to za to 😉
Jistě, ale pak je heslo zaregistrováno v použitých příkazech. Z bezpečnostních důvodů by se to nemělo dělat ...
Na to jsem myslel při čtení příspěvku
Přidání tohoto do našeho souboru .bashrc by neuložilo příkazy související s sshpass:
HISTIGNORE='sshpass *'Budu dělat příspěvek o tom, jak ignorovat příkazy, aby se brzy neuložily do historie bash :)
Dalším způsobem, jak nelze příkazy uložit, je vždy před příkaz umístit mezeru. ^ __ ^
Myslím, že je bezpečnější používat klíče pro připojení přes SSH, aniž byste museli zadávat heslo.
Na druhou stranu může být problémem se zabezpečením vytvoření úplného aliasu příkazu, kde je uloženo heslo.
Pokud se mi zdá chyba v počítačové bezpečnosti, ale my se ujistíme, že nejsou uloženy v historii bash, není ani tak problém, který děláme (až na alias, který by byl obrovský), také jak říká elav v obchod nám prodá nůž, my jsme ti, kdo uvidí, co použít
Zajímavé, ale raději použiji veřejný a soukromý klíč, který jste ukázali v jiné položce.
@KZKG
Myslím, že je to praktičtější - a bezpečnější! - pro automatické ověřování používejte klíče RSA / ECDSA společně s klíčenkou (agentem SSH).
V mém případě používám klíčenku SSH ke klíčence vyvinutou lidmi ve Funtoo, která funguje velmi dobře, používá velmi málo zdrojů a je velmi bezpečná:
http://www.funtoo.org/Keychain
příklad:
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)"'
Jak používat:
SSHKEYGEN {ecdsa, rsa}
SSHCOPYID {ecdsa, rsa} uživatel @ {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'
Kde:
-p #: port
usr1 @ server1: uživatel @ AVAHI server
usr1@server1.local: user @ AVAHI server (v závislosti na konfiguraci serveru v některých systémech je nutné přidat příponu .local)
usr1 @ [addr. ip] .101: pevná adresa IP.
/ etc / ssh / sshd_config: http://paste.chakra-project.org/4974/
~ / .ssh / config: http://paste.chakra-project.org/4975/
OS: Arch Linux/Chakra
Doufám, že vám to poslouží, pozdravy!
Ve skutečnosti používám klíče, ne SSHPass pro přístup k mým serverům ... SSHPass jsem objevil, když jsem potřeboval způsob, jak tento skript provést: http://paste.desdelinux.net/4810
Ale ... no, chtěl jsem sdílet SSHPass s každým, ale očividně jsem sem nemohl dát skript, který by umožňoval pomocí slovníku pokusit se porušit OpenSSH-Server HAHAHA!
«[...] Nemohl jsem sem dát skript, který by prostřednictvím slovníku umožňoval pokus o porušení HAHAHA serveru OpenSSH-Server!“
Ale proč ne!!?
Není hackování a prolomení součástí osvojování si dobrých bezpečnostních postupů [0]!?
Prosím člověče, pokračujte !!!
[0] Není krásné používat slova k označení přesného opaku toho, co doslova znamenají!? Hackněte lingvistiku !!! ;-D
Ahoj, dostávám tuto chybu:
Testuje hesla k 192.168.20.11 na portu 22 s uživatelem root
cat: con-letters.txt: Žádný takový soubor nebo adresář neexistuje
soubor s písmeny.txt vytvořím je?
jde o
To se nedělá, protože heslo je uloženo v bash_history jako prostý text, kromě toho jej lze zjistit jiným způsobem. Aby vás ssh nepožádalo o heslo, je správný způsob použití „veřejných a soukromých klíčů“.
Používám RSA pro vzdálené připojení k mým serverům, přesto si myslím, že připojení k nějakému počítači, kde nevyžadujeme tak silné zabezpečení, je dobrý nástroj, díky za tip!
Chiuuuu
A proč raději nezveřejnit své heslo, aby bylo kdokoli k dispozici?
Vynikající, že dobré !!!!!! a ve španělštině.
Výborný článek, jako vždy si lidé stěžují místo poděkování, i když je metoda nejistá, záleží na tom, kde a jak ji použijete, děkuji moc 🙂