За тези от нас, които използват SSH, тоест тези от нас, които се нуждаят от постоянен достъп до отдалечени компютри или сървъри ежедневно, стигат до точката да се омръзнат от въвеждане на пароли, би било:
- Въведете терминал: ssh user @ server
- Изчакайте няколко секунди
- Сървърът, на който искаме да се свържем, ще поиска паролата
- След като поставим паролата и натиснем [Enter], ще имаме достъп до отдалечения сървър
И сега моят въпрос, не е ли по-просто просто да пишете?:
sshpass -p «PASSWORD» ssh root@servidor
Да предположим например, че потребителят е корен, сървърът е: разработчикdesdelinux. Net и паролата е ксунил ... тогава редът ще бъде:
sshpass -p xunil ssh root@dev.desdelinux.net
За да постигнем това, просто трябва да инсталираме пакета sshpassВ Debian / Ubuntu или производни биха били с sudo apt-get инсталирайте sshpass Междувременно в ArchLinux или производни биха били достатъчни sudo pacman -S sshpass
Ако искаме да посочим порта (тъй като SSH не е на порт 22) добавяме -p «ПОРТ» ... тоест, ако приемем, че е порт 9122:
sshpass -p xunil ssh root@dev.desdelinux.net -p 9122
За да опростим всичко това още повече можем да създаваме псевдонимиНапример, при изпълнение на server1, целият ред се изпълнява, за да се свърже чрез SSH към server1 (sshpass -p парола потребител @ server1) или нещо подобно, така че спестяваме и поставянето на линия твърде дълго 😉
Както и да е, надявам се това да ви е било полезно.
Между другото, друг начин да избегнем да се налага да пишем паролата, когато имаме достъп чрез SSH, е чрез използване публични и частни ключове.
поздрави
Моите извинения, но това е ужасно отклонение от сигурността !! Имате забита парола в скриптове, обикновени текстови файлове, история на bash и т.н.
За това openssh поддържа удостоверяване с публичен ключ чрез RSA.
Благодарение на този тип практика (прилагана от субекти, които се наричат „администратори“) има толкова голяма компютърна несигурност.
Поздрави.
Да видим. Да, това е проблем със сигурността, но не означава, че "субектите", които са или не са администратори, трябва да използват този метод. Методът съществува и се показва в случай, че трябва да се използва в среда, в която сигурността не е проблем. В магазина ви продават ножа, вие решавате дали да го използвате, за да режете зеленчуци или да убиете някого.
Разбирам вашата позиция, но съжалявам, че в такъв известен блог те популяризират този тип практика, това е почти като „извинение за ужасната системна администрация“ хехе.
Прегръдка!!
Все още не разбирам какъв е проблемът 🙁
Тъй като говорихме за „как да получим повече сигурност“ в различни аспекти, можем да говорим и за други „по-малко сигурни“ теми. Нашата цел е да предложим информацията, от вас зависи да знаете какво да правите с нея. Освен това авторът на най-параноичния пост със сигурност не може да бъде, повярвайте ми, когато става въпрос за системна администрация, той не прави такива неща.
Поздрави 😉
Първо, когато казах „изпълнява се от субекти, които се наричат„ администратори “, по всяко време не се обърнах към автора на статията, не разбирам защо са толкова податливи.
Проблемът от моя гледна точка е, че този инструмент противоречи на всички добри практики за сигурност. Вярвам, че от общността на GNU / Linux трябва да поддържаме нашата ценна операционна система възможно най-сигурна. Искам да кажа, че не бих искал да видя GNU / Linux превърнат в Windows (от гледна точка на сигурността).
За съжаление има много начинаещи администратори, които не знаят правилния начин да правят нещата и в крайна сметка използват тези инструменти на критични системи.
Разбира се, имате право да публикувате това, което искате, но повтарям, съжалявам, че този блог (един от най-важните на испански език) отстъпва място на инструменти, които застрашават сигурността.
Поздрави!
И дайте Хуана с леген. Тъй като това е справочен блог, ние обичаме да предоставяме всякаква информация. Разбирам това:
Потребител пристига и пита: Как мога да се свържа със сървър чрез SSH, без да искам парола?
Те му отговарят във всеки форум: Нееееее, това е проблем със сигурността, никой не го прави.
Дори да знае, потребителят не му казва защо това е проблем със сигурността. Лошо, много лошо, добре е, че знаете как се правят нещата, затова в Desdelinux:
Потребител пристига и пита: Как мога да се свържа със сървър чрез SSH, без да искам парола?
Пишем публикация и казваме: Можете да използвате този метод, той работи по този начин, но НЕ Е БЕЗОПАСЕН. Най-сигурното е да използвате този друг.
Коя според вас е по-добра?
Добре, уважавам позата ти. С Най-Добри Пожелания!!
SSHPass всъщност не застрашава сигурността, човекът, който заплашва сигурността във всеки случай, е потребителят, който я злоупотребява.
Например, тук е отличен пример, че SSHPass не се използва само за това, което коментирам в публикацията, той може да се използва за (например) разбиване на OpenSSH-Server: http://paste.desdelinux.net/4810
Приложението не е нищо повече от това, приложение, което се дава, е това, което ще доведе до неуспехи, които компрометират сигурността или не.
Що се отнася до нервни или податливи, изобщо може би това беше начинът, по който го казахте (или че четенето затруднява правилното разбиране), но аз тълкувах, че коментарът е насочен към мен, ако не е, извинявам се.
PS: Със сигурност ще има няколко, които ще намерят сценария, който сложих интересен и дори забавен LOL!
Добре, радвам се, че постигнахме споразумение. Наздраве !!
Някога казвал ли съм, че този метод е по-сигурен от използването на публични и частни ключове?
В друга статия вече споделих как да ги използвам [1], сега просто обяснявам друг начин за постигане на същото или нещо подобно.
Всеки използва този, който най-много му отива, този, който предпочита. Тук просто обясних една от употребите, които могат да бъдат дадени на sshpass, друга може да бъде чрез скрипт Bash за разбиване на SSH чрез използване на речник ... но хайде, това е просто друга употреба.
Повтарям, споделям само знанията си, свързани с GNU / Linux. SSHPass може да не е идеалният избор за всеки случай, но има полезност, не се колебайте.
BTW, позовавайки се на: (прилага се от субекти, които се наричат "администратори") ... хе ... хе ... хе ... предпочитам да не коментирам, няма какво да доказвам на никого, да не говорим, че вашият приятелю, нямаш най-отдалечената представа за това кой съм, още по-малко от това, което знам 😉
[1] https://blog.desdelinux.net/ssh-sin-password-solo-3-pasos/
Не се изнервяйте, случва се в моята област да познавам хора, които базират работата си на Google и при решаване на проблеми копират и поставят този тип неща. Тогава администраторът по сигурността е този, който „поставя колелата в колелото“, когато открие този тип аномалии. Наздраве !!
Спокойно човече, не си струва 😉
Разбира се, но след това паролата се регистрира в използваните команди. От съображения за сигурност това не трябва да се прави ...
Това си мислех, когато четох публикацията
Добавянето на това към нашия .bashrc няма да запази командите, свързани с sshpass:
HISTIGNORE='sshpass *'Ще направя публикация за това как да игнорирам команди, за да не се запазят скоро в историята на bash :)
Друг начин командите да не се запазват е винаги да поставя интервал пред командата. ^ __ ^
Мисля, че е по-безопасно да се използват ключове за свързване чрез SSH, без да се налага да въвеждате паролата.
От друга страна, създаването на пълен псевдоним на командата, където се запазва паролата, може да бъде проблем със сигурността.
Ако ми се струва недостатък в компютърната сигурност, но ние ще се уверим, че те не са запазени в историята на bash, не е толкова проблемът, който правим (с изключение на псевдоним, който би бил garrafal), също както elav казва в магазин ни продайте ножа ние сме тези, които ще видим какво да използваме
Интересно, но по-добре използвам публичния и частния ключ, който показахте в друг запис.
@KZKG
Мисля, че е по-практично - и безопасно! - използвайте RSA / ECDSA ключове заедно с ключодържател (SSH агент) за автоматично удостоверяване.
В моя случай използвам SSH ключодържател за ключодържател, разработен от хората от Funtoo, който работи много добре, използва много малко ресурси и е много сигурен:
http://www.funtoo.org/Keychain
Пример:
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)"'
Форма за използване:
SSHKEYGEN {ecdsa, rsa}
SSHCOPYID {ecdsa, rsa} потребител @ {сървър, 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'
когато:
-p #: порт
usr1 @ server1: потребител @ AVAHI сървър
usr1@server1.local: user @ AVAHI сървър (в зависимост от това как сървърът е конфигуриран в някои системи е необходимо да се добави суфиксът .local)
usr1 @ [addr. ip] .101: фиксиран ip адрес.
/ etc / ssh / sshd_config: http://paste.chakra-project.org/4974/
~ / .ssh / config: http://paste.chakra-project.org/4975/
ОС: Arch Linux / Chakra
Надявам се, че ви служи, поздрави!
Всъщност използвам ключове, а не SSHPass за достъп до сървърите си ... Открих SSHPass, когато имах нужда от начин да направя този скрипт: http://paste.desdelinux.net/4810
Но ... добре, исках да споделя SSHPass с всички, но очевидно не можах да сложа тук скрипт, който позволява използването на речник да се опита да наруши OpenSSH-Server HAHAHA!
«[...] Не можах да поставя тук скрипт, който позволява с помощта на речник да се опита да наруши OpenSSH-Server HAHAHA!"
Но защо не!!?
Дали хакерството и взломът не са част от изучаването на добри практики за сигурност [0]!?
Моля те човече, давай !!!
[0] Не е ли красиво да използваш думи, за да означаваш точно обратното на това, което те буквално означават!? Хакнете лингвистиката !!! ;-Д
Здравейте, получавам тази грешка:
Той тества пароли до 192.168.20.11 на порт 22 с root потребител
cat: con-letters.txt: Няма такъв файл или директория
файла с буквите.txt да ги създам?
отношение на
Това не се прави, тъй като паролата се съхранява в bash_history като обикновен текст, освен че може да бъде открита по друг начин. За да не поиска ssh от вас парола, правилният начин е с "публични и частни ключове".
Използвам RSA за отдалечено свързване със сървърите си, въпреки че мисля, че свързването с някакъв компютър, където не се изисква такава силна сигурност, е добър инструмент, благодаря за съвета!
Чиууу
И защо по-добре да не публикувам паролата си, така че да е достъпна за всеки?
Отлично, че добре !!!!!! и на испански.
Отлична статия, както винаги хората се оплакват, вместо да благодарят, въпреки че методът е несигурен, зависи от това къде и как го използвате, благодаря много 🙂