30 сент. 2011 г.

Авторизация пользователя по ssh с использованием rsa-ключа

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

1. Создание rsa-ключа.

Вначале на той машине, с которой хотите ходить везде (т. е. например, ваша рабочая) создаем пару ключей:
ssh-keygen -t dsa
 
Отвечаем на вопросики, даем или не даем (не рекомендуется, иначе зачем мы вс это делаем?) пароль на ключик.

Получаем пару файлов - публичный и приватный ключ. Публичный ключ, который мы будем копировать на сервера, на которые хотим заходить по ключу называется:
 
id_dsa.pub

2. User management

Далее опциональные шаги. Заходим на целевой сервер и:
1. Создаем юзера командой useradd name_of_user
2. Создаем пароль нашему юзеру командой passwd name_of_user
3. Добавляем пользователя в файл /etc/sudoers (если sudo не установлен и файлика нет - устанавливаем apt-get install sudo или типа того) после похожей записи рута и изменяем или комментируем строчку требования пароля:
 
Defaults !requiretty

Затем после строчки %sudo ALL=(ALL) ALL пишем:
name_of_user ALL=(ALL) NOPASSWD:ALL
 
Теперь команда sudo su - не будет запрашивать пароль.

3. Копирование ключа на удалённый сервер

Есть два пути:
 
а) копируем ключ автоматически. Для этого на сервере, где есть публичный ключ, выполняем:
ssh-copy-id -i ~/.ssh/id_dsa.pub user@remote-host
 
где параметром -i передается путь в публичному ключу и кладется в папку .ssh указанного пользователя со всеми правами автоматически.
 
б) копируем вручную. Для этого заходим в хомяк пользователя на удаленном сервере, создаем там папку .ssh, а в ней файл authorized_keys, в который копируем наши публичные ключи - смотрите, чтобы каждый ключик был в одну строчку!
Изменяем владельца наших файлов/директорий - ссх очень чувствителен к этому.

chown -R name_of_user:name_of_user .ssh
chmod 700 .ssh
chmod 400 .ssh/authorized_keys
 
Всё, теперь мы можем зайти удаленно на наш сервер по ssh не указывая пароль нашего пользователя и командой sudo su - сразу превратиться в рута без вопросов :)

4. Способы авторизации на удалённом сервере по ключу

Один из способов был указан ранее.
Далее просто командой c указанием пути к ключу:
 
ssh -i /path/to/key/key.pem user@server
 
И ещё один вариант - добавить конфиг файл. Осбенно хорошо когда серверов несколько.
Добавляем в папку вашего пользователя на клиенте:
 
nano /home/your_user/.ssh/config
 
следующее:
 
Host server1 server1.company.com
Hostname 192.168.1.2
User username
IdentityFile /path/to/key/key1.pem

Host server2 server2.company.com
Hostname server2.com
User username
IdentityFile /path/to/key/key2.pem

И потом можно сразу заходить командами вида:

ssh server1

ssh server2

Update 1.

 
Столкнулся с ситуацией, когда всё проделанное выше не работало для удаленного сервера Oracle Linux 6.8 (аналог RHEL/CentOS 6.8) пока я не выполнил команды:
 
chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys
restorecon -R -v /root/.ssh
 
Несмотря на то, что Selinux был выключен.

Update 2.

 
Описанные в начале команды для новых систем Debian/Ubuntu не сработали. Потому создаём ключи другого формата:
 
Создаём ключи на сервере1:
 
ssh-keygen -t rsa -b 4096 -C "domain.com"
 
Копируем ключи на сервер2:
 

ssh-copy-id user@server2

Дролжны получить такой результат:

"

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/root/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
user@server2's password:

Number of key(s) added: 1

Now try logging into the machine, with: "ssh 'user@server2.

"

Проверяем:

ssh user@server2

Ссылки:

  1. http://www.beginninglinux.com/home/server-administration/openssh-keys-certificates-authentication-pem-pub-crt
  2. https://linuxhint.com/generate-ssh-key-ubuntu/

26 сент. 2011 г.

Автоматизация управления Snapshot'ами в VMWare vServer, vCenter

Если у вас много виртуальных машин на vServer'e, то создание новых снапшотов и удаление устаревших может стать очень рутинным занятием. Есть тулза, которая ставится вместе с сервером - VMware vCenter Orchestrator. Но её очень напряжно настраивать - для неё нужно настроить MSSQL Server, LDAP/AD и еще много чего) я запнулся на LDAP, т. к. структуры АД не было в той сети, в которой был сервер, а ADAM как-то странно себя вел на том сервере. И я нашел альтернативу :)  - примочку к Power Shell. Работало у меня всё под Windows Server 2003, а там нет по умолчанию павер шелла - выкачиваем его отсюда: http://support.microsoft.com/kb/968930/en-us

Затем качаем саму примочку - Power CLI: http://communities.vmware.com/community/vmtn/server/vsphere/automationtools/powercli


По умолчанию в Windows 2003 не разрешено выполнять скрипты PowerShell в соответствии с политиками выполнения сценариев (Execution Policy). Чтобы разрешить это, запустим консоль PowerShell и напечатаем:

Set-ExecutionPolicy RemoteSigned

Теперь можем пользоваться новой примочкой, запустив ее из меню Пуск/Программы.

Ознакомиться с тем, какие команды она воспринимает, можно из гугла, нас сейчас интересует написание скриптов, которые будут автоматом создавать и удалять снапшоты. Для этого создаем 2 текстовых файла, редактируем и переименовываем потом.

1й - addsnapshots.ps1 :


Connect-VIServer ИмяСервера
get-vm | new-snapshot -name "AutoSnapshot"


20 сент. 2011 г.

Ruby Gem за прокси

Недавно столкнулся с проблемой при установке gem'a Rails:

gem install rails

ERROR: Could not find a valid gem 'rails' (>= 0) in any repository

путем гугла понял проблему:

gem install rails -V


Error fetching remote data: Errno::ECONNREFUSED: Connection refused - connect(2) (http://rubygems.org/quick/Marshal.4.8/rails-3.1.0.gemspec.rz)

Falling back to local-only install

ERROR: Could not find a valid gem 'rails' (>= 0) in any repository

ERROR: Possible alternatives: rails


Руби не прохавал настройки прокси :) пробиться через проксю помогла такая опция:

gem install rails -p http://proxy.com:3128

Вместо моего адреса пишите адрес вашего прокси, конечно.

Всем пока :)

15 сент. 2011 г.

Настройка Squid как High Anonymity(Elite) proxy

Немного теории. Есть такая штука - html headers ( http://en.wikipedia.org/wiki/HTTP_header ). Передавая которые, наш прокси сообщает очень много данных о себе целевым хостам.

Существует 2 типа анонимных прокси:
  • Anonymity - скрывает только IP клиента;
  • High Anonymity(Elite) proxy - скрывает вообще сам факт того, что клиент находится за прокси.
Настраивается High Anonymity(Elite) proxy очень легко: по статье на офиц вики  http://www.squid-cache.org/Doc/config/header_access/

Т. е. Оставляем только нужные нам html-хедеры, а остальные запрещаем (вариант 2):

header_access Allow allow all
header_access Authorization allow all
header_access WWW-Authenticate allow all
header_access Proxy-Authorization allow all
header_access Proxy-Authenticate allow all
header_access Cache-Control allow all
header_access Content-Encoding allow all
header_access Content-Length allow all
header_access Content-Type allow all
header_access Date allow all
header_access Expires allow all
header_access Host allow all
header_access If-Modified-Since allow all
header_access Last-Modified allow all
header_access Location allow all
header_access Pragma allow all
header_access Accept allow all
header_access Accept-Charset allow all
header_access Accept-Encoding allow all
header_access Accept-Language allow all
header_access Content-Language allow all
header_access Mime-Version allow all
header_access Retry-After allow all
header_access Title allow all
header_access Connection allow all
header_access Proxy-Connection allow all
header_access All deny all


Еще можно разрешить хедер Set-Cookie ибо без кукисов многие сайты не будут корректно проводить авторизацию пользователя и т. п.

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

Протестить наш проксик можно с помощью сайта http://proxydetect.com/ (не забыв в настройках браузера вбить наш прокси).

После написание вышеописанного :) обнаружил более простой способ:

header_access Via deny all
header_access Proxy deny all

header_access X-Forwarded-For deny all

И всё :) не отсылая эти заголовки, наш прокси становится хай анонимным.

З. Ы. Конфиг валидный для сквиды 2.5 или 2.7. Для 3.х сквиды директива header_access заменяется на request_header_access и reply_header_access, т. е. нужно запрещать заголовки как для запроса, так и для ответа.

9 сент. 2011 г.

Установка веб-сервера Apache на Linux Gentoo с использованием разных версий php на разных виртуалхостах

Я не проггер, потому не могу сказать, какие там отличия у php 5.2 и php 5.3, но они есть и иногда возникает необходимость девелопить под ту или другую версии. Сейчас я поведаю вам, как это реализовать на одной машине с Gentoo Linux.

Для начала устанавливаем апач и оба пхп. Там надо немного поколдовать с  USE - у меня уже не сохранился лог моих мучений) но у вас всё получится - я уверен: оно, как правило, пишет чего ему не хватает и остается только подключить это.

Для того чтобы подключить два mod_php к разным apache на разных IP нужно две разных конфигурации для apache (да и два разных запущенных apache). В Gentoo, к счастью, это делается очень просто. Скрипт запущенный из /etc/init.d/ будет искать себе начальную конфигурацию в /etc/conf.d/ согласно своему префиксу: скрипт /etc/init.d/apache2 получит конфигурацию из /etc/conf.d/apache2, /etc/init.d/apache2.php52 из /etc/conf.d/apache2.php52, /etc/init.d/apache2.php53 из /etc/conf.d/apache2.php53. Таким образом просто делая линки на оригинальный скрипт из /etc/init.d мы можем передавать разные параметры программе. В нашем случае это будут разные Define директивы апачу (через флаг -D). Это позволит использовать один конфигурационный файл разделив нужные нам опции директивами IfDefine.

Разделять директивами следует те ресурсы, которые не могут совместно использоваться разными процессами apache, например лог-файлы, pid-файлы. Или разную функциональность, например разные версии mod_php или разные сертификаты SSL.

Настройка всего этого хозяйства.

Для начала создаем себе 2-й IP адрес:

ifconfig eth0:0 10.10.7.249

Для того чтобы меньше менять в конфигурации примем стандартные определения - для того чтобы грузится с PHP 5.2 апачу нужно передать -D PHP52, а для PHP 5.3 соотвественно -D PHP53. Добавим к этим двум еще и определение -D TWO_PHP, что позволит нам иметь три разных конфигурации:

  • если неопределено TWO_PHP (что есть по-умолчанию), то будем иметь апач настроенный по-умолчанию (удобно для тестирования и отладки глюков других конфигураций)

  • если определено TWO_PHP & PHP52 - получаем апач с PHP 5.2

  • если определено TWO_PHP & PHP53 - получаем апач с PHP 5.3

Соответственно делаем два линка на стартовый скрипт:

ln -s apache2 /etc/init.d/apache2.php52
ln -s apache2 /etc/init.d/apache2.php53


Копируем и изменяем настройки в /etc/conf.d:

cp /etc/conf.d/apache2{,.php52}
cp /etc/conf.d/apache2{,.php53}


в apache2.php52:


APACHE2_OPTS="-D PHP52 -D TWO_PHP ..."

в apache2.php53:

APACHE2_OPTS="-D PHP53 -D TWO_PHP ..."

Также в этих двух файлах меняем директорию PIDFILE.

httpd.conf от стандартного отличается следующим:


<IfDefine !TWO_PHP>
   Listen 80

</IfDefine>
<IfDefine TWO_PHP>
   <IfDefine PHP52>
     Listen 10.10.7.7:80
   </IfDefine>
   <IfDefine PHP53>
     Listen 10.10.7.249:80
   </IfDefine>
</IfDefine>


Include /etc/apache2/vhosts.d/*.conf

Понятно, что в listen указываем свои IP, а Include нужен для поддержки виртуал хостов.

vhosts.confбудет таким:

<VirtualHost site1.example.int> 
   ServerName site1.example.int
   DocumentRoot "/var/www/php5.2/"
   <Directory "/var/www/php5.2">
     Options Indexes FollowSymLinks
     DirectoryIndex index.php
     AllowOverride All
     Order allow,deny
     Allow from all
   </Directory>
</VirtualHost>

<VirtualHost site2.example.int>
   ServerName site2.example.int
   DocumentRoot "/var/www/php5.3/"
   <Directory "/var/www/php5.3"> 
     Options Indexes FollowSymLinks
     AllowOverride All
     DirectoryIndex index.php
     Order allow,deny
     Allow from all
   </Directory>
</VirtualHost>

Также надо подправить файлик /etc/httpd/modules.d/70_mod_php5.conf:

IfDefine PHP5> # Load the module first
<IfModule !mod_php5.c>
   LoadModule php5_module modules/libphp5.so
</IfModule>

# Set it to handle the files
<IfModule mod_mime.c>
   AddHandler application/x-httpd-php .php .php5 .phtml
   AddHandler application/x-httpd-php-source .phps
</IfModule>
   DirectoryIndex index.php index.phtml
</IfDefine>

<IfDefine TWO_PHP>
   <IfDefine PHP52>
     LoadModule php5_module /usr/lib/php5.2/apache2/libphp5.so
   </IfDefine>
   <IfDefine PHP53>
     LoadModule php5_module /usr/lib/php5.3/apache2/libphp5.so
   </IfDefine>
<IfModule mod_mime.c>
   AddHandler application/x-httpd-php .php .php5 .phtml
   AddHandler application/x-httpd-php-source .phps
</IfModule>
</IfDefine>

Также, если не настроен ДНС у вас, то не забываем вписать в /etc/hosts наши домены:

10.10.7.7      site1.example.int
10.10.7.249    site2.example.int


Вроде бы всё... Запускаем:

/etc/init.d/apache2.php52 start

Проверяем 1й IP (пофиг проверяем, даже если ругается апач что не стартует - у меня ругался, но работал :) ).
 Затем удаляем PID файл апача:

rm /var/run/apache2

Магия запуска двух апачей с разными PID файлами мне пока еще не доступна, потому так по-китайски делаем :)

/etc/init.d/apache2.php53 start

Всё должно работать теперь.

Кстати, не забудьте в директории /var/www/php5.3 и /var/www/php5.2 для проверки кинуть файлик index.php с содержимым:

<? php
phpinfo();
/> 

Всем спасибо за внимание :) 

Автоматический редирект с http версии на ssl (https) версию сайта в Apache

Чтобы решить этот маленький квест нужно в конфиге апача (httpd.conf) прописать следующее:

RewriteEngine On 
RewriteCond %{SERVER_PORT} !443 
RewriteRule (.*) https://localhost/ [R]

Вместо  https://localhost/ вписываем название своего домена.

З. Ы. Чтобы заработало, надо или собрать апач с поддержкой mod-rewrite или чтобы этот модуль был включен:

LoadModule rewrite_module modules/mod_rewrite.so

1 сент. 2011 г.

Установка Gentoo Linux на VMWare

Сам процесс установки мало чем отличается от того, что описан на http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1 За исключением одних небольших, но очень важных граблей... О них я тут и поведаю.

Грабли сии заключаются в том, чтобы включить поддержку жеских дисков VMWare в ядро на этапе его компиляции. Т. е. надо перед компиляцией ядра выполнив команды

# cd /usr/src/linux
# make menuconfig


В менюшке найти ([/]) и включить в ядро ("*", а не "М"!!! - в этом-то как раз и весь прикол) драйвера, cодержащие фразы VMWare, Buslogic, Sym53.

Тогда при загрузке эти драйвера будут сразу подгружаться с ядром и операционка увидит наш виртуальный винчестер.

Всем удачи!