SSH для простых смертных: настройка и использование SSH в Linux

В сети много документов по настройке SSH для удалённого управления Linux и BSD-системах, но часто в них умалчиваются простые вещи. В этом посте я расскажу о простом использовании клиента SSH и настройке удалённого доступа.






Установка SSH в Linux на примере Debian
Итак, всё, что нам нужно для установки полного комплекта удалённого управления компьютером (SSH-клиент и SSH-сервер) давным-давно лежит в репозитории. Лёгким движением ставим пакет:
# apt-get install ssh
и ждём несколько мгновений, когда оно настроится. После этого мы получим возможность SSH доступа в систему и управления ей. Так как технология эта кросс-платформенная, то можно управлять по SSH Linux или FreeBSD можно и из Windows. Для этого есть
putty, SSH Windows клиент.

На стороне клиента
Теперь надо поправить настройки, которые лежат в каталоге /etc/ssh - конфиг для клиента называется ssh-config, конфиг для сервера, соответственно, sshd-config. На своей, клиентской, стороне, настраиваем возможность приёма X11Forward, ищем и меняем ключи на:
ForwardX11 yes
ForwardX11Trusted yes
Клиентская машина теперь может запускать удалённо графические приложения на сервере. Настройка SSH на стороне клиента закончена, теперь идём к админу далёкого сервера...
В принципе, можно на клиентской стороне ничего не менять, а логиниться на удалённую машину так:
$ ssh -X user@server1.mydomain.com
или
$ ssh -X user@192.168.x.x
если лезть в конфиги на своей стороне не хочется, но у меня это почему-то не работало...

На стороне сервера
Теперь нужно настроить SSH сервер: в конфигах машины-сервера, к которой будем подсоединяться (у вас ведь есть её рутовый пароль, так ведь?) в /etc/ssh/sshd-config ищем и меняем ключи на:
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes

Этим мы разрешаем серверу запускать удалённо графические приложения и отправлять их на клиентскую машину. Перестартуем сервис:
sudo /etc/init.d/ssh restart

Теперь мы сможем заходить на машину не только в консольном режиме, но и с запуском иксовых приложений.

Если хочется разрешить вход только с определённых машин, нужно подправить строки в конфиге /etc/ssh/sshd_config
AllowUsers hacker@*

AllowUsers *@192.168.1.*
Впрочем, это уже для более продвинутых товарищей.

SSH в действии
Всё готово, и теперь я приведу несколько команд SSH для примера. Открываем консольку и пишем в ней:
$ ssh имя_пользователя_удалённой_машины@ip_адрес_или_сетевое_имя_удалённой_машины
Например, в моём случае, когда я захожу удалённо на ноутбук, пишу ssh beast@192.168.1.5 - так как у меня не настроен сервер имён, пишу адреса. Опять-таки, доступ по SSH может быть не только из Linux или FreeBSD, но и из Windows - при помощи putty.

После этого нас могут спросить: данный айпишник ещё не опознан, как доверительный, стоит ему доверять? Пишем yes, стоит, конечно! :-) Далее вводим пароль пользователя удалённой машины, под которым мы заходим и, если он правильный, попадаем в консоль удалённой машины. В процессе набора пароля вы его не увидите - набирайте всё равно; даётся три попытки - потом соединение обрывается.

Итак, нас поприветствуют как-то вроде этого:

penta4@penta4rce:~$ ssh beast@192.168.1.5
Password:
Linux notebeast 2.6.15.7 #3 PREEMPT Sun Jul 2 12:51:07 MSD 2006 i686 GNU/Linux
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.

Last login: Tue Oct 10 19:23:57 2006 from 192.168.1.1
beast@notebeast:~$

Теперь, в окошке терминала, который на нашей машине, мы рулим компьютером, к которому мы подключились. Не перепутайте терминалы, а то вырубите не тот компьютер :-) Здесь всё просто и логично, но нам бы хотелось ещё и запускать графические приложения на удалённой системе. Легко!

Запуск графических приложений удалённо
Вводим, как обычно, логин и пароль удалённой машины. И вот перед нами та же самая консоль. Как вызвать графическое приложение? Просто наберите имя вызываемой программы и поставьте после имени знак амперсанд:
$ gimp &;
Это запустит на удалённой машине GiMP в фоне и вернёт вам консоль для дальнейших действий. Если вы не поставите амперсанд после имени приложения, то управление в консоль будет возвращено только после завершения приложения.

На приведённом скриншоте: слева gimp, запущенный на "родной" машине, справа - на удалённой. Кнопочки чуть разные из-за того, что на удалённой машине другие настройки gimp. В остальном - как родной.

Итак, у вас запустится графическое приложение точно так же, как если бы оно работало у вас. Есть одно но: это приложение будет работать на вашем экране, но с документами и настройками удалённой машины. Если файл для обработки находится в вашем домашнем каталоге, то его нужно будет передать на удалённую машину. Оно (и другие приложения, которые вы запустите) будет работать ровно до того момента, пока открыто ssh-соедиение. Туда же, в консольку ssh-соединения, будут выдаваться служебные сообщения запускаемых вами приложений.


Заключение
Ну вот, как выясняется, удалённое соединение и работа по SSH может быть полезна и простым смертным, а не только бородатым админам. Очень удобно, например, быстренько влезть на компьютер коллеги и помочь ему в чём-то (прочитать логи, например), тихо и незаметно поставить софт, или просто загрузить чем-то полезным простаивающую машину. В общем, много применений.

Так как пост делался с упором на простого пользователя, тут не рассматривается шифрованное копирование файлов и прочие тонкости. Они есть на русском в виде краткого описания настройки SSH, а ещё очень подробная статья с nixp. Хорошая справка (правда, на английском) здесь и тут. Думаю, что этого хватит.

60 комментариев: |высказаться!| RSS-лента дискуссии.|
serhiy cherevko комментирует...

Прикольно все расписано. Очень доходчиво. Я у себе делал почти все также.
В целях большей защиты, желательно поменять стандарный порт. Потом через аругмент -p его задавать. Если пользуетесь лишь одним сервером, то можно сделать alias, чтобы все время не набирать все эти ip имена и порты. Ну или пользоваться history | grep ssh ,а потом просто !№процесса.

virens комментирует...

2 serhiy cherevko
Прикольно все расписано. Очень доходчиво.
Спасибо :-) Просто я долго не мог понять, как запускать графические программы через ssh. Я думал, что это типа RemoteDesktop, а оно вон как :-)
В манах и других статьях про это не говорится вообще или мельком - ну все ж вроде знают...

В целях большей защиты, желательно поменять стандарный порт.
Да-да, это верно. Но простым смертным это уже слишком - или тогда это бородатые админы. :-)

Кстати, в вашем блоге почему-то пропала возможность оставлять комментарии гражданам с Blogger. Только с гугловского аккаунта. Это фича такая?

serhiy cherevko комментирует...

>Кстати, в вашем блоге почему-то пропала >возможность оставлять комментарии гражданам >с Blogger

Вы уже второй, кто об этом пишет. Я не знаю. Это не фича. По крайней мере не моя. Щас пойду в Blogger Help искать. А как на счет других блогов на Blogger Beta? Или это только у меня такое?

serhiy cherevko комментирует...

Нашел. Это глюк у Blogger beta.Оставил свои замечания. Думаю скоро исправят. Вообще он часто глючит. Несколько дней назад никто не мог загрузить картинки при публикации. Решили. И это решат

Roman Lagunov комментирует...

В Etch будет два пакета ssh - openssh-client, и openssh-server. Первый соответственно клиент, второй - сервер.

Мне сервер без надобности, так что я поставил себе openssh-client из backports.org - и телемаркет.

И для того, что бы не набирать все время ip очень и нестандартные порты, имена пользователей и т.д., редактируем ~/.ssh/config.

Так же, редактировать /etc/ssh/ssh_config для клиента нет необходимости, вообще-то. Опять же, редактируем ~/ssh/config.

За подробностями - man ssh_config.

Хочу только сказать, что у меня все настроено так для конкретной машины - порт, имя пользователя, файл Identity, и ip этой машины.

Еще есть такая интересная фича - ее стоило бы в статье рассмотреть - возможность логина без ввода пароля, с помощью ключей.

virens комментирует...

2 Anonymous
Такие вопросы задаются по личной почте, которая есть в профиле, а не в комментах на блог.
есть проблема вот в чем: когда пытаюсь запустить там иксы
Дальше можно не писать: я же написал в посте,что иксы там запускать НЕ НАДО, а НАДО запускать приложение иксовое. И всё будет ОК.

virens комментирует...

2 Roman Lagunov
В Etch будет два пакета ssh - openssh-client, и openssh-server. Первый соответственно клиент, второй - сервер.
Этч ещё не скоро :-) Когда выйдет - пост поправлю. Спасибо

Еще есть такая интересная фича - ее стоило бы в статье рассмотреть - возможность логина без ввода пароля, с помощью ключей.
Не в этм посте, а то для простых смертных это перебор :-) Но предложение учёл, буду писать (когда сам попробую :-))

jankkhvej комментирует...

Не -X, а -Y:
[...]
-Y Enables trusted X11 forwarding. Trusted X11 forwardings are not
subjected to the X11 SECURITY extension controls.
[...]

jankkhvej комментирует...

Логины с ключами - вообще бином ньютона ;)

на машине, откуда пойдём:
$ ssh-keygen -t dsa

- соглашаемся с местом хранения и вводим пустой пароль, просто жмём Enter.

Далее публикуем наш публичный ключ на машину, куда будем идти. Тут же, на нашей исходной машине:

cat ~/.ssh/id_dsa.pub | ssh user@remote.host.com "cat - >> .ssh/authorized_keys"

Последний раз ;) вводим пароль на удалённую машину.
Всё, публичный ключ нашего аккаунта на локальной машине добавлен в список авторизованных ключей аккаунта user на удалённом хосте.

Можно проверить: ssh user@remote.host.com не должен спрашивать пароля.

PS: два cat в одной команде наверняка можно заменить чем-то более правильным, чтобы не было Ещё Одного Бесполезного Использования Cat (тм).

serhiy cherevko комментирует...

Respect земляку jankkhvej. Все проделал как вы написали. Поскольку использую нестандартный порт, то просто дописал через -p. Все работает. Раньше как-то об этом не задумывался. Читал, но разбираться не хотел. Но как на счет безопасности? что безопасней? Для меня это не проблема, но в случае системных администраторов, это важно.

Анонимный комментирует...

Не в тему.
Я писал тебе писмо, насчет рассылки дисков. Рассылка закончена или просто письмо не прочитал?
krivakin@km.ru

jankkhvej комментирует...

С точки зрения прослушки по сети - безопасно что ключ, что пароль.
Если грамотно организована безопасность вообще - так, что никто не может украсть личный ключ из id_dsa - то ключи, очевидно, безопаснее паролей.
Одним из признаков хорошего сисадмина является использование везде ssh и ключей, с доступом к ssh только с определённых хостов и с запрещённой парольной аутентификацией.
Нестандартный порт - не помеха хакерам, а лишь неудобство пользования.

virens комментирует...

Да, намечается ещё один пост про SSH, на основе заметок, оставленных в комментариях. За что уважаемым комментаторам огромное спасибо.
Сейчас у меня мало времени, к концу года "подбиваю бабки", но пост будет.
Ещё раз огромное спасибо за ценные комментарии. Если чт ещё вспомните - милости просим.

Анонимный комментирует...

Сделал по инструкции (в качестве клиента использовал Mac OS X с установленным X11, в качестве сервера -- Debian Etch). Всё отлично работает. Спасибо!

Но вот такой вопрос возник. Если я хочу удалённо не просто приложения позапускать, а прямо в среде Gnome поработать -- как это сделать кошерно? Пока тупо запускал "nautilus&" и "gnome-panel&" -- и вроде всё работало, но не уверен, что это исчерпывающе и кошерно. Какие мануалы изучать?

Adin комментирует...

Используй Vncserver

rkuksa комментирует...

Если я хочу удалённо не просто приложения позапускать, а прямо в среде Gnome поработать
внц запускать не unixway
/usr/bin/gdmXnest

2 jankkhvej
почему id_dsa а не id_rsa? если я правильные книги грызу, то второе лучше.

cat ~/.ssh/id_dsa.pub | ssh user@remote.host.com "cat - >> .ssh/authorized_keys"
PS: два cat в одной команде наверняка можно заменить чем-то более правильным, чтобы не было Ещё Одного Бесполезного Использования Cat (тм).

да. :-)
scp ~/.ssh/id_rsa.pub user@remote.host.com:~/.ssh/authorized_keys2

2 - чтобы не использовать некогда дырявый первый протокол.

virens комментирует...

Очень приятно, что в комментариях идёт конструктивная дискуссия. Заодно смотрю, что публиковать в посте про "использование SSH для бородатых админов" :-)

Анонимный комментирует...

Хорошая дока, для полноты я бы добавил, как работать с ключами, в коментах достаточно хорошо раскрыли тему, осталось обобщить. ну и конечно как можно делать тоже самое в виндоусе. Недавно была необходимость запустить иксовые приложения в винде. Нашёл программу xwinlogon, работает через ssh. Ну и про putty и SSHSecureShellClient последний удобен для закачки и скачки файлов. Да и под линукс не плохо описать как работать в mc с файловой системой удалённой машины через ssh.

virens комментирует...

2 Anonymous
Хорошая дока, для полноты я бы добавил, как работать с ключами
Будет в другой статье. Не в этом году :-)

ну и конечно как можно делать тоже самое в виндоусе.
Блог о Линукс, а не о винде. Так что увы - мне даже негде это проверить.


Да и под линукс не плохо описать как работать в mc с файловой системой удалённой машины через ssh.
scp имеется в виду? Опять-таки, статья называется "для простых смертных", всего не упомянуть.

Комментаторам большое спасибо, по материалам обсуждения будет ещё пост.

Анонимный комментирует...

cat ~/.ssh/id_dsa.pub | ssh user@remote.host.com "cat - >> .ssh/authorized_keys"
PS: два cat в одной команде наверняка можно заменить чем-то более правильным, чтобы не было Ещё Одного Бесполезного Использования Cat (тм).
да. :-)
scp ~/.ssh/id_rsa.pub user@remote.host.com:~/.ssh/authorized_keys2


чем-то более правильным, имхо, является замена всего этого безобразия на
ssh-copy-id -i ~/.ssh/id_rsa.pub user@example.com

Или даже еще изящнее, если pubkey был предварительно сохранен в ~/.ssh/identity.pub, то
ssh-copy-id user@example.com

К тому же данный способ позволяет избежать такой проблемы как неправильно выставленные права на ~/.ssh/ и вложенные файлы, из-за чего ничего работать не будет. :)

Анонимный комментирует...

У меня нет проблем с SSH, но не работает scp: спрашивает пароль и заканчивается как будто нормально, но файл на новом месте отсутствует.
debian 3.1, proxy нет, а желание использовать scp есть. Спасибо.

Анонимный комментирует...

Автор, пиши исчо - зачетное крео

Максим комментирует...

ssh -XYC user@domain всегда так юзал...
большенство прог для форварда хватает -X но некоторым надо еще и -Y , -C для компрессии трафика.
будет-ли gnome форвардиться не знаю... icewm себя чувствует нормально... получаешь полный рабочий стол удаленно машины... безо всяких vnc

Djam комментирует...

Спасибо за доходчивое объяснение настройки подключения.
Вот только теперь интересно как организовать трансляцию KDE рабочего стола через SSH на удаленную машину, да так чтоб рабочий стол удаленной машины располагался на отдельном рабочем столе клиентской машины...

virens комментирует...

2 Максим комментирует...
ssh -XYC user@domain всегда так юзал...
Если настроить X11Forward, можно писать просто ssh user@host и всё.

будет-ли gnome форвардиться не знаю... icewm себя чувствует нормально...
По идее, это не должно зависеть от среды. У меня форвардятся любые приложения - и кдешные, и гномовские.

2 Djam комментирует...
Спасибо за доходчивое объяснение настройки подключения.
Пожалуйста. Сам немного помаялся, решил выложить.

Вот только теперь интересно как организовать трансляцию KDE рабочего стола через SSH на удаленную машину, да так чтоб рабочий стол удаленной машины располагался на отдельном рабочем столе клиентской машины
Вам точно в сторону VNC\Rdesktop. С помощью SSH вы сможете запускать приложения и форвардить их на другую машину, а если надо отображать весь рабочий стол целиком - это уже vnc.

Djam комментирует...

Вам точно в сторону VNC\Rdesktop. С помощью SSH вы сможете запускать приложения и форвардить их на другую машину, а если надо отображать весь рабочий стол целиком - это уже vnc

ну не совсем так. К примеру, у меня получилось полностью перенести стол KDE на клиентскую машину
командой kdesktop
но в таком случае переноситься именно весь стол, и если создать нового ползователя, то получается что два рабочих стола двух различных машин работают под двумя пользователями, что не очень-то удобно...
Где-то на форумах читал о том что X предсталяют собой терминальный сервер, тогда можно предположить, что трансляция на один из рабочих столов (пусть скажем в окне с размером во весь экран) вполне возможна...

Анонимный комментирует...

Подскажите пожалуйста!!!У меня одна машина с дебианом,а на второй ХР(виндец),как можно использовть удаленку?Заранее благодарен.

Анонимный комментирует...

В продолжение моего вопроса о переносе всего рабочего стола на другую машину по ssh

И так отвечаю на собственный вопрос. Но оговорюсь, получилось у меня это проделать только на Mandriva 2008 с KDE так как другого не имею...

И так для запуска удаленного рабочего стола по ssh необходимо выполнить несколько действий
1. начать новый сеанс пользователя
2. в новом сеансе подключиться к удаленной машине по ssh
ssh -X user@host
3. после этого в консоле выполнить:
kicker
kdesktop

после этого появиться панелька с меню удаленной машины и рабочий стол, НО останется и панель локальной машины...
для перехода от одного рабочего стола к другому использовать клавиши Ctrl+Alt+F7(Fx)

Анонимный комментирует...

Подскажите пожалуйста!!!У меня одна машина с дебианом,а на второй ХР(виндец),как можно использовть удаленку?Заранее благодарен.

тут чтобы не заморачиваться можно использовать rdesktop...
Хотя это не лучший вариант.

invisible комментирует...

Putty и нет проблем

Анонимный комментирует...

Автору спасибо, больше бы таких статей на тему Linux и консоль, в интернете все приходится искать, а как найдеш чтото и начинаеш задавать вопросы на форумах так сразу шлют в google практически всех, тогда зачем делать форумы если на них откровенно посылают, тем более чаще этим занимаются старперы которые настолько гордые в линуксе что боятся даже передать свои знания тем кто стремится это все впитывать, а в итоге все впитывают грубость и так же посылать всех в google..

virens комментирует...

2 invisible комментирует...
Putty и нет проблем
Есть проблемы: виндовый икс-сервер по умолчанию, насколько я знаю, X11Forward не умеет.

2 Анонимный комментирует...
Автору спасибо, больше бы таких статей на тему Linux и консоль
Пожалуйста, хотя меня за подобные статьи иногда в комментариях хают :-)

а как найдеш чтото и начинаеш задавать вопросы на форумах так сразу шлют в google практически всех
Знакомо. Кстати, что-то в гугле и в разных интернетах мусора стало больше - искать труднее. Личное наблюдение.

Анонимный комментирует...

В данный момент у нас все управляется через windows, щас шеф включил тормоза на покупку софта, естесна все расширяется и уже надоело сидеть на месте, появилось желание подвигатся и поэкспериментировать но так как никогда не имел дело с linux решил попробовать, долго лазил по инету в поисках на какой сборке начинать все мутить, ну пока остановился на ubuntu-server 8.10 уже раз 5-6 переставлял ковырялся и вроде начинаю въезжать, еще помню лет 10 назад торчал в консоли и она мне както более по душе с MC, нежели графическая оболочка

Сегодня настроил ssh, mc вроде все понял.

Но есть еще просьба к автору, продолжить подобные описания с подобными разъснениями по темам:
DHCP
VLAN
DNS
Хочется построить машину на linux для использования в подсчете трафика, NAT, DHCP, DNS, VLAN в общем управления сети.

vodoprom комментирует...

Огромное спасибо Автору за статью!!!

viktor6 комментирует...

у меня такая проблема
server:/home/viktor# kwrite &
[1] 5043
server:/home/viktor# PuTTY X11 proxy: wrong authentication protocol attemptedkwrite: cannot connect to X server localhost:10.0

Анонимный комментирует...

Автору большое спасибо, как раз то что искал.

MrFree комментирует...

Не помню откуда, в заметках нашел.

Запуск удаленной сессии через xinit

Недавно возникла необходимость поработать на работе на удаленном linux-компьютере. В тот момент на нем уже работали, так что вариант с VNC отпал сразу же. Также у меня была возможность работать через ssh, но запуск отдельных приложений через параметр -X меня не устроил. И тут я вспомнил, что где-то читал про возможность запуска удаленной сессии по ssh через xinit.

Для этого делаем следующее:

1. Создаем публичный ключ (сразу оговорюсь, для своего(!) удобства ключевую фразу - оставлял пустой)
$
ssh-keygen -t rsa

на все вопросы жмем Enter.
2. Публикуем этот ключ на удаленную машину, к которой будем подключаться
$
ssh-copy-id -i ~/.ssh/id_rsa.pub user@host

3. Переключаемся в консоль (не эмулятор) по Ctrl+Alt+F1
4. Используем xinit для запуска удаленной сессии GNOME
$
xinit /usr/bin/ssh -X user@host gnome-session -- :1

или
$
xinit /usr/bin/ssh -X user@host startkde -- :1

для KDE.

P.S. При данном методе мы запускаем удаленную сессию на удаленном компьютере, при этом сам рабочий стол отображается на нашем компьютере, но все процессы происходят на удаленном компьютере.
Поясню по user@host. user - имя пользователя на удаленной машине, host - IP удаленного компьютера.
И еще, чтобы вернуться к своей рабочей сессии, надо нажать на Ctrl+Alt+F7, чтобы обратно вернуться к удаленной сессии, надо нажать Ctrl+Alt+F9

aldo комментирует...

Привет. Я настроил себе ssh, правда, не пользуясь вашим мануалом. Все прекрасно, gnome-session работает отлично, если бы не одно но... (см. http://pics.livejournal.com/_call_of_ktulu_/pic/0000ew94 )
Может быть вы мне подскажете, что это могло бы быть?))))

Игорь комментирует...

Хороший пост для начинающего, что бы просто ознакомиться. Благодарю автора!

Анонимный комментирует...

помогите пожалуйста!
пишет
root@csring:~# gimp &
[1] 9310
root@csring:~# Не удалось открыть дисплей:


Что делать?

Анонимный комментирует...

а пробовал кто-нибудь подключиться к удаленому ubuntu через windows mobile? Я использовал прогу token2 shell. Putty не хочет запускаться. Подключиться получается, но на этом все фокусы заканчиваются. Может у токена сильные ограничения по функциям, подскажите плиз. Очень необходимо

Анонимный комментирует...

Прекрасный блог. Спасибо автору.
А может кто-нибудь подсказать, как запускать консольную ssh-сессию из-под юзера на клиенте (у меня получается запустить только из-под рута), хотя putty, запущеный юзером, работает отлично. Также не могу зайти на сервер по имени машины (ssh name), нужно только указывать IP-адрес (ssh IP). Система - две машины Debian squeeze и одна Ubuntu 10.10.

Анонимный комментирует...

Спасибо за статью!

Однако, графическое приложение запустить не удается (аналоогично посту несколько выше)

lmmold@lmmold-P4i65GV:~$ gimp &
[1] 2582
lmmold@lmmold-P4i65GV:~$ Не удалось открыть дисплей:

Анонимный комментирует...

Читаешь и что-то новое узнаешь
Побольше бы таких блогов
Прикольная статья

worldmind комментирует...

Что делать дальше с ssh, когда-то описывал тут
http://habrahabr.ru/blogs/personal/98771/

CBAPKA комментирует...

есть еще очень приятная штука sshfs называется :)

mul.sasha комментирует...

No DISPLAY: this may not be what you want - вот что мне выдало при попытке запустить gimp&

ВАЮ комментирует...

коллеги, а как оно по требовательности к каналу ssh против rdp?

В рдп у меня, видимо, вследствие разных аппаратных клавиатур, не все нажатия передаются адекватно - с Лин на Лин машину. С Лин на Вин машину все передается нормально.
Но доступ, например, запуск наутилуса, через ssh получается в разы медленней.

Анонимный комментирует...

Спасибо за статейку...
при настройке я еще в sshd_config
добавил
DenyUsers root
таким образом, чтоб удаленно проникнуть ко мне (без моего согласия) хацкеру надо будет для начала подобрать логин, так как все руты запрещены ))) это удваивает безопасность

gesigor комментирует...

Чтобы из windows подключиться к линукс машине и запускать приложения, нужна связка PUTTY + XMING. Первая позволяет делать связь по ssh c linux, вторая X-сервер для виндовс. Также можно использовать exceed, но он платный, по крайней мере на 2010 год.

HH комментирует...

ссылка "тут" в конце стать уже не актуальа

virens комментирует...

@HH комментирует...
ссылка "тут" в конце стать уже не актуальа
Это точно, спасибо, исправил. Всё течёт, всё меняется. Статье уже пять лет, так что не удивительно.

Да, автор подумывает запилить продолжение с настройками и более продвинутым использованием SSH. Пожелания приветствуются.

Анонимный комментирует...

К давнишнему комментарию про нестандартный порт и history ¦ grep ssh : есть такая замечательная штука в линупсовой консоли, как reverse-i search. Вводишь Ctrl-R и любую часть ранее выполненной команды (включая все параметры, трубопроводы и т.п.), и оно тебе любезно вводит в командную строку последнюю из подходящих под введённую строку команд. Остаётся только нажать enter.


Так, (C-r)ssh(Enter) выполнит последнюю из выполненных ранее подключений через ssh(или просто содержащих это слово где-то ещё), а (C-r)h user@exa с большой вероятностью выловит ssh user@example.com , если , конечно, вы раньше пытались так залогиниться и не выполняли ни команд, кончающихся на h c таким форматом адреса, ни ssh на другие адреса, начинающиеся на exa, что маловероятно.

Ну разве не прелесть?

Анонимный комментирует...

Статейка норм только вот готовность пятилетней давности сделать более расширенный пост на тему ССШ улыбнуло :) автор конечно молодец, не пропал и не забыл но что еще не написал ее это конечн.. :)

HH комментирует...

Из пожеланий - хотелось бы прочитать руководство по использованию rsa ключей. Однажды мне удалось настроить по ним доступ, но недавно начал с нуля и результата нет. После чтения различных руководств у меня сложилась следующая картина - на клиенте нужно сгенерить ключи:

ssh-keygen -t dsa -b 2048 -f /home/username/.ssh

потом private оставить на клиенте в папке /home/username/.ssh

(так ли это?)

а .pub поместить в файл /etc/home/username/.ssh/authorized_keys

на сервере. Причем, как я понял, нужно именно записать ключ в файл как-то так:

ssh-copy-id -i key_name.pub username@server_IP

или достаточно просто перекинуть на сервер и сделать

cat key_name.pub > /etc/home/username/.ssh/authorized_keys ?

На этом этапе могут быть отказы из-за прав доступа к файлу ключа, придется использовать chmod - как это лучше делать - 600 ?

В /etc/ssh/sshd_config на сервере есть строчка AuthorizedKeysFile %h/.ssh/authorized_keys , как я понимаю, она указывает ssh где смотреть публичные ключи клиентов. А где находится указатель на то, где хранится приватный ключ клиента, он должен где-то лежать по умолчанию (тогда где?) а если нет, то как указать местоположение?

У меня приватный ключ лежит в /home/andrey/.ssh у клиента . Публичный я записал на сервер в /home/andrey/.ssh/authorized_keys
по паролю логинится можно, по ключу - Permission denied (publickey)

Анонимный комментирует...

Очень просто, доходчиво и полезно. Спасибо автору!)

сисадмин комментирует...

А ежели кому надо запускать графические приложения (с GUI) на удалённых серверах, то рекомендую посмотреть в сторону xvfb (X Virtual Frame Buffer). Для дистрибутива CentOS пакет называется xorg-x11-server-Xvfb. Такое часто надо при тестировании различного софта.

Александр Якубенко комментирует...

Такой вопрос, есть некая железка, с доступом по ssh (там таки не совсем дебиан, но таки линукс) при запуске софтинки, я собственно, получаю консоль этой софтинки.
Есть ли возможность "свернуть", переключиться в консоль, сделать что то, и потом вернуться обратно? Ну или каким то иным способом запустить программу в рабочем состоянии, но с возможностью общения с ней?

уж извиняюсь, мыслю терминами Винды)

virens комментирует...

@Александр Якубенко комментирует...
Есть ли возможность "свернуть", переключиться в консоль, сделать что то, и потом вернуться обратно?
Не совсем врубился в то, что вы хотите. Подключившись по ssh, вы получаете консоль СИСТЕМЫ - и если вы запустили в удалённой консоли, скажем, файловый менеджер (MC\FAR), то вы заняли консоль системы вот этим запущенным приложением. Как его свернуть-то?!

Если приложение графическое (запускается графическая морда), то можно провернуть такой трюк: поставить амперсанд (&) в конце вызова приложения (скажем, gimp&), тогда и консоль будет доступна, и приложение.

Если приложение само по себе консольное, то оно-то эту консоль и заберёт - в этом случае амперсанд сделает хуже, т.к. вы это приложение просто не увидите (а ресурсы оно есть будет).

Вопрос в последнем случае: а что, сделать ещё одно подключение нельзя по религиозным причинам? То есть открыть два терминала и сделать два вызова к "некой железке по ссш"? Типа, одно окно терминала для нужной софтины, а другое - для всяких похабных действий? :-)

Александр Якубенко комментирует...

Да, последний случай. А не позволяет не религия но извращенный склад ума : это Embedded железка (прикрутил к ARM линукс, теперь надо сделать саму ось удобной для дальнейших извращений) , ssh через ком - порт. два раза повиснуть на одном порте я не могу. WiFi потом припаяю, но до этого еще дожить надо.

вроде начал копать тему, посмотрю вечером на screen и tmux, может это то, что мне нужно.

вообще, на стационарнике и нормальном доступе к консоли, как бы несколько их, через альт + F1 - F6, вот и интересно есть ли подобное через SSH

Отправить комментарий

Подписаться на RSS-ленту комментариев к этому посту.