Топ SSH клиенти за достъп

INeed$

INeed$

Registered
Днес имаше една мотивираща тема за мен ин дъ мидъл атаките, та реших аз да пусна за това кои са топ, поне според мен, SSH клиента, с които си достъпвате сървъра. Моите са само два от изброените - PuTTY и WinSCP.

SolarPuTTY – Безплатен SSH клиент, който ви помага да управлявате професионално отдалечени сесии. Можете да управлявате инструмента от една конзола с интерфейс с раздели.

PuTTY - Клиентска програма за SSH, която ви позволява да стартирате защитени отдалечени сесии през мрежата. Първоначално създаден за Windows, инструментът работи и на Linux и Mac машини.

WinSCP - Популярен, защитен софтуер за прехвърляне на файлове (SCP, SFTP и т.н.), но има и SSH клиент, който помага за отдалечени връзки през мрежата.

Bitvise SSH - клиентски инструмент, който работи само за Windows. Той поддържа всички версии до най-новата версия на Windows 11. Той е безплатен и поддържа неограничен брой потребителски връзки.

SecureCRT - Проектиран за използване с Windows, Linux и Mac, SecureCRT е търговски продукт, който осигурява емулация на терминали за компютри.

AbsoluteTelnet SSH - комутируема връзка, Telnet и много други в една сесия или многосесионен интерфейс с раздели.

DropBear - Приложение с отворен код и е сравнително по-малък SSH сървър и клиент.

Terminus - Платен клиентски инструмент за SSH, който работи на Windows, Linux и Mac. С Terminus можете да организирате хост групи.

KiTTY - Издание на PuTTY, което се счита за най-добрия SSH и Telnet клиент в света. Той е проектиран за Windows и има всички функции на оригиналното приложение PuTTY.

mRemoteNG - Издание на mRemote и е отворен код, мулти-протоколен мениджър на отдалечени връзки с раздели за операционна система Windows.

MobaXterm - Инструментариум за отдалечена компютърна система. Това е приложение за Windows с функции, използвани от уеб администратори, програмисти, ИТ администратори и всеки, който трябва да управлява отдалечени работни места.

SmarTTY Α безплатен SSH клиент с множество раздели, който ви позволява да копирате директории и файлове с SCP освен SSH връзки.

ZOC Terminal - Софтуер за емулация на терминал, както за Windows, така и за macOS. Приложението е с професионален подход и има много функции, които го правят надежден и сигурен инструмент.

Xshell - Един от най-мощните SSH клиенти. Той позволява на потребителите лесно да създават, стартират и редактират сесии с Мениджър на сесии и Свойства за наследяване на сесия.

ShellNGN - Уеб-базиран SSH клиент, който предлага управление на сървъра "всичко в едно". Приложението включва SFTP, RDP, VNC и много други.

Надявам се да съм дал обща картинка на нещата. Вие кои използвате?
 
Secure Shell (SSH) се е превърнал в един от най-важните протоколи за отдалечена връзка и се използва постоянно при деплойване или друг тип манипулации по сървъра. Намира приложение и при комуникацията на отделни системи по между си. Когато преглеждаме пазара на SSH клиенти, които позволяват запазване на сесии и пароли, трябва да се анализират тези инструменти въз основа на критерии като:
  • Сигурна ли е програмата като отдалечен терминал
  • Криптирана ли е системата при съхранението на пароли
  • Възможност системата да съхранява настройките за връзка, за да активира незабавен контакт с насочване
  • Възможността за поддържане на отворени няколко сесии
  • Функции за пауза и възобновяване на сесията
  • Безплатна пробна версия или безплатен инструмент
  • Безплатен инструмент, който си струва да използваме, или платен инструмент, който предлага стойност за парите ни
 
И аз ползвам самом PuTTY и WinSCP. Намирам ги за най-подходящи за мен и честно казано дори не съм се оглеждал за алтернативи, но може би заради това, че не ги ползвам с пълна сила всичките им функционалности, и не откривам дали някъде нещо липсва от това, което ми е нужно. Интересно и мерси много, че го сподели.
 
На работния компютър ползвам Putty понеже трябва да ползваме Windows. На Мака си използвам терминала и съм си конфигурирал SSH-а да знае къде да използва личния ми ключ и къде работния в случай, че работя дистанционно.

На локалната машина съм с Линукс, но там не съм конфигурирал нищо все още, но ще е както на Мака.
 
Като изключим терминалите, какво ползвате, наистина ми е любопитно. ;) Ще гледам тия дни и аз да пусна нещо за FTP клиентите. И май ще се препокриват с тези тук. Някои поне де. Примерно WinSCP си го ползвам и за FTP също. :)
 
Не ви ли трябва да боравите със сървъра, към който се връзвате? Или просто ви трябва клиент да си пренесете файловете?
 
Revelation каза:
Не ви ли трябва да боравите със сървъра, към който се връзвате? Или просто ви трябва клиент да си пренесете файловете?
Увеличете...
Какво значи да боравим със съръра, към който се връзваме? Аз ако трябва да правя нещо със сървъра през SSH, си ползвам cmd-то, ftp-to го ползвам предимно за прехвърляне на файлове. Ти какво точно правиш през клиентите, които ползваш?
 
Revelation каза:
Не ви ли трябва да боравите със сървъра, към който се връзвате? Или просто ви трябва клиент да си пренесете файловете?
Увеличете...
Да си качим кода най-вече. Аз поне само за това го ползвам, дори пипам някой неща в прод. с тези клиенти, като разбира си наглася кой реактиви едитор да се ползва - notepad ++, и задължително един бекъп преди това. Това е за дребни корекции. За сериозни девелопинг процеси, локал и после ъплоуд. ;)

А най-добре е да си вържеш средата с уеб сървъра, но на някоя дев среда там. Това е нормалното. ;)
 
Ами тука не се споменава само трансфер на файлове, но виждам, че повечето дават SFTP решения и просто ми стана интересно дали само за това го ползват.

Ами как какво правя. Боравя със сървърите. Налага се да проверявам логове най-често, за тази цел никога не бих ползвал WinSCP, за да разгледам някой лог, защото понякога е нужно да се tail-ва или пък да парсваш тези логове. Друг случай е проблем със сървъра - бавен е например, връзваш се за да видиш как се държи и каква може да е причината.
Въпреки че имаме мониторинг на всички сървъри, на мен ми е по-лесно да си пусна (h)top, разни логове и така.

За трансфер на файлове отново ще ползвам терминала с rsync или scp.
 
Не съм сигурен, че това с връзването към сървъра е добре, но към демо среда е супер. По две основни причини, имаш наистина реална симулация, и други - може да се разгледа от QA екипа, клиента, дизайнерите и другите страни, взимащи участие в проекта.
 
Ами тука говорим за различен workflow. Кода не го качвам по този начин. Имаме си deployer-и, които вържаш тази цел. Винаги трябва да имаш достъп до сървъра, обаче - и говоря за директен достъп, където директно работиш с command line-а.

В същия ред на мисли, никога няма да вържа IDE-то със сървъра и да правя промени директно по този начин. Имаш си локална среда, която е клонинг на production средата и си работиш на нея. Пипане по кода на production машина не е желателно, освен ако не искаш да оставиш сума недоволни потребители и клиенти, в случай че чупиш нещо без да искаш.

Моята гледна точка просто е от работа за компания, която си има собствени продукти и цялата архитектура е по-сложна от това да се качи уебсайта на споделен хостинг.
Понеже не знам кой с какво се занимава ми изникна този въпрос.

Предвид, че споделени хостинги последно време също предлагат ssh достъп, много лесно може да се направи automation.
 
Revelation каза:
Ами тука говорим за различен workflow. Кода не го качвам по този начин. Имаме си deployer-и, които вържаш тази цел. Винаги трябва да имаш достъп до сървъра, обаче - и говоря за директен достъп, където директно работиш с command line-а.

В същия ред на мисли, никога няма да вържа IDE-то със сървъра и да правя промени директно по този начин. Имаш си локална среда, която е клонинг на production средата и си работиш на нея. Пипане по кода на production машина не е желателно, освен ако не искаш да оставиш сума недоволни потребители и клиенти, в случай че чупиш нещо без да искаш.

Моята гледна точка просто е от работа за компания, която си има собствени продукти и цялата архитектура е по-сложна от това да се качи уебсайта на споделен хостинг.
Понеже не знам кой с какво се занимава ми изникна този въпрос.

Предвид, че споделени хостинги последно време също предлагат ssh достъп, много лесно може да се направи automation.
Увеличете...
Всъщност пипаш в демо среда, а прод. средата може да в отделена винаги. Както на машина, така и на същата, но в отделен акаунт или vps. Иначе процедурата е следната:

Имаш локално кода, който е огледален на демо средата - т.нар. sandbox. След като мине тестове, и QA-тата дадат зелена светлина, се качва в съотното репо в твоя бранш, който се мърджва с рилиз бранча. След това се взима всичко от тези демо среди и се налива в staging, преди окончателното да мине в продъкшън.

В много случаи се ползват клиенти, но в други дори няма смисъл. Зависи каква методика ще изберат от компанията и съответно екипа какво ще реши. Споделям го от гледната точка на девелопър.
 
Staging е по принцип, където QA тестват, защото staging средата трябва да е идентична с тази на production и тестването ще е по-точно. Всичко мине ли добре се пуска в production.
Sandbox (или development) environment е по принцип, където се тестват неща от програмистите.

В нашия случай ние нямаме този development environment (sandbox). Имаме директно staging (който при нас е кръстен UAT, което не е много вярно). Същевременно имаме допълнително тестови сървъри (в повечето случаи те играят роля на development environment), на които главно тестване промени в deployer-ите, ъпгрейдване на пакети и т.н. Въпроса е, че не е част от веригата при нас.
 
Да, така е. Прав си, общия staging се гледа преди продъкшъна, и е точно обединяващ от всички sandbox-ове на девовете. Нали, успоредно с това си вървят бранчовете в репоситоритата. ;) Всеки проект си има репо, следван от главни и под-нива бранчове, като на ниския е този на таска. Нагоре вървят спринта, после релииза и накрая се вливат в главния. Всички те се мърджват. Абе схемата е супер добра до момента, в който едно малко бъгче трябва да мине цялата тази процедура. За цяла функционалност разбираемо. ;)

В моя случай имаш локал проекта, който е сингваше с онлайн демото ми, което този т.нар. sandbox, и всяка промяна се отразяваше там при билдване и деплойване. Но всичко минаваш през код едитора, нямаше никакви клиенти. В сегашната ми работа, като работен процес, си ползвам локал проект, който си гледам при мен и след като всичко е Ок, качва се на демото, и ако всичко е отива на продъкшън. Също през код едитора се девелопва , гледа се локал и се качва с FTP - Filezila, и така. Това е.
 
Трябва да си влезнал или регистриран, за да отговориш тук.

Горе