Configuring Linux
System administration
Server Administration
Comments 135
+8
Спасибо. Очень полезная статья.

По содержанию похожа на эту, только текст другой.
+7
Это то самое типовое руководство, которое заканчивается на -L/-R/-D.
+1
Некоторые вещи реально очень круто, спасибо! Алиасы уже завтра начну применять.
+6
Когда я первый раз напечатал ssh ns1 вместо ssh -C family_n@lkt-srv-ns1.spb.companyname.ru, я понял, что ssh — это здорово.
+2
а почему не alias ns1='ssh -C family_n@lkt-srv-ns1.spb.companyname.ru' и потом просто ns1?

По крайней мере я у себя прописал так. Правда я не знал про алиасы на уровне ssh
+2
alias не нормальная команда. Автокомплиты не работают, редиректы «в» тоже не очень.
+2
scp не работает, rsync-over-ssh не работает, любой version control over ssh не работает и т.д.

Да, всё вышеперечисленное можно с помощью совершенно диких опций командной строки заставить жить без ~/.ssh/config, но зачем?
+1
точно так же прописал кучу хостов и вызываю их по имени алиаса
+2
А вы пробовали автокомплит в ssh? Набираю ssh re дополняет до redmine.host.com.
0
А если настроена авторизация по сертификату, то scp добивает табом путь на выбранном сервере =)
+1
Спасибо за контент. По поводу 443 немного оффтопика.
Имхо VPN лучше чем socks, и openvpn эту проблему решает отлично с port-share. Так что лично у меня для браузера 443 порт отдает страничку, а для openvpn туннель )
0
ssh может обеспечивать и туннель. Честно говоря, я сам не пробовал, но в теории должно быть. Почему ssh лучше, чем openvpn? Ну, в первую очередь потому, что dpi с большой вероятностью его таки пропустит (иначе все админы порвут все возможные места за поломанный ssh).

Главным же аргументом является минимализм. ssh есть и так и так, зачем лишний софт ставить? (И на сервер, и на рабочую станцию/ноутбук).
0
Ну, как минимум тем, что не нужно вносить изменения в конфигурацию всего софта. Например — прописывать/убирать прокси. По идее с т.з. dip разницы между любым-другим-TLS быть не должно, надо будет посмотреть кстати. Ну и порт шаринг из коробки. Вроде ssh не умеет
0
Порт шаринг — ssh не умеет. На 443 порту может жить апач и openvpn. С точки зрения DPI возможно разницы и нет, а может и есть.
+6
>> примерно 10% людей, которых просишь дать ssh-ключ постят id_rsa, причём из этих десяти
>> процентов 100% — мужского пола

Это можно и жирным выделить )) Спасибо, хорошо написано.
+3
Спасибо за статью, туннели очень внятно и приятно освещены, большой труд.

… вопрос про CompressionLevel. Он же, по man-у, только для ssh v1, который нынче принудительно включать надо.
Или есть подводные камни?
+3
Уели. Не прочитал внимательно. Да, убираю из примеров.
+1
Автор постарался, работу — плюсую, и добавляю в избранное. Побольше бы таких памяток!
+1
scp, кстати может в маски всякие и автодополнение пути на удаленной машине — очень классная фича.
+3
Автодополнение может не scp, признаемся, а автокомплит. Он, кстати, иногда умнее ssh и умудряется правильно прокидывать имя пользователя (отличное от текущего).
0
Более того, если доступ по ключу без пароля, то автокомплит может дополнять пути на удаленной машине (то есть в его скриптах написано попытаться пойти на ту машину по ssh). Правда, такое поведение не всегда приемлемо из-за дополнительных тормозов.
0
Скажите, а возможен проброс x-сервера используя Putty с linux на windows если порты на подключаемом компе закрыты. У меня только в локальной сети получалось
0
Возможен. Только вы, наверное, хотели сказать наоборот — с windows на linux. X-сервер там, где рисуется картинка.

Я как-то на windows прокидывал X'ы (установил для этого putty и x-server для windows) и показывал java-приложение с headless-сервера под linux'ом. Было мерзко, рабоче.
0
Подключаюсь с винды к линуксу. Иксы на винде, все входящие соединения блокируются. А в Putty нужно IP X сервера указать
+1
Спасибо! ssh пользуюсь очень часто, а знал всего пару фич.
Файлы передавал вообще через onedayfiles.com + wget.
+2
Всё знал, единственное, дополню, что ssh_config может понимать и такую конструкцию как Host * для всех остальных хостов, чтобы не вписывать все хосты, где имя пользователя отлично от локального.
0
На самом деле формат файла предусматривает указание глобальных переменных, равно как и относящися к конкретному хосту, примерно так
User root
PasswordAuthentication yes

Host home
        Hostname myhome.dyndns.org
        User vasya
        PasswordAuthentication no

0
Подсказка всем, кто будет редактировать ssh_config и использовать IdentityFile: ssh-agent может (и часто так и поступает) перегружать тот ключ, что указан в ssh_config. Чтобы этого не случилось, используйте IdentitiesOnly. Пару часов однажды убил пытаясь настроить подключение к двум хостам с разными ключами.
+1
Это, кстати, очень философский вопрос, о том, какие ключи где и как использовать.

Я придерживаюсь модели: один терминал — один ключ. На каждом ноуте/десктопе свой ключ. Один. Используется для работы с устройства.

Мотивация: спиз… т ноутбук (хоть у меня там ключ и под паролем), я буду точно знать, какой ключ отзывать (и он грепается по hostname в конце ключа).
+1
Прекрасно вас понимаю. Но тем не менее, случаи бывают разные. Вот к примеру, на команду разработчиков ключ к GitHub-у клиента был один. Получить доступ к аккаунту, чтобы добавить другой ключ не представлялось возможным. Пришлось этот ключ использовать и остальным членам команды.
+8
буэ

Я не фанат всякой секьюрной хрени, но употребление общих ключей напоминает использование общей зубной щётки.
0
ИМХО, в данном случае это было вполне оправдано и достаточно секьюрно. По окончании работ заказчик просто удалит ключ, выданный команде для работы и никто больше не получит туда доступа. В конце концов, открытые/закрытые ключи и прочие механизмы аутентификации — всего лишь способ установления доверия между участниками.
0
Правильным вариантом было бы просто добавить людей/ключи людей к репозиторию.
0
Конечно. Но именно это и не представлялось возможным, о чём я написал в комменте выше.
+1
Ещё есть MasterMode, который позволяет использовать уже установленное соединение для подключения ещё одной консоли, или использовании scp без авторизации. Активируется параметром -M. Или через config:
ControlPath /home/username/ssh-mastermode-%h-%p-%r
ControlMaster auto
0
Ну зачем вы прямо в ~ гадите?
~/tmp используйте или там ~/.ssh/socket какой-нить
а вот прямо ~/ это неприлично же, это все равно что справлять малую нужду на кухне.
-1
Вы бредите. Это всего-лишь временный файл, который автоматически удалится при закрытии подключения.
0
временным файлам место в ~/tmp(или в /tmp зависит от вашей паранойи)
0
Ну, технически — это не совсем временный файл. Это то, что в /var/run помещается для системных сервисов (ну, или /run в новых системах). По аналогии — per user такое, наверное, должно бы в ~/run создаваться.
0
да, это сокет, но в принципе же всякие php-fpm создают свои сокеты в /tmp, потому я и предложил ~/tmp.
вообще у меня в системе оно в ~/.ssh/socket/ создает свои файлы, там оно мне совсем не мешает :)
0
Спасибо, теперь буду просто давать ссылку на эту статью, вместо рассказов.
0
Аналогично. Только еще сопру в pdf, чтобы уж в совсем сложных случаях можно было пользоваться.
+1
Там с таром-то, не будет работать — хостнэйм пропущен.
UFO landed and left these words here
0
Которым а не который. Хотя да, не сразу ясно если не знаешь
UFO landed and left these words here
0
Жаргонизм. Заходят пользователем на сервер. Ну или заходят «из-под пользователя на сервер». Имеется в виду тот username, который передаётся.
0
угу. это фрагмент, который будет требовать разъяснений у многих

если бы не знал, о чем речь — я бы точно не понял
чем, тот который ходит отличается от того, которым ходят — и кто из них где

0
Да, это недостаточно ясно. Можно сказать так: локальный пользователь (локальной машины), удаленный пользователь (определенного сервера).
+1
А вот еще ценная фича: ssh может своими силами делать chroot для пользователя sftp. Или такой хак: в список ключей можно вписать команду которая будет выполнятся на сервере вместо шэла при использовании ключа
0
Кстати, вы умеете настраивать chroot на sftp для отдельных ssh-учёток?
0
как-то так:
Match group sftponly
         ChrootDirectory %h
         X11Forwarding no
         AllowTcpForwarding no
         ForceCommand internal-sftp
0
Проблема в том, что «как-то так» не работает, например, в свежем селектеловском дебиане — в зависимости от параметров либо вообще не логинит, либо не chroot'ит.
0
как-то так у меня работает. Есть подводные камни: весь путь должен владеться root-ом, шэл — баш либо подобный
+1
Простите, дебиан не «селектеловский», а просто дебиан. Мы не зря используем preseed для установки, а не клонируем готовое.
+2
Да, проверил, вы правы — дебиан Скалакси. Премного извиняюсь!
0
Если да — ключ сохраняется в файл ~/.ssh/known_hosts. Узнать, где какой ключ нельзя (ибо несекьюрно).
Разве?
Находим в ~/.ssh/known_hosts строчку с искомым доменным именем/ip-адресом, у удаляем её. Всё, наш клиент забыл «отпечаток» того сервера.
0
Как ответили ниже, это зависит от опции HashKnownHosts. У меня другой вопрос — почему без нее считается несекьюрно? Это же публичные ключи. Я ее обычно отключаю, поскольку с ней автокомплит по имени хоста перестает работать.
+2
scp годится только для очень больших файлов, если нужно передать много мелких файлов, то лучше делать как-то так:

cd /storage; tar cf — .snapshots | ssh root@192.168.0.1 tar xf — -C /storage

A sshfs можно подключать через fstab.
+1
бенч 2007 года? вылезайте из криокамеры — HPN уже запилили
0
А я просто в запускаемых приложениях (Linux Mint) дабавил команду монтирования (sshfs user@host:path path -o reconnect)
-1
С нормальным каналом нормальный способ, зато не надо в консолях выкручивать руки.
0
Пардон, промахнулся, это был ответ товарищу ksevelyar.
0
>с него в этой статье показываются картинки
Решили проверить, выдержите ли хабраэффект?
+4
чё? Какой хабраэффект? У меня раздача торрента даёт большую нагрузку, чем отдача статики. За 5 часов 75к хитов.

Вообще ни о чём.
0
Не увидел описания типовой конструкции «VPN для бедных» вида:

Host	shellbox.company
	HostKeyAlias shellbox
	Hostname public.address.for.shellbox.company.com
	LocalForward 22001 server1.company.private.zone:22
	LocalForward 22002 server2.company.private.zone:22
	LocalForward 22003 server3.company.private.zone:22
...

Host	r_server1.company.private.zone
	HostKeyAlias server1.company.private.zone
	Hostname 127.0.0.1
	Port 22001

Host	r_server2.company.private.zone
	HostKeyAlias server2.company.private.zone
	Hostname 127.0.0.1
	Port 22002
...



После чего типовая схема работы с помощью такого VPN:

1. «Активировать» VPN, выполнив один раз «ssh shellbox.company» и оставив висеть это соединение
2. После этого просто дописывать некий префикс — например, как в примере — «r_» к имени серверов, на которые хочешь ходить — т.е. ходить на «r_server1.company.private.zone», когда хочешь оказаться на «server1.company.private.zone».
0
Мне кажется, последний вариант с ProxyCommand именно эту задачу и решает, причём его не надо «активировать», т.е. проходит нормальный ssh сквозь другой сервер.
0
Вариант с ProxyCommand плох несколькими вещами:

1. Появился недавно _и_ должен поддерживаться ssh-сервером на той стороне. Даже далеко не все современные (ну, плюс-минус современные) большие Linux его поддерживают, что уж говорить об инсталляциях на всяких Cisco и/или минималистичных вариантах вроде OpenWRT

2. Плохо себя ведет с ControlMaster — в зависимости от конфигурации ControlPath мы получаем либо создание отдельного ssh-соединения до публичной машины на каждый конечный хост, либо вообще невозможность работать более, чем с одной разной приватной машиной одновременно (зато с одной можно, да, поднимать сессии пачками и все будет ок).

Кстати, да, про ControlMaster тоже ничего не увидел в статье, а это, субъективно, одна из самых важных, если не самая важная, настройка в ssh.
0
Почему ControlMaster так важен? Просто чтобы scp -r делать более свободно? Или для медленных каналов?
0
Экономит приличное количество нервов и резко повышает интерактивность использования ssh при некоторых сценариях. Даже на современных машинах (с двух сторон) и приличных каналах (полноценный гигабит, например) пользоваться, скажем, комплишеном для выбора файла на той стороне при написании строчки для scp или rsync-over-ssh, крайне некомфортно, когда на каждое нажатие Tab будет происходить реконнект с удаленной стороной, все эти хендшейки, логины, создания терминалов и т.д. Да и нажимать подтверждение того, что «да, использовать ключ» — тоже замучивает.
0
Простите, не понимаю о чём вы.

У меня до работы канал сильно меньший (от 50 до 100 мегабит), но я не вижу никаких запросов «да, использовать ключ» или тормозов в работе автокомплита.
0
Типовая ситуация: хочу скопировать какой-то файл из DocumentRoot http-сервера, помню, что он на машине server3, где-то то ли в /var/www, то ли в /var/www/html, то ли в /srv/www, то ли в /usr/local/htdocs. Лет N-дцать назад для этого нужно было открыть отдельную консоль, зайти оттуда через telnet/rsh/ssh на server3, полазать там по каталогам, пописать команды типа «ls /var/www», «ls /var/www/html» и т.д.

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

Вариант «без ControlMaster»:
1. Пишу «scp s», нажимаю Tab.
2. Мне предлагают на выбор «server1», «server2», «server3» и т.д. Выбираю «server3». Дописываю ":/", нажимаю Tab еще раз.
3. Комплишен устанавливает новое соединение с server3. Обмен ключами практически в любом случае занимает минимум полсекунды. Затем выскакивает окошко «Allow use of key такой-то?». Поднимаю глаза на окошко, жму дополнительный Enter. Аутентификация, повторный обмен ключами, логин, открытие сессии и выполнение ls или echo * на стороне сервера занимают еще с полсекунды. Получаю наконец-таки желанный список из "/bin", "/boot", "/cgroup", "/dev" и т.д.
4. Желаю посмотреть "/var", пишу букву «v» и чтобы не допечатывать «ar» по привычке нажимаю Tab. Внезапно, для выполнения этого комплишен еще раз переподключается к серверу и я трачу еще минимум секунду и еще одно лишнее чтение окошка и нажатие Enter.
5. Шаг 4 еще, собственно, ничего даже не начал прояснять по поводу содержимого "/var". Дописываю "/", уже ругаясь, нажимаю Tab еще раз. Еще секунда и еще один Enter, наконец-то выведено содержимое "/var".
6. Если забыться и не написать «www» полностью руками или не выбрать его из списка (если используется zsh), то следующее «w» + Tab приведет еще раз к секунде ожидания и окошку.

n. Наконец-таки сделав свою задачу, через некоторое время обнаружить, что логи server3 загажены тоннами бессмысленных сообщений о подключениях вида:

Aug  1 00:00:03 server3 sshd[443955]: Accepted publickey for greycat from 11.22.33.44 port 43506 ssh2
Aug  1 00:00:04 server3 sshd[443962]: Received disconnect from 11.22.33.44: 11: disconnected by user
Aug  1 00:00:06 server3 sshd[443967]: Accepted publickey for greycat from 11.22.33.44 port 43507 ssh2
Aug  1 00:00:06 server3 sshd[443971]: Received disconnect from 11.22.33.44: 11: disconnected by user


Вариант «с ControlMaster»:
1. То же
2. То же
3. Если соединения с server3 нет, то то же. Если есть, то мгновенно делается _один_ вызов на уже установленном соединении и тут же появляется на экране результат. Один пакет туда, один-два с результатом обратно.
4..(n-1). Даже если окошко выпрыгивало для первого коннекта, то для всех последующих уже точно все будет быстро, как на локальной ФС, и без всяких дозапросов.
n. В логах ровно одно подключение, как и должно быть с точки зрения аккаунтинга: человек подключился, человек поработал, человек отключился.

По-моему, вариант «с ControlMaster» имеет некоторые преимущества?
0
Ну, у меня один ssh-ключ, так что никаких запросов нет.

А автокомплит занимает неощутимое время.

Засирание логов — может быть, но кого это реально волнует?
0
Какая разница, сколько ключей? Как раз напротив — если уж ключ везде один, то добавлять ключ без ssh-add -c можно фактически в двух случаях:

1. Либо совсем не пользоваться agent forwarding (-A)
2. Либо когда есть тотальная уверенность в том, что люди, которые могут получить доступ к auth-сокету агента, не воспользуются ключом не по назначению

Во всех других случаях, когда есть хоть какая-то толика недоверия к людям, имеющим root на удаленном сервере, я не вижу причин не использовать ssh-add -c — это хотя и надоедливая защита, но действенная.

Про время — сейчас вот специально замерил, сколько у меня занимает установление соединения, хендшейки и выполнение 1 минимальной команды на соединении. Лучший получившийся результат (с одного относительно мощного сервера на другой аналогичный по линку в одном гигабитном свиче) — 680 мс при отключенном окошке подтверждения; типичный результат, к сожалению, в районе минуты — по нелокальным линкам, когда один из компьютеров медленнее другого и т.д. Для сравнение, худший результат с ControlMaster — 15 мс. В хороших случаях — 3-4 мс.

При более-менее быстрой скорости печати внезапная пауза в секунду (ну или даже в 0.7 с) при наборе, субъективно, малоприятна.

Засирание логов волнует, например, примерно каждую вторую IDS. Пару раз сталкивался с весьма жизненными ситуациями, когда человек вот так вот поконнектившись ~20 раз в минуту к серверу получал reject по IP-адресу, взведенный алерт в IDS типа «подозрительная активность на сервере N» и визит службы безопасности с разбирательством «у вас на компьютере вирус, который ломает сервер N».
0
Дайте угадаю — у вас rtt до сервера в районе нескольких секунд? А теперь представьте, что сервер в Америке? Опять же ждать пока разгонится slow-start на LFP при передаче файлов не очень хочется.

Засирание логов действительно не важно, пока «безопасники» не начинают жаловаться (у некоторых компаний так вообще IDS лицензируются по кол-ву обрабатываемых сообщений). Да и самому приятнее потом в чистых логах разбираться, если нужно будет.
+2
А еще:
либо ssh разрешён (читай — делай что хочешь)

На самом деле для «делай что хочешь» достаточно хоть какой-то связи с внешним миром. Вполне себе есть работающие прокси и туннели на базе ICMP, на базе DNS, на базе побитовой передачи результатов единичных легитимных DNS-запросов и т.д.
+1
ICMP можно смело фильтровать по rate, доводя до нефункциональности туннель (но сохраняя пинги), DNS-запросы аналогично.

Вся ж фича не в том, что это «в принципе возможно», а в том, что это комфортно и стандартно. И трафик никак не выделяется «нехарактерными» признаками.
0
Так и ssh, пардон, что на 22, что на 443 — где угодно можно зашейпить, как и в целом трафик по любым портам, по которым нет L7-проксирования. Ну и, по сути, да — шейпинг и делание «некомфортно» — это чуть ли не единственный действующий способ претворения таких ограничений в жизнь.
0
А бывают такие туннели, которые прикидываются валидным http? А то я был в таком месте, где был только выход по 80-му и, насколько я понял, DPI. Здесь могут быть сложности с тем, что в дополнение ко всему содержимое http может фильтроваться и модифицироваться, что для веб-серфинга несущественно, а для обернутого ssh фатально.
+2
Смотря что подразумевается под «валидным http» — метод CONNECT — тоже вполне себе http.

Туннелировать хитрым образом через особенный внешний туннельный http-сервер умеют многие, например вот есть проект с незамысловатым названием HTTPTunnel (серверная часть на php, клиентская — на perl или в виде бинарника под Windows) или там Proxytunnel — примерно то же самое, но еще банальнее, работает прямо со stdin/stdout, очень легко подключается к ssh через ProxyCommand.
+2
У fusermount есть полезная опция -z (lazy unmount), которая позволяет отключить даже занятый каталог.
0
На заметку, в ssh_config(~/.ssh/config) можно прописать ForwardAgent Yes, что бы не передавать ключ -A каждый раз. Можно и для Host *, можно для конкретных хостов.
0
годный ликбез
хочется подробностей про L2 over ssh и рецепт wake-up-on-lan через ssh
+1
скорость по SSH (scp) хорошо поднимается, если выбрать шифрование «по легче».
в своё время вперёд выставлял Blowfish и скорость существенно возрастала.

по умолчанию установлено что-то типа
Cipher 3des Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
0
Некоторые считают, что arcfour ( RC4 ) чуть быстрее blowfish, и главное, потребляет меньше ресурсов. А при передаче файлов криптостойкость обычно не так уж важна (за это arcfour и не в фаворе, хотя и незаслуженно).
0
Небольшое дополнение насчет fuse. Бывает, что сетевое соединение отвалилось, тогда при попытке доступа к точке монтирования консоль намертво зависает (так что ^Z не помогает). В этом случае при отмонтировании нужно проявить выдержку, чтобы не нажать таб, вызвав тем самым зависание консоли из-за того, что автокомплит пытается читать подмонтированную директорию.
0
Есть и вот такой головоломный приём использования pipe'а (любезно подсказали в комментариях в жж):

tar -c * | ssh user@server cd && tar -x


Блин. Классно. А то я делал как-то так:

tar -cvf — -C upload. | ssh user@server tar -xpvf — -C /var/spool/www/upload/
+7
Чтобы проверить, что в домашний каталог можно зайти. cd без параметров идёт в $home, если его нет или нет прав (или ошибка ФС и т.д.), то ломается, и не даёт выполнить tar в непонятное место.
+4

А разве тут не должно было быть


tar -c * | ssh user@server "cd && tar -x"

чтобы "&& tar -x" улетело в удалённый шелл, а не локальный?

0
у меня с ssh-copy-id возникла проблема — оно не умеет (или не умело?) работать с нестандартным портом. Решил проблему такой простой функцией: pastebin.com/Xb3A6Prq
+1
Всегда умело. Надо просто порт указывать правильно (кстати, спасибо, ща допишу в статью):

ssh-copy-id '-p443 user@example.com'

(внимание на кавычки).
0
Извините, что не в QA. Как можно выполнить несколько команд. Что-то типо этого:
ssh example.com -t "cd /www/example.com && git status -sb | head -1"
0
всё правильно написали, так что не понятно что вас смущает
ssh server «command1;command2;command3» или ssh server 'command1;command2;command3'
0
Статья хорошая, спасибо.
P.S.
Ещё большая драма, если у нас есть нестандартный порт, и, например, первая версия ssh (привет цискам).

Привет от цисок: ip ssh version 2
+1
Есть старые циски (которых еще полно, и которые справляются со своими обязанностями) и они не умеют v2.
0
спасибо за статью! не очень понял про проброс Х-сервера, ssh ric rdesktop -k en-us 192.168.1.1 -g 1900x1200, тут ric — это имя хоста в локальной сети?
0
а да, вчитался — в предыдущем пункте конфиг
Host ric
Hostname ооо-рога-и-копыта.рф
User Администратор
ForwardX11 yes
Compression yes
т.е по сути это ssh -XYC user@SERVER rdesktop -k en-us 192.168.1.1 -g 1900x1200
0
Замечу, что со временем постоянная смена ключей хостов из-за переналивки задалбывает, и спасает только
HashKnownHosts no StrictHostKeyChecking no
в конфиге. После этого выключаются дурацкие вопросы про добавление в known hosts (yes/no), равно как и параноя про man-in-the-middle.
0
Чудесно! Давно искал многое из этого в доступной форме с примерами. Спасибо большое!
+1
Еще одна полезная «фича» ssh — это Multiplexing. Если нужен шустрый автокомплит для scp, то можно запустить один терминал с ssh-сессией, а во втором работать с scp — он будет реюзать существующее подключение.
+1
Но копировать его на 8.8.8.8 мы не хотим, ибо там проходной двор и половина людей имеет sudo и может шариться по чужим каталогам.

Стало быть, многие имеют рутовый доступ к DNS серверу гугла? Странно, что никто не обратил внимание на сей факт в статье
0
Капитан очевидность докладывает, что это всего лишь пример.
0
Да это ясно. Я просто хотел сказать, что не очень удачно подобранный, так как пересекается с действительностью. Так, повод улыбнуться получившемуся в итоге выражению: «Но копировать его на 8.8.8.8 мы не хотим, ибо там проходной двор и половина людей имеет sudo и может шариться по чужим каталогам.»
Добавление смайликов к моему предыдущему сообщению подсказало бы, что оно носило саркастический характер. Но смайлы на хабре не котируются.Но копировать его на 8.8.8.8 мы не хотим, ибо там проходной двор и половина людей имеет sudo и может шариться по чужим каталогам.
0
Кстати с socks-proxy можно несколько упростить задачу, когда находишься «Фиг знает где». Дело в том, что приходится каждой программе прописывать настройки socks5, а это утомительно.

Есть такая софтина redsocks — умеет заворачивать весь исходящий траф на определенный порт, а на этом порту мы и запускаем ssh -fNL…
К софтине правда еще прилагаются несколько правил iptables.
+1
Хорошая статья, тут можно разве, что пропиарить книжку: SSH Mastery: OpenSSH, PuTTY, Tunnels and Keys

Ну и пара «интересностей» ещё:
1. ControlMaster — уже упомянули пару раз в комментах.
2. Извлечение public ключа из private: ssh-keygen -y -f id_rsa > id_rsa.pub
3. pam-ssh-agent-auth тоже интересная штука, особенно в комбинации с вышеописанным authorized_keys2
4. ssh-keyscan бывает полезна, впрочем любители chef/puppet/cfengine могут собирать ключики с машин более эффективным образом.
5. В последних версиях OpenSSH начали использовать Elliptic Curve DSA
0
либо ssh разрешён (читай — делай что хочешь), либо ssh запрещён

Либо ssh разрешён строго на определённые адреса, необходимые для работы.
0
Отличная статья, спасибо!

В качестве дополнения — есть ещё замечательня утилита corkscrew (доступна в т. ч. и на Cygwin), позволяющая для установления SSH-соединения использовать HTTP-прокси. Необходимо соблюдение двух условий:

  • прокси-сервер должен разрешать HTTPS CONNECT;
  • SSH-сервер должен «слушать» на порту 443 (в мире сурового ынтырпрайза HTTPS CONNECT на порт, отличный от 443, обычно запрещают).

Ремарка: PuTTY умеет использовать HTTP прокси своими силами, обходясь без corkscrew.

В результате фрагмент конфигурации будет выглядеть так:

Host home
        Hostname ...
        User ...
        Compression yes
        Port 443
        ProxyCommand corkscrew webcache.mycompany.com 8080 %h %p

После этого «хождение» на все остальные SSH-сервера достигается тривиальным образом:

Host ...
        Hostname ...
        User ...
        Compression yes
        Port ...
        ProxyCommand ssh -W %h:%p home
0
А если Windows и Putty, то надо доставить Xming (http://sourceforge.net/projects/xming/), затем в Putty >> Connection >> SSH >> X11 ставим галку Enable X11 forwarding, X display location “localhost:0.0”

Если Linux-сервер без GUI, то инициализируем глобальную переменную DISPLAY:
$ DISPLAY=localhost:10.0
$ export DISPLAY

И вот уже RDP наружу совсем не нужен.
Заголовок спойлера
Привет из 2017
Only those users with full accounts are able to leave comments., please.