SSH уведомление об авторизации

13 ноября 2013
Рубрика: Linux, vanoc.ru
Теги: ,

vanoc

Решил реализовать уведомление на почту о том, что кто-то авторизовался в ssh. Сперва решение выглядело вот так:

echo -e "Remote connection from\t $SSH_CONNECTION \nLogin $USER" | /bin/mail -s "[SSH] Login on $(hostname)" мояпочта@сайт.ru

Добавляем эту строку в /etc/ssh/sshrc (в случае, если этого файла нет, а его скорее всего не будет, его следует создать)

У этого решения есть существенный недостаток — письма будут отсылаться после любой аутентификации по ssh. Даже если это вы залогинились, письмо все равно вам придет. Дабы не получать массу писем и ввиду того, что я начал изучать python, решил попробовать написать на нем. Получился скрипт сравнивающий с нашего ли ip залогинились, в противном случае шлет email на указанную почту.


#!/usr/bin/env python

import smtplib, os, platform
from email.MIMEMultipart import MIMEMultipart
from email.MIMEText import MIMEText

server = smtplib.SMTP('smtp.сайт.ru', 25)

sender = 'root@'+platform.node()
to = 'мояпочта@сайт.ru'

ip = 'xxx.xxx.xxx.xxx'
sship = os.environ['SSH_CONNECTION']
loginname = os.environ['LOGNAME']

msg = MIMEMultipart()
msg['Subject'] = '[SSH] Login on ' + platform.node()
msg['From'] = sender
msg['To'] = to
text = 'Remote connection from\t' + sship + '\nLogin ' + loginname
msg.attach (MIMEText(text, 'plain'))

textmail = msg.as_string()

if ip in sship:
        print ('hi. Welcome!')
else:
        print ('who is it?')
        server.sendmail(sender, to, textmail)

Сохраняем скрипт в файл, например, noticessh.py и прописываем путь к нему в /etc/ssh/sshrc. К сожалению не со всеми версиями второго питона работает, так же мешает авторизовываться по sftp в случае, если sftp работает через ssh. FileZilla, например, ругается «Оut of memory!» Надо бы допилить, но на данный момент к сожалению знаний по питону не достаточно.

sshfs

4 декабря 2012
Рубрика: Linux, vanoc.ru
Теги: ,

vanoc

На собеседовании встал вопрос монтирования директории удаленного сервера и тут я попал в просак. Ну что ж, исправляемся.

SSHFS (Secure SHell FileSystem) это файловая система для Linux (и других операционных систем, для которых существует реализация FUSE (Filesystem in Userspace), например Mac OS X), используемая для удаленного управления файлами по протоколу SSH (точнее, его расширению SFTP) таким образом, как будто они находятся на локальном компьютере. (Википедия)

Установим sshfs

в ubuntu/debian
sudo apt-get install sshfs
в Arch
sudo pacman -S sshfs

Монтирование
sshfs user@remotehost:/path/to/directory /local/path

Отмонтируем
fusermount -u /local/path

Удалённый доступ/Терминальный сервер с помощью FreeNX

18 апреля 2011
Рубрика: Debian, How-to, Lucid Lynx (10.04), Maverick Meerkat (10.10), Ubuntu
Теги: , , ,

Dedsy

Добавляем репозиторий:

sudo add-apt-repository ppa:freenx-team

Т.к. ppa не для Maveric/Natty нету вводим (для maveric) :


sudo sed -i 's/maverick/lucid/g' /etc/apt/sources.list.d/freenx-team-ppa-maverick.list

Или правим в /etc/apt/sources.list.d/freenx-team-ppa-natty.list версию на lucid.

Обновляемся:

sudo apt-get update

Скачиваем по ссылке (http://www.nomachine.com/download-package.php?Prod_Id=2520) 3 файла и ставим их командой:


sudo dpkg -i *.deb

Система на вас поругается, но это так и надо вводим :


sudo apt-get -f install

Впринципе всё, ставим клиент и пробуем конектиться… 🙂

Установка и настройка Ubuntu 10.04 «Lucid Lynx» на компьютер с Ubuntu: часть 1 — подготовка


Zeboton

Ubuntu 10.04Данный цикл заметок будет рассказывать о том, как установить и настроить Ubuntu 10.04 «Lucid Lynx» на компьютер, на котором уже установлена Ubuntu предыдущей версии. Путь установки ОС заново, а не обновления, выбран по нескольким причинам:

  1. На некоторых компьютерах установлены версии Ubuntu 9.04, Ubuntu 8.10, Ubuntu 8.04 или даже более ранние;
  2. Из-за постоянного экспериментирования на компьютере скопилась куча ненужных программ, файлов конфигураций и прочего мусора, от которого хочется избавиться.

Цикл будет состоять из нескольких частей:

Читать далее »

Запуск X приложений на удаленном компе через ssh

5 января 2010
Рубрика: vanoc.ru
Теги:

vanoc

Дабы иметь возможность запускать приложения/сообщения на удаленном компе достаточно подключившись к нему выполнить
export DISPLAY=:0.0
либо дописывать к командам
-display :0.0

1. Чтобы на удаленном компе появилось сообщение, можно воспользоваться утилитой xmessage, правда у нее проблемы с кирилицей
xmessage -center 'Vkljuchi skype'
2. Так же можно воспользоваться такой командой
echo 'button .b -text "Включи скайп" ; pack .b ' | wish
3. Создать текстовик и запустить
echo 'Включи скайп' > file; gedit file
4. Использовать libnotify
sudo aptitude install libnotify-bin
notify-send "Включи скайп, ночной красный гоблин"

Вообще способов привлечь внимание много. Интересно узнать какие знаете Вы?

Это страшное слово – «виртуализация». Мое решение на базе KVM.


Softovick

Заметка пригодится всем, кому интересно использовать виртуализацию в своей работе. Мое решение вполне может претендовать на промышленное применение и пригодится тем, кто захочет сократить расходы на аппаратную часть при необходимости иметь в наличии разветвленную сетевую инфраструктуру. На подобном варианте базируется некоторые решения от IBM, к примеру. Но эти решения далеко не бюджетные и востребованы лишь в исключительных случаях.
Итак, однажды мне понадобилось в домашних условиях воспроизвести разветвленную сетевую инфраструктуру, состоящую из различных программных платформ. Путь начинался от VMWare Workstation и завершился KVM… Почему именно KVM и как все было, читайте ниже.

1. Немного истории или с чего все началось.
Работая в банке, я вживую столкнулся с виртуализацией. Это была операционная система AIX от IBM, работающая на майнфреймах. С самого начала меня поразила мощь и гибкость подобного подхода. И когда мне понадобилось воспроизвести в тестовых целях дома разветвленную программную инфраструктуру, то сразу базировал все это на принципах виртуализации. Это позволило избежать как значительных затрат на аппаратную часть, так и уместить все весьма компактно в плане пространства.
Для читателя следует учесть, что на самом деле инструментов виртуализации великое множество. Каждый из них имеет свои тонкости и нюансы. Я же ставлю цель рассказать об одном варианте, с которыми работаю лично, описывая по возможности недостатки и особенности остальных.
2. Мой выбор называется KVM (или Kernel-based Virtual Machine).
Подробнее об этом варианте можно почитать тут.
Но лучше все по порядку излагать. Начну с условий отбора и какие из известных мне вариантов этим условиям неудовлетворяют:
— основная система должна быть бюджетной и мощной.

В аппаратном плане я выбрал вариант AMD Phenom X4 9550 / Asus M3A78 / 2x2Gb DDR-II / 1x160Gb IDE + 2x1Tb SATA-II. Видео здесь совершенно не приципиально, кроме того, что в случае встроенной придется учитывать, что она под себя забирает часть оперативной памяти, соответственно для виртуальных машин ее останется меньше. Скажу сразу — выбор материнки с встроенным RAID-контроллером был не совсем корректным. Как выяснилось, RAID этот работает только в программном режиме, т.е. нужны драйвера для Windows систем, ну а в Linux такого же эффекта можно было достичь гораздо проще, используя стандартные средства.
Использование программной платформы для основной системы было однозначно в пользу GNU/Linux, т.к. позволяло получить среду виртуализации без лишних затрат на лицензирование, а также более облегченную в плане нагрузки (вот никогда я не пойму, почему в Windows Server без графики ничего нельзя поставить и сделать…. бессмысленная нагрузка, ИМХО). Изначально планировалось использовать вариант Ubuntu Server Hardy LTS, но почти сразу была произведена миграция на Debian Lenny (он к тому времени как раз вышел).Ни в коем случае не принижаю достоинства Ubuntu, но субьективно Debian стабильнее и быстрее работает.

— система виртуализации должна быть стабильной, общедоступной и нетребовательной к ресурсам.

От выбора разбегаются глаза, но после изучения отзывов в интернете и попыток использования сложилось субьективное мнение.
Продукты VMWare не подходят. Workstation платная, ESXi не удалось поставить на мою систему из-за неподдерживаемого чипсета (он у меня оказался более современным). Неплохим выбором был бы VMWare Server, но судя по отзывав она тяжеловата и периодически падает, сам я не стал пробовать после неудачи с ESXi. Не подошли они еще по одной причине — компания все таки продает свои продукты и только часть из них доступна в свободном доступе.
VirtualBox оказался весьма удачным вариантом. Существует в двух вариантах — OSE и Freeware. В открытом доступе исходников Freeware-версии нет, зато компенсируется это функциональностью. Из известных мне различий — это отсутствие в OSE версии поддержки USB, ограничения при работе с сетью, неподдерживается графическая акселерация (кстати, дающая весьма приличный прирост скорости работы виртуальной машины). VirtualBox идеально подходит для простейшей реализации, т.к. позволяет быстро получить работоспособную виртуальную машину без лишних телодвижений и внимательного изучения руководства. Приятной особенностью оказалась поддержка работы из консоли, что позволяет не использовать графических надстроек и соответственно снимается дополнительная нагрузка на хост-машину. Для начинающих «домашних виртуализаторов» я бы посоветовал именно такой вариант. Лично я до сих пор его использую на личном ноутбуке для быстрого поднимания тестовой среды, а также для работы в Windows (там уже давно и стабильно обосновалась Ubuntu в качестве основной системы). По субьективным ощущениям работает VirtualBox гораздо шустрее VMWare Workstation, занимает меньше места как на диске, так и в памяти. Для каждой машины выделяется отдельное окно, а также при установленных драйвера в гостевой системе (есть «из коробки») есть возможность интегрировать в рабочий стол хоста, что очень удобно и позволяет разнести задачи на разные виртуальные столы.
QEMU — очень мощная штука. Но когда вспомнил про нее, уже обратил внимание на виртуализацию на базе ядра и информацию про Xen и KVM, потому близко знакомится с чистым QEMU не стал.
Xen — идеальная система для виртуализации. Но имеет весьма существенный недостаток — гостевая система должна быть заранее подготовленна.
KVM, базируется на QEMU, по скорости почти не уступает Xen, зато обладает более гибкой функциональностью, всей мощью настроек QEMU (хотя основная часть необходимых мне была и в VirtualBOX). Оба варианта, Xen и KVM реализованы во всех современных дистрибутивах и для использования не надо прилагать серьезных усилий. Но есть между ними принципиальное отличие, о котором пойдет речь дальше.

— необходимо иметь возможность воспроизвести на виртуальных машинах различные программные платформы.

Несмотря на доступность в этом плане продуктов VMWare и VirtualBOX, от их использования я отказался еще ранее, так что рассматривать не буду… А вот применительно к Xen и KVM опишу чуток подробнее, т.к. сам искал информацию весьма долго.
Xen не позволяет запускать системы отличные от хостовой!!!, а точнее не подготовленные заранее для работы в виртуальной среде. И к сожалению (а может к счастью), подобной обработке не поддаются дистрибутивы Windows. Что меня не устраивало, потому в итоге выбор пал на варианте использования KVM, для которого заранее подготавливать гостевую систему не надо.

Итак причины выбора KVM кратко:

1. Реализация доступна из коробки в любом большом дистрибутиве;
2. Реализовано на базе ядра Linux, соответственно обладает большой скоростью;
3. Используется такими гигантами, как RedHat и Ubuntu, что говорит о высокой стабильности и гибкости;
4. Не требуется дополнительных махинаций с гостевой системой для установки в виртуальную машину.

3. Как я сделал это на Debian.
Дальше пойдет больше техническое описание, описывающее по шагам, как я сделал свой сервер, свободно тянущий с десяток виртуальных серверов.
Несмотря на то, что мой любимый дистрибутив Ubuntu, в итоге под базовую системы был выбран Debian. В рамках статьи объяснять тонкостей не буду, что да как, но на десктопе я все также предпочитаю использовать Ubuntu. Большинство инструкций для Ubuntu и Debian актуальны для обоих вариантов, потому при настройке я использовал и это и то и другое.
Итак, начнем ставить сервер.
Берем дистрибутив Debian. Чтобы не качать лишнего потом и сразу получить свежую систему, я брал вариант netinstall, при помощи которого устанавливал только вариант «Стандартная система», большего нам и не надо. Кстати, я использую 64-битный выпуск, чтобы получить поддержку большего количества оперативной памяти (>3Гб) без обходных путей и выкрутасов (к примеру, 32-битное серверное ядро дистрибутива Ubuntu поддерживает больше, чем 3Гб, но только при наличии такой возможности в чипсете).
Я использую под системные разделы («/», «/home», swap) жесткий диск IDE, дабы не иметь проблем при работе системы при установке на RAID-массив (а они есть). При установке сразу создаю RAID-1 на основе двух жестких дисков SATA для достижения большей сохранности данных (основная информация будет храниться на нем). В дальнейшем для работы с софтовым RAID-массивом следует использовать утилиту mdadm.
Свежеустановленную систему я немного ретуширую. Для начала устанавливаю ssh, чтобы можно было сразу засунуть системник подальше и отключить от него уже ненужный монитор:sudo apt-get install sshМногие советуют переключить порт с стандартного 22 на другой. Но это следует делать только в том случае, если вы уверены в своих действиях и ваш сервер подключен напрямую к интернету. Кстати, следует упомянуть, что если будет использоватся нестандартный порт, то потом возникнут сложности с удаленным управлением KVM-виртуализацией. Поэтому я оставил стандартный порт, но через аппаратный маршрутизатор сделал переброску на нестандартный, доступный снаружи.

Затем включаем синхронизацию времени через интернет (настоятельно советую, пригодится).
sudo apt-get install ntp ntpdate
Для контроля температуры чипсетов, процессора и жестких дисков:
sudo apt-get install lm-sensors hddtemp
Утилита hddtemp работает сразу, для настройки lm-sensors запускаем после установки:sudo sensors-detectотвечаем на все вопросы утвердительно.
Использовать очень просто:
— узнать температуру процессора, чипсета и других характеристик sudo sensors получаем что-то вроде:

it8712-isa-0290
Adapter: ISA adapter
VCore 1: +1.33 V (min = +3.54 V, max = +3.30 V) ALARM
VCore 2: +3.76 V (min = +1.39 V, max = +1.01 V) ALARM
+3.3V: +3.28 V (min = +4.00 V, max = +0.91 V) ALARM
+5V: +6.69 V (min = +3.04 V, max = +6.10 V) ALARM
+12V: +12.67 V (min = +15.23 V, max = +5.57 V) ALARM
-12V: -15.33 V (min = -0.85 V, max = -12.39 V) ALARM
-5V: +2.85 V (min = +3.06 V, max = +3.47 V) ALARM
Stdby: +5.99 V (min = +0.11 V, max = +6.37 V)
VBat: +3.31 V
fan1: 2922 RPM (min = 3260 RPM, div = 2)
fan2: 0 RPM (min = 5400 RPM, div = 2) ALARM
fan3: 0 RPM (min = 2732 RPM, div = 2) ALARM
M/B Temp: +44.0°C (low = -73.0°C, high = -49.0°C) sensor = transistor
CPU Temp: +32.0°C (low = -65.0°C, high = -9.0°C) sensor = transistor
Temp3: +128.0°C (low = +23.0°C, high = -66.0°C) sensor = disabled
cpu0_vid: +0.000 V

— узнать температуру 1 жесткого диска SATA — sudo hddtemp /dev/sda получаем что-то вроде:

/dev/sda: WDC WD1001FALS-00J7B0: 33°C

Для дальнейшей работы рекомендую обзавестись сторонним DHCP-сервером и на нашем сервере виртуализации настроить bridge-интерфейс.
Установим нужные утилиты: sudo apt-get install bridge-utils
Я использую в качестве DHCP-сервера свой роутер, а bridge-интерфейс создавал по инструкции. По той же инструкции рассказано, как сделать, чтобы виртуальная машина в KVM создавалась по умолчанию с использованием этого способа подключения. Для ускорения перезагрузки (совершенно не критичная ситуация, если сервер будет включен круглосуточно) советую заранее указать статический адрес на интерфейс даже при условии доступности DHCP.

И самое вкусное, устанавливаем KVM модули и полезные утилиты. Сразу добавим текущего пользователя в соответствующую группу для доступности использования KVM. Описание использования утилит можно найти по уже указанным руководствам.sudo aptitude install kvm libvirt-bin virtinst virt-top python-virtinst
sudo adduser softovick libvirt
Фактически сразу можно использовать. Описывать все команды смысла не вижу, для этого есть man. Но покажу, как я создаю виртуальную машину:
для Linux virt-install -n linux -r 512 -f linux.img -s 15 -c образ.iso --accelerate --vnc --vncport=5900 --noautoconsole --os-type=linux --os-variant=generic26
для Windows virt-install -n windows -r 512 -f windows.img -s 15 -c образ.iso --accelerate --vnc --vncport=5901 --noautoconsole --os-type=windows --os-variant=win2k3 --noacpiПосле этого дальнейший ход установки и экран гостевой машины можно контролировать, подключившись при помощи VNC-клиента к серверу по порту 5900 и 5901(рекомендую для каждой машины заранее определять порт VNC, чтобы было удобно подключаться). Есть еще несколько полезных опций, я их не использую лишь потому, что не столкнулся с их необходимостью.

И еще один штрих, но не последний. Как подключить к гостевой системе возможность что-то писать напрямую на физический раздел или папку на рейде, я пока не понял, хотя и старался. Поэтому в случае Linux я подключаюсь к данным на сервере при помощи nfs, а в случае Windows — при помощи Samba. Настройка Samba достаточно тривиальна, устанавливаем sudo aptitude install samba и правим конфигурационный файл /etc/samba/smb.conf под свои задачи. А вот установка и настройка nfs не совсем тривиальна. Я использую такой вариант установки, позволяющий подключаться к нужным папкам с любого ip-адреса локальной сети (вида 192.168.10.*):sudo aptitude install nfs-kernel-server portmap
perl -pi -e 's/^OPTIONS/#OPTIONS/' /etc/default/portmap
echo "portmap: 192.168.10." >> /etc/hosts.allow
/etc/init.d/portmap restart
echo "/media/raid 192.168.10.0/255.255.255.0(rw,no_root_squash,subtree_check)" >> /etc/exports
/etc/init.d/nfs-kernel-server reload
После приведенных действий достаточно на гостевой системе сделать так:
sudo mount сервер:/media/raid локальная_папка
При необходимости можно включить автоматическое монтирование при загрузке, поправив конфигурационный файл /etc/fstab, добавив туда строку типа:
virtual:/media/raid /media/raid nfs defaults 0 2
Ну вот, в целом настройка нашего сервера виртуализации завершена. Управлять им можно как в консоли, так и при помощи графических инструментов virsh или virtual manager.

P.S.:
Некоторые полезные советы:
1. Если вы указали конкретный порт VNC для гостевой машины, то через Virtual Manager вы не сможете автоматически запустить графическую консоль.
2. Virtual Manager не сможет подключиться, если у вас переопределен порт ssh. Точнее для этого придется долго и нудно разбираться.
3. Обязательно используйте для гостевой Windows Server режим —noacpi, чтобы она нормально установилась.
4. Аккуратно настраивайте режим сбережения энергии на гостевых системах, ни в коем случае не отключайте экран, иначе не сможете потом подключится по VNC.
5. Если вы хотите удаленно выключать и перезагружать машины через Virtual Manager, то отключайте хранитель экрана, т.к. он блокирует управление питанием.

Автостарт WiFi сети в Ubuntu 8.10 «Intrepid Ibex»

14 января 2009
Рубрика: Intrepid Ibex (8.10), Ubuntu, Заметки
Теги: ,

Zeboton

NetworkManager в Ubuntu 8.10 был переработан очень сильно и, как мне кажется, в лучшую сторону. Где-то на форуме я читал, что он теперь может подсоединяться к 3G сетям через USB модем! Но в этом благоденствии есть нюанс.

У меня дома маленькая WiFi сеть. NetworkManager в Ubuntu 8.10 подключается к WiFi сети только после того как пользователь авторизуется в системе (откроется сессия Gnome). С одной стороны это правильно, но с другой стороны я хочу управлять компьютером с WiFi через ssh. То есть я хочу нажать на кнопку включения на корпусе нужного компьютера, перейти к своему MSI Wind и с него по ssh управлять включённым и подключённым по WiFi к сети компьютером.

С настройками по-умолчанию такое сделать не получалось. Но немного покопавшись в конфигурационных файлах я нашёл решение. Всё просто!

Открываем из под sudo файл /etc/network/interfaces чтобы можно было произвести в него запись:

sudo nano /etc/network/interfaces

И добавляем в него код:

auto ath0
iface ath0 inet static
address 10.5.5.10
netmask 255.255.255.0
gateway 10.5.5.1
wireless-key 12345678901234567890123456
wireless-essid homeNet

Где:
ath0 — имя интерфейса у меня. Для того чтобы узнать какой у вас интерфейс отвечает за WiFi достаточно выполнить в терминале команду:

iwconfig

10.5.5.10, 255.255.255.0, 10.5.5.1, 12345678901234567890123456, homeNet — данные из моей сети у вас они будут другие.

Почти всё готово, осталось только прописать DNS и всё будет работать как часы. Открываем нужный файл:

sudo nano /etc/resolv.conf

Добавляем в него строчку:

nameserver 10.5.5.1

Вместо 10.5.5.1 впишите IP адрес своего роутера или IP адрес DNS сервера своего провайдера.

Сохраняем файл. Перезагружаем компьютер и всё работает 🙂