Для тих з нас, хто використовує SSH, тобто ті з нас, хто потребує постійного доступу до віддалених комп’ютерів або серверів у своєму повсякденному житті, доходять до того, щоб втомитися від набору паролів, це буде:
- Введіть термінал: ssh user @ server
- Зачекайте кілька секунд
- Сервер, де ми хочемо підключитися, запитає пароль
- Як тільки ми введемо пароль і натисніть [Enter], тоді ми отримаємо доступ до віддаленого сервера
А тепер моє запитання, чи не простіше просто ввести?:
sshpass -p «PASSWORD» ssh root@servidor
Наприклад, припустимо, що користувач є корінь, сервер: dev.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
Щоб спростити все це ще більше ми можемо створювати псевдонімиНаприклад, при запуску сервера1 виконується весь рядок для підключення за допомогою SSH до сервера1 (sshpass -p пароль користувача @ server1) або щось подібне, тому ми також заощаджуємо надто довгий рядок 😉
У будь-якому випадку, я сподіваюся, це вам було корисно.
До речі, ще один спосіб уникнути необхідності писати пароль, коли ми отримуємо доступ через SSH, - це використання відкриті та приватні ключі.
привіт
Прошу вибачення, але це жахливі відхилення від безпеки !! Пароль застряг у сценаріях, текстових файлах, історії bash тощо.
Для цього openssh підтримує автентифікацію за допомогою відкритого ключа за допомогою RSA.
Завдяки такому виду практики (реалізується суб'єктами, які називають себе "адміністраторами"), стільки комп'ютерної небезпеки.
Привіт.
Подивимось. Так, це проблема безпеки, але це не означає, що "суб'єкти", які є або не є адміністраторами, повинні використовувати цей метод. Метод існує і відображається на випадок, якщо його потрібно використовувати в середовищі, де безпека не є проблемою. У магазині вони продають тобі ніж, ти вирішуєш, використовувати його для різання овочів чи вбивства когось.
Я розумію вашу позицію, але мені шкода, що в такому популярному блозі вони пропагують такий тип практики, це майже як "вибачення за жахливе адміністрування систем" хе-хе.
Обійми!!
Я досі не розумію, в чому проблема 🙁
Оскільки ми також говорили про те, "як отримати більшу безпеку" в різних аспектах, ми можемо говорити і про інші "менш безпечні" теми. Наша мета - запропонувати інформацію, від вас залежить, що з нею робити. Крім того, автор найбільш параноїчного допису з безпекою не може бути, повірте мені, коли справа стосується системного адміністрування, він не робить подібних дій.
Вітаю 😉
По-перше, коли я сказав "впроваджується суб'єктами, які називають себе" адміністраторами ", я жодного разу не звертався до автора статті, я не розумію, чому вони так сприйнятливі.
З моєї точки зору, проблема полягає в тому, що цей інструмент суперечить усім належним практикам безпеки. Я вважаю, що від спільноти GNU / Linux ми повинні захищати нашу дорогоцінну операційну систему якомога безпечніше. Я маю на увазі, що я не хотів би бачити, як GNU / Linux перетворюється на Windows (з точки зору безпеки).
На жаль, є багато початківців адміністраторів, які не знають, як правильно це робити, і в кінцевому підсумку використовують ці інструменти в критичних системах.
Звичайно, ви маєте право публікувати те, що хочете, але повторюю, мені шкода, що цей блог (один із найважливіших на іспанській мові) посідає місце інструментам, які загрожують безпеці.
Привіт!
І дай Хуані таз. Саме тому, що це довідковий блог, ми любимо надавати різну інформацію. Я розумію це:
Користувач приходить і запитує: Як я можу підключитися до сервера через SSH, не запитуючи пароль?
Вони відповідають йому на будь-якому форумі: Нееее, це проблема безпеки, ніхто цього не робить.
Навіть знаючи, користувач не говорить йому, чому це проблема безпеки. Погано, дуже погано, добре, що ти вмієш робити, тому в Desdelinux:
Користувач приходить і запитує: Як я можу підключитися до сервера через SSH, не запитуючи пароль?
Ми пишемо пост і кажемо: Ви можете використовувати цей метод, він працює таким чином, але НЕ БЕЗПЕЧНО. Найбезпечніше - використовувати цей інший.
Який з них ви вважаєте кращим?
Гаразд, я поважаю вашу поставу. З найкращими побажаннями!!
SSHPass насправді не загрожує безпеці, особа, яка в будь-якому випадку загрожує безпеці, є користувачем, який цим зловживає.
Наприклад, ось чудовий приклад того, що SSHPass використовується не тільки для того, що я коментую в дописі, він може бути використаний для (наприклад) злому OpenSSH-сервера: http://paste.desdelinux.net/4810
Додаток - це не що інше, як додаток, яке використовується саме те, що спричинить збої, що загрожують безпеці чи ні.
Щодо нервового чи сприйнятливого, то взагалі, можливо, це було так, як ти це сказав (або що читання ускладнює правильне розуміння), але я тлумачив, що коментар був спрямований до мене, якщо він був не таким, я перепрошую.
PS: Напевно знайдеться кілька, хто знайде сценарій, який я поставив цікавим і навіть кумедним LOL!
Добре, я радий, що ми досягли згоди. Вітаємо !!
Я коли-небудь говорив, що цей метод є більш безпечним, ніж використання відкритих та приватних ключів?
В іншій статті я вже розповідав, як ними користуватися [1], тепер я просто пояснюю інший спосіб досягнення того самого чи чогось подібного.
Кожен використовує той, який йому найбільше підходить, той, який їм більше подобається. Тут я просто пояснив одне із застосувань, яке може бути використано sshpass, інше - через скрипт Bash, щоб зламати SSH за допомогою словника ... але давай, це просто інше використання.
Повторюю, я ділюсь лише своїми знаннями, пов’язаними з GNU / Linux. SSHPass може не бути ідеальним вибором для будь-якого випадку, але він має корисність, не соромтеся.
До речі, маючи на увазі: (реалізується суб'єктами, які називають себе "адміністраторами") ... хе ... хе ... хе ... я волію не коментувати, мені нічого нікому доводити, не кажучи вже про те, що ваш друже мій, ти не маєш найвіддаленішого уявлення про те, ким я є, а тим більше від того, що я знаю😉
[1] https://blog.desdelinux.net/ssh-sin-password-solo-3-pasos/
Не нервуйте, буває, що в своїй галузі я знаю людей, які базують свою роботу на Google, і при вирішенні проблем вони копіюють та вставляють подібні речі. Тоді адміністратор безпеки - це той, хто «ставить колеса в колесо», коли виявляє такі аномалії. Вітаємо !!
Розслабтеся чоловіче, це не варто 😉
Звичайно, але тоді пароль реєструється в використовуваних командах. З міркувань безпеки цього робити не слід ...
Саме про це я думав, читаючи пост
Додавання цього до нашого .bashrc не збереже команд, пов’язаних з sshpass:
HISTIGNORE='sshpass *'Я зроблю допис про те, як ігнорувати команди, щоб вони незабаром не збереглися в історії bash :)
Інший спосіб, щоб команди не зберігалися, - це завжди ставити пробіл перед командою. ^ __ ^
Я думаю, що безпечніше використовувати ключі для підключення через SSH без необхідності вводити пароль.
З іншого боку, створення повного псевдоніма команди, де зберігається пароль, може бути проблемою безпеки.
Якщо мені здається вадою в комп'ютерній безпеці, але ми збираємось переконатися, що вони не зберігаються в історії bash - це не стільки проблема, яку ми робимо (за винятком псевдоніма, який був би величезним), так само, як каже 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 server (залежно від того, як сервер налаштований у деяких системах, потрібно додати суфікс .local)
usr1 @ [адд. 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-сервер HAHAHA!
«[…] Я не міг помістити сюди сценарій, який дозволяє через словник спробувати порушити OpenSSH-сервер HAHAHA!"
Але чому ні !!?
Хакерство та злом не є частиною вивчення належних практик безпеки [0]!?
Будь ласка, чоловіче, вперед !!!
[0] Хіба не красиво використовувати слова, щоб означати прямо протилежне тому, що вони буквально означають!? Рубайте лінгвістику !!! ;-D
Привіт, я отримую цю помилку:
Він тестує паролі до 192.168.20.11 на порту 22 з кореневим користувачем
cat: con-letters.txt: Немає такого файлу або каталогу
файл з літерами.txt я їх створюю?
що стосується
Це не зроблено, оскільки пароль зберігається в bash_history як звичайний текст, крім того, що його можна було дізнатись іншим способом. Щоб ssh не запитував у вас пароль, правильно використовувати "відкритий та приватний ключі".
Я використовую RSA для віддаленого підключення до своїх серверів, навіть тому я думаю, що для підключення до якогось комп’ютера, де нам не потрібна така сильна безпека, є хорошим інструментом, дякую за підказку!
Чіууу
І чому краще не опублікувати мій пароль, щоб він був доступний кожному?
Чудово, що добре !!!!!! та іспанською.
Відмінна стаття, як завжди люди скаржаться замість подяки, хоча метод небезпечний, це залежить від того, де і як ви його використовуєте, велике спасибі 🙂