Памятка пользователям ssh

[utf]

Спасибо. Очень полезная статья.

По содержанию похожа на эту, только текст другой.

[amarao]

Это то самое типовое руководство, которое заканчивается на -L/-R/-D.

[AlexWinner]

Некоторые вещи реально очень круто, спасибо! Алиасы уже завтра начну применять.

[amarao]

Когда я первый раз напечатал ssh ns1 вместо ssh -C [e-mail], я понял, что ssh — это здорово.

[Voenniy]

а почему не alias ns1='ssh -C [e-mail]' и потом просто ns1?

По крайней мере я у себя прописал так. Правда я не знал про алиасы на уровне ssh

[amarao]

alias не нормальная команда. Автокомплиты не работают, редиректы «в» тоже не очень.

[GreyCat]

scp не работает, rsync-over-ssh не работает, любой version control over ssh не работает и т.д.

Да, всё вышеперечисленное можно с помощью совершенно диких опций командной строки заставить жить без ~/.ssh/config, но зачем?

[netmaniac]

точно так же прописал кучу хостов и вызываю их по имени алиаса

[Zelgadis]

А вы пробовали автокомплит в ssh? Набираю ssh re дополняет до redmine.host.com.

[elve]

А если настроена авторизация по сертификату, то scp добивает табом путь на выбранном сервере =)

[Vasily_Pupkin]

Спасибо за контент. По поводу 443 немного оффтопика.
Имхо VPN лучше чем socks, и openvpn эту проблему решает отлично с port-share. Так что лично у меня для браузера 443 порт отдает страничку, а для openvpn туннель )

[amarao]

ssh может обеспечивать и туннель. Честно говоря, я сам не пробовал, но в теории должно быть. Почему ssh лучше, чем openvpn? Ну, в первую очередь потому, что dpi с большой вероятностью его таки пропустит (иначе все админы порвут все возможные места за поломанный ssh).

Главным же аргументом является минимализм. ssh есть и так и так, зачем лишний софт ставить? (И на сервер, и на рабочую станцию/ноутбук).

[Vasily_Pupkin]

Ну, как минимум тем, что не нужно вносить изменения в конфигурацию всего софта. Например — прописывать/убирать прокси. По идее с т.з. dip разницы между любым-другим-TLS быть не должно, надо будет посмотреть кстати. Ну и порт шаринг из коробки. Вроде ssh не умеет

[deniszh]

Порт шаринг — ssh не умеет. На 443 порту может жить апач и openvpn. С точки зрения DPI возможно разницы и нет, а может и есть.

[hazg]

>> примерно 10% людей, которых просишь дать ssh-ключ постят id_rsa, причём из этих десяти
>> процентов 100% — мужского пола

Это можно и жирным выделить )) Спасибо, хорошо написано.

[neperap]

Спасибо за статью, туннели очень внятно и приятно освещены, большой труд.

… вопрос про CompressionLevel. Он же, по man-у, только для ssh v1, который нынче принудительно включать надо.
Или есть подводные камни?

[amarao]

Уели. Не прочитал внимательно. Да, убираю из примеров.

[Sysman]

Автор постарался, работу — плюсую, и добавляю в избранное. Побольше бы таких памяток!

[Kastrulya]

scp, кстати может в маски всякие и автодополнение пути на удаленной машине — очень классная фича.

[amarao]

Автодополнение может не scp, признаемся, а автокомплит. Он, кстати, иногда умнее ssh и умудряется правильно прокидывать имя пользователя (отличное от текущего).

[janatem]

Более того, если доступ по ключу без пароля, то автокомплит может дополнять пути на удаленной машине (то есть в его скриптах написано попытаться пойти на ту машину по ssh). Правда, такое поведение не всегда приемлемо из-за дополнительных тормозов.

[Kastrulya]

Вот ээто я и имел в виду.

[atomAltera]

Спасибо большое. Я тут как раз настраивал удалённые фс

[atomAltera]

Скажите, а возможен проброс x-сервера используя Putty с linux на windows если порты на подключаемом компе закрыты. У меня только в локальной сети получалось

[amarao]

Возможен. Только вы, наверное, хотели сказать наоборот — с windows на linux. X-сервер там, где рисуется картинка.

Я как-то на windows прокидывал X'ы (установил для этого putty и x-server для windows) и показывал java-приложение с headless-сервера под linux'ом. Было мерзко, рабоче.

[atomAltera]

Подключаюсь с винды к линуксу. Иксы на винде, все входящие соединения блокируются. А в Putty нужно IP X сервера указать

[amarao]

127.0.0.1

[atomAltera]

Спасибо, попробую

[ShadowPrince]

Спасибо! ssh пользуюсь очень часто, а знал всего пару фич.
Файлы передавал вообще через onedayfiles.com + wget.

[UUSER]

Всё знал, единственное, дополню, что ssh_config может понимать и такую конструкцию как Host * для всех остальных хостов, чтобы не вписывать все хосты, где имя пользователя отлично от локального.

[amarao]

Оки, спасибо, сейчас допишу.

[BasilioCat]

На самом деле формат файла предусматривает указание глобальных переменных, равно как и относящися к конкретному хосту, примерно так

User root
PasswordAuthentication yes

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

[Shark]

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

[amarao]

Это, кстати, очень философский вопрос, о том, какие ключи где и как использовать.

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

Мотивация: спиз… т ноутбук (хоть у меня там ключ и под паролем), я буду точно знать, какой ключ отзывать (и он грепается по hostname в конце ключа).

[Shark]

Прекрасно вас понимаю. Но тем не менее, случаи бывают разные. Вот к примеру, на команду разработчиков ключ к GitHub-у клиента был один. Получить доступ к аккаунту, чтобы добавить другой ключ не представлялось возможным. Пришлось этот ключ использовать и остальным членам команды.

[amarao]

буэ

Я не фанат всякой секьюрной хрени, но употребление общих ключей напоминает использование общей зубной щётки.

[Shark]

ИМХО, в данном случае это было вполне оправдано и достаточно секьюрно. По окончании работ заказчик просто удалит ключ, выданный команде для работы и никто больше не получит туда доступа. В конце концов, открытые/закрытые ключи и прочие механизмы аутентификации — всего лишь способ установления доверия между участниками.

[amarao]

Правильным вариантом было бы просто добавить людей/ключи людей к репозиторию.

[Shark]

Конечно. Но именно это и не представлялось возможным, о чём я написал в комменте выше.

[gnomeby]

Ещё есть MasterMode, который позволяет использовать уже установленное соединение для подключения ещё одной консоли, или использовании scp без авторизации. Активируется параметром -M. Или через config:
ControlPath /home/username/ssh-mastermode-%h-%p-%r
ControlMaster auto

[Ernillew]

Ну зачем вы прямо в ~ гадите?
~/tmp используйте или там ~/.ssh/socket какой-нить
а вот прямо ~/ это неприлично же, это все равно что справлять малую нужду на кухне.

[gnomeby]

Вы бредите. Это всего-лишь временный файл, который автоматически удалится при закрытии подключения.

[Ernillew]

временным файлам место в ~/tmp(или в /tmp зависит от вашей паранойи)

[GreyCat]

Ну, технически — это не совсем временный файл. Это то, что в /var/run помещается для системных сервисов (ну, или /run в новых системах). По аналогии — per user такое, наверное, должно бы в ~/run создаваться.

[Ernillew]

да, это сокет, но в принципе же всякие php-fpm создают свои сокеты в /tmp, потому я и предложил ~/tmp.
вообще у меня в системе оно в ~/.ssh/socket/ создает свои файлы, там оно мне совсем не мешает :)

[wlan]

Спасибо, теперь буду просто давать ссылку на эту статью, вместо рассказов.

[rtzra]

Аналогично. Только еще сопру в pdf, чтобы уж в совсем сложных случаях можно было пользоваться.

[slimlv]

Там с таром-то, не будет работать — хостнэйм пропущен.

[amarao]

Поправил.

[slimlv]

Которым а не который. Хотя да, не сразу ясно если не знаешь

[amarao]

Жаргонизм. Заходят пользователем на сервер. Ну или заходят «из-под пользователя на сервер». Имеется в виду тот username, который передаётся.

[ludenus]

угу. это фрагмент, который будет требовать разъяснений у многих

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

[spacediver]

Да, это недостаточно ясно. Можно сказать так: локальный пользователь (локальной машины), удаленный пользователь (определенного сервера).

[slimlv]

А вот еще ценная фича: ssh может своими силами делать chroot для пользователя sftp. Или такой хак: в список ключей можно вписать команду которая будет выполнятся на сервере вместо шэла при использовании ключа

[antarx]

Кстати, вы умеете настраивать chroot на sftp для отдельных ssh-учёток?

[slimlv]

как-то так:

Match group sftponly
         ChrootDirectory %h
         X11Forwarding no
         AllowTcpForwarding no
         ForceCommand internal-sftp

[antarx]

Проблема в том, что «как-то так» не работает, например, в свежем селектеловском дебиане — в зависимости от параметров либо вообще не логинит, либо не chroot'ит.

[slimlv]

как-то так у меня работает. Есть подводные камни: весь путь должен владеться root-ом, шэл — баш либо подобный

[amarao]

Простите, дебиан не «селектеловский», а просто дебиан. Мы не зря используем preseed для установки, а не клонируем готовое.

[antarx]

Да, проверил, вы правы — дебиан Скалакси. Премного извиняюсь!

[jov]

Если да — ключ сохраняется в файл ~/.ssh/known_hosts. Узнать, где какой ключ нельзя (ибо несекьюрно).

Разве?
Находим в ~/.ssh/known_hosts строчку с искомым доменным именем/ip-адресом, у удаляем её. Всё, наш клиент забыл «отпечаток» того сервера.

[slimlv]

Это от версии зависит — в дэбьяне там только номера

[Nikon_NLG]

HashKnownHosts no в /etc/ssh/ssh_config спасает.
На счёт ~/.ssh/config не уверен

[janatem]

Как ответили ниже, это зависит от опции HashKnownHosts. У меня другой вопрос — почему без нее считается несекьюрно? Это же публичные ключи. Я ее обычно отключаю, поскольку с ней автокомплит по имени хоста перестает работать.

[ksevelyar]

scp годится только для очень больших файлов, если нужно передать много мелких файлов, то лучше делать как-то так:

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

A sshfs можно подключать через fstab.

[ksevelyar]

%s/—/-/g

[wlan]

Чем не угодил scp -r?

[ksevelyar]

Тем, что это самый медленный способ: www.spikelab.org/transfer-largedata-scp-tarssh-tarnc-compared/

[slimlv]

бенч 2007 года? вылезайте из криокамеры — HPN уже запилили

[atomAltera]

А я просто в запускаемых приложениях (Linux Mint) дабавил команду монтирования (sshfs user@host:path path -o reconnect)

[Alexander_The_Great]

А компютер без интернета заведётся заведётся тогда, если в fstab прописать?

[khajiit]

Все нелокальное лучше через systemd automount unit. Зашли в папочку — она примонтировалась, если это возможно.

[grossws]

Раньше для fstab были опции указания сетевых точек монтирования чтобы не блокировать загрузку при отсутствии сети или недоступности сетевой фс. Дистроспецифичные опции, но всё же. В современном мире, конечено, лучше и проще взять и написать тривиальный mount unit для systemd.

[Alexander_The_Great]

А можно скрипт типа авторского на автозапуск поставить.

[khajiit]

Автозапускной скрипт или не поможет в случае недоступности ресурса или будет кривой и бажной альтернативной реализацией systemd'шных маунтов.

[wlan]

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

[wlan]

Пардон, промахнулся, это был ответ товарищу ksevelyar.

[spacediver]

А чем не угодил rsync -r?

[atomAltera]

>с него в этой статье показываются картинки
Решили проверить, выдержите ли хабраэффект?

[bondbig]

хабраэффект сильно переоценен, %username%

[amarao]

чё? Какой хабраэффект? У меня раздача торрента даёт большую нагрузку, чем отдача статики. За 5 часов 75к хитов.

Вообще ни о чём.

[GreyCat]

Не увидел описания типовой конструкции «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».

[amarao]

Мне кажется, последний вариант с ProxyCommand именно эту задачу и решает, причём его не надо «активировать», т.е. проходит нормальный ssh сквозь другой сервер.

[GreyCat]

Вариант с ProxyCommand плох несколькими вещами:

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

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

Кстати, да, про ControlMaster тоже ничего не увидел в статье, а это, субъективно, одна из самых важных, если не самая важная, настройка в ssh.

[jerom]

Почему ControlMaster так важен? Просто чтобы scp -r делать более свободно? Или для медленных каналов?

[GreyCat]

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

[amarao]

Простите, не понимаю о чём вы.

У меня до работы канал сильно меньший (от 50 до 100 мегабит), но я не вижу никаких запросов «да, использовать ключ» или тормозов в работе автокомплита.

[GreyCat]

Типовая ситуация: хочу скопировать какой-то файл из 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» имеет некоторые преимущества?

[amarao]

Ну, у меня один ssh-ключ, так что никаких запросов нет.

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

Засирание логов — может быть, но кого это реально волнует?

[GreyCat]

Какая разница, сколько ключей? Как раз напротив — если уж ключ везде один, то добавлять ключ без 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».

[SaveTheRbtz]

Дайте угадаю — у вас rtt до сервера в районе нескольких секунд? А теперь представьте, что сервер в Америке? Опять же ждать пока разгонится slow-start на LFP при передаче файлов не очень хочется.

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

[GreyCat]

А еще:

либо ssh разрешён (читай — делай что хочешь)

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

[amarao]

ICMP можно смело фильтровать по rate, доводя до нефункциональности туннель (но сохраняя пинги), DNS-запросы аналогично.

Вся ж фича не в том, что это «в принципе возможно», а в том, что это комфортно и стандартно. И трафик никак не выделяется «нехарактерными» признаками.

[GreyCat]

Так и ssh, пардон, что на 22, что на 443 — где угодно можно зашейпить, как и в целом трафик по любым портам, по которым нет L7-проксирования. Ну и, по сути, да — шейпинг и делание «некомфортно» — это чуть ли не единственный действующий способ претворения таких ограничений в жизнь.

[janatem]

А бывают такие туннели, которые прикидываются валидным http? А то я был в таком месте, где был только выход по 80-му и, насколько я понял, DPI. Здесь могут быть сложности с тем, что в дополнение ко всему содержимое http может фильтроваться и модифицироваться, что для веб-серфинга несущественно, а для обернутого ssh фатально.

[GreyCat]

Смотря что подразумевается под «валидным http» — метод CONNECT — тоже вполне себе http.

Туннелировать хитрым образом через особенный внешний туннельный http-сервер умеют многие, например вот есть проект с незамысловатым названием HTTPTunnel (серверная часть на php, клиентская — на perl или в виде бинарника под Windows) или там Proxytunnel — примерно то же самое, но еще банальнее, работает прямо со stdin/stdout, очень легко подключается к ssh через ProxyCommand.

[janatem]

Да, похоже, httptunnel — то что нужно.

[Portah]

Вот ещё инструкция хоть и на английском, но по ней все делал. И выбрался наружу в закрытом учреждении. Тоже про HTTPTunnel.
dag.wieers.com/howto/ssh-http-tunneling/

[spacediver]

У fusermount есть полезная опция -z (lazy unmount), которая позволяет отключить даже занятый каталог.

[Ernillew]

На заметку, в ssh_config(~/.ssh/config) можно прописать ForwardAgent Yes, что бы не передавать ключ -A каждый раз. Можно и для Host *, можно для конкретных хостов.

[ludenus]

годный ликбез
хочется подробностей про L2 over ssh и рецепт wake-up-on-lan через ssh

[vasilisc]

скорость по SSH (scp) хорошо поднимается, если выбрать шифрование «по легче».
в своё время вперёд выставлял Blowfish и скорость существенно возрастала.

по умолчанию установлено что-то типа
Cipher 3des Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc

[BasilioCat]

Некоторые считают, что arcfour ( RC4 ) чуть быстрее blowfish, и главное, потребляет меньше ресурсов. А при передаче файлов криптостойкость обычно не так уж важна (за это arcfour и не в фаворе, хотя и незаслуженно).

[janatem]

Небольшое дополнение насчет fuse. Бывает, что сетевое соединение отвалилось, тогда при попытке доступа к точке монтирования консоль намертво зависает (так что ^Z не помогает). В этом случае при отмонтировании нужно проявить выдержку, чтобы не нажать таб, вызвав тем самым зависание консоли из-за того, что автокомплит пытается читать подмонтированную директорию.

[worldmind]

Дополню своей заметкой там про удобный ввод парольной фразы и полезняшки в коментах

[Nastradamus]

Есть и вот такой головоломный приём использования pipe'а (любезно подсказали в комментариях в жж):

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

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

tar -cvf — -C upload. | ssh user@server tar -xpvf — -C /var/spool/www/upload/

[trapwalker]

Пардон за некропостинг, но зачем тут нужен `cd`?

[amarao]

Чтобы проверить, что в домашний каталог можно зайти. cd без параметров идёт в $home, если его нет или нет прав (или ошибка ФС и т.д.), то ломается, и не даёт выполнить tar в непонятное место.

[evg_krsk]

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

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

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

[amarao]

Да, должно.

[xdemon]

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

[amarao]

Всегда умело. Надо просто порт указывать правильно (кстати, спасибо, ща допишу в статью):

ssh-copy-id '-p443 [e-mail]'

(внимание на кавычки).

[shinespb]

можно и с двойными кавычками, типа ssh-copy-id "-p 2345 user@host"

[intrud3r]

Можно и вообще без кавычек.

[Stamm]

Извините, что не в QA. Как можно выполнить несколько команд. Что-то типо этого:

ssh example.com -t "cd /www/example.com && git status -sb | head -1"

[bondbig]

``

[phikus]

всё правильно написали, так что не понятно что вас смущает
ssh server «command1;command2;command3» или ssh server 'command1;command2;command3'

[1nd1go]

Крепко жму руку! Спасибо.

[apatrushev]

Мы когда-то написали для своей команды клиента, который умеет делать магию. Сейчас под GPL и лежит на гитхабе. Надо про него статейку сбацать наверное. Он сильно упрощает такие действа, как «хождение за три хопа в веб приложение».

[coocheenin]

Круто!

[Flagman]

Спасибо, пригодится!

[kbool]

Статья хорошая, спасибо.
P.S.

Ещё большая драма, если у нас есть нестандартный порт, и, например, первая версия ssh (привет цискам).

Привет от цисок: ip ssh version 2

[easy_john]

Есть старые циски (которых еще полно, и которые справляются со своими обязанностями) и они не умеют v2.

[kolebas]

спасибо за статью! не очень понял про проброс Х-сервера, ssh ric rdesktop -k en-us 192.168.1.1 -g 1900x1200, тут ric — это имя хоста в локальной сети?

[kolebas]

а да, вчитался — в предыдущем пункте конфиг
Host ric
Hostname ооо-рога-и-копыта.рф
User Администратор
ForwardX11 yes
Compression yes
т.е по сути это ssh -XYC user@SERVER rdesktop -k en-us 192.168.1.1 -g 1900x1200

[DeltaFlight]

Замечу, что со временем постоянная смена ключей хостов из-за переналивки задалбывает, и спасает только
HashKnownHosts no StrictHostKeyChecking no
в конфиге. После этого выключаются дурацкие вопросы про добавление в known hosts (yes/no), равно как и параноя про man-in-the-middle.

[StealthX]

Чудесно! Давно искал многое из этого в доступной форме с примерами. Спасибо большое!

[settler]

Еще одна полезная «фича» ssh — это Multiplexing. Если нужен шустрый автокомплит для scp, то можно запустить один терминал с ssh-сессией, а во втором работать с scp — он будет реюзать существующее подключение.

[shanker]

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

Стало быть, многие имеют рутовый доступ к DNS серверу гугла? Странно, что никто не обратил внимание на сей факт в статье

[foxgray]

Капитан очевидность докладывает, что это всего лишь пример.

[shanker]

Да это ясно. Я просто хотел сказать, что не очень удачно подобранный, так как пересекается с действительностью. Так, повод улыбнуться получившемуся в итоге выражению: «Но копировать его на 8.8.8.8 мы не хотим, ибо там проходной двор и половина людей имеет sudo и может шариться по чужим каталогам.»
Добавление смайликов к моему предыдущему сообщению подсказало бы, что оно носило саркастический характер. Но смайлы на хабре не котируются.Но копировать его на 8.8.8.8 мы не хотим, ибо там проходной двор и половина людей имеет sudo и может шариться по чужим каталогам.

[maxidler]

Кстати с socks-proxy можно несколько упростить задачу, когда находишься «Фиг знает где». Дело в том, что приходится каждой программе прописывать настройки socks5, а это утомительно.

Есть такая софтина redsocks — умеет заворачивать весь исходящий траф на определенный порт, а на этом порту мы и запускаем ssh -fNL…
К софтине правда еще прилагаются несколько правил iptables.

[SaveTheRbtz]

Хорошая статья, тут можно разве, что пропиарить книжку: 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

[Valery4]

либо ssh разрешён (читай — делай что хочешь), либо ssh запрещён

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

[unix_junkie]

Отличная статья, спасибо!

В качестве дополнения — есть ещё замечательня утилита 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

[StiflerWEN]

А если 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

[dmitryvolochaev]

У меня есть, что добавить. Проброс SSH через HTTP proxy с методом CONNECT

Вот конфиг для использования nc:

host github.com
  user git
  hostname github.com
  port 22
  proxycommand nc --proxy proxy.example.com:1234 %h %p

Если под Windows используется git, то вместе с git устанавливается инструмент под названием connect.exe, который используется так:

host github.com
  user git
  hostname github.com
  port 22
  proxycommand "C:\Program Files\Git\mingw64\bin\connect.exe" -H proxy.example.com:1234 %h %p

[kt97679]

Это работает только если прокси разрешает connect на порт 22, что скорее всего не так. squid, к примеру, по умолчанию разрешает connect только на порт 443:

acl SSL_ports port 443

acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl Safe_ports port 1025-65535 # unregistered ports

acl CONNECT method CONNECT

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

[LimeOrange]

Понекропостю немного, но чем черт не шутит.

Может ли кто поделиться простой, или относительно простой, или хотя бы не требующей слишком много телодвижений и реконфигураций командой/алиасом/функцией/магией для того чтобы залить файл с локальной машины в удаленный докер-контейнер? Но так чтобы при этом случайно не призвался ктулху и душу никому продавать не пришлось. Можно iTerm2-specific даже (он, к примеру, позволяет прямо из shell'а скачивать, если установлены integration tools, а вот в обратную сторону - уже не очень).

[khajiit]

Если это разовая операция, то посмотрите в сторону docker cp.
Если файл требуется обновлять на постоянной основе, то в сторону docker volumes.

[amarao]

cat local_file | ssh remote_server sudo docker cp - container_name:/path/in_containerner

Но с правами придётся всё равно возиться, если в контейнере не от рута.

[LimeOrange]

Шикарно! Спасибо! А есть предположения как оно себя будет вести с файлами 1Gb..10Gb?

[amarao]

Так же как с файлами 1..10Мб, только чуть медленее.

[powerman]

И вот в этот момент остро чувствуется нехватка смайликов-реакций на хабре.