OpenVZ - различные показания df -h и du -sh даже после перезапуска

У данных программ выдача может различаться, я ранее писал об этом: http://phpsuxx.blogspot.com/2010/11/df-du-sh.html


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

Имеем следующие показания в VPS:

vps:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/simfs 9.8G 7.2G 2.7G 74% /
tmpfs 150M 0 150M 0% /lib/init/rw
tmpfs 150M 0 150M 0% /dev/shm
community-seo:~# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/simfs 1280000 1152242 127758 91% /
tmpfs 38400 4 38396 1% /lib/init/rw
tmpfs 38400 1 38399 1% /dev/shm

vps:~# du -sh /*
0 /aquota.group
0 /aquota.user
4.4M /bin
4.0K /boot
4.0K /dev
4.9M /etc
12K /home
8.0M /lib
0 /lib64
4.0K /media
4.0K /mnt
4.0K /opt
du: cannot access `/proc/31770/task/31770/fd/4': No such file or directory
du: cannot access `/proc/31770/fd/4': No such file or directory
0 /proc
92K /root
5.1M /sbin
4.0K /selinux
4.0K /srv
0 /sys
12K /tmp
664M /usr
2.5G /var

Фикс:
vzctl stop ct
vzquota drop ct
vzctl start ct

Как ограничить ssh пользователя, входящего в систему по сертификатам лишь заданным диапазоном IP?

Итак, у нас есть Linux пользователь, который входит в систему по ssh с использованием ключей - парольная аутентификация запрещена. Задача - как ограничить пользователю возможный диапазон IP, с которых он входит в систему.

Вариант 1.

Задать диапазон хостов, с которых может входить юзер можно посредством директивы AlloUsers в /etc/ssh/sshd_config.

Вот цитата из официальной документации (man sshd_config):

AllowUsers This keyword can be followed by a list of user name patterns, separated by spaces. If specified, login is allowed only for user names that match one of the patterns. ‘*’ and ‘?’ can be used as wildcards in the patterns. Only user names are valid; a numerical user ID is not recognized. By default, login is allowed for all users. If the pattern takes the form USER@HOST then USER and HOST are separately checked, restricting logins to particular users from particular hosts.

Но, очевидно, каждый раз дергать конфиги такого важного демона как ssh для изменения IP крайне неправильно.

Вариант 2.

Использовать поле options в файле authorized_keys: from "ip_addr".

Выглядеть это будет так:

from "ip_addr" ssh-rsa AAAABтут_много_букв_которые_представляю_собой_ключ_в_base64== test@yandex.ru

Подробное описание из документации (man 8 sshd):

from="pattern-list"

Specifies that in addition to public key authentication, the canonical name of the remote host must be present in the comma-separated list of patterns (‘*’ and ‘?’ serve as wildcards). The list may also contain patterns negated by prefixing them with ‘!’; if the canonical host name matches a negated pattern, the key is not accepted. The purpose of this option is to optionally increase security: public key authentication by itself does not trust the network or name servers or anything (but the key); however, if somebody somehow steals the key, the key permits an intruder to log in from anywhere in the world. This additional option makes using a stolen key more difficult (name servers and/or routers would have to be compromised in addition to just the key).

Как проверить конфиг-файл ssh без перезапуска демона?

/usr/sbin/sshd -t

Использование KeyChain для работы с ssh

http://www.cyberciti.biz/faq/ssh-passwordless-login-with-keychain-for-scripts/

Как запретить логин в ssh по паролю для определенного юзера?

Match User someuser
PasswordAuthentication no

Работает только для Debian/Ubuntu, на CentOS поддержки Match нету!

http://serverfault.com/questions/84199/disable-ssh-password-authentication-by-user

Вывод ошибок на stderr в Python

import sys
print >> sys.stderr, 'This is error!'

http://stackoverflow.com/questions/939866/pythons-print-vs-stderr

Эмуляция канала с потерями

http://www.linuxfoundation.org/collaborate/workgroups/networking/netem

SSH, pseudo-tty -t: Connection to some.host.com closed.

При использовании интерактивного ssh:

ssh -t ....

Часто выдается ошибка Connection to some.host.com closed. Чтобы от нее избавится нужно рядом с -t добавить ключ -q.

Источник: http://fixunix.com/ssh/73970-how-avoid-connection-host-closed-t.html

Запуск интерактивных команд по ssh: TERM environment variable not set.

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

ssh test@node1.domain.ru top
TERM environment variable not set.

Чтобы все заработало, делаем так:

ssh test@node1.domain.ru -t top

Alternative DNS Servers бесплатная PDF книга

Содержание данной прекрасной книги: http://blog.fupps.com/2008/11/24/alternative-dns-servers-table-of-contents/

Ссылка на статью о бесплатном доступе к книге: http://blog.fupps.com/2010/10/29/alternative-dns-servers-the-book-as-pdf/

Ссылка на книгу: http://mens.de/:/altdnsbook

Вход в SSH по Public Keys из LDAP

http://blog.fupps.com/2006/03/02/ssh-public-keys-from-ldap/

sudoers в ldap

http://www.gratisoft.us/sudo/sudoers.ldap.man.html

Как работает cPanel jailshell?

http://www.learncpanel.com/server-administration/jailshell-virtfs/

Двухфакторная аутентификация посредством sms

http://en.wikipedia.org/wiki/Two_factor_authentication#SMS_One_Time_Password

Что такое двухфакторная аутентификация в двух словах?

Двухфакторная аутентификация

Аутентификация с использованием двух различных аутентифицирующих факторов.

Существуют три обобщенных аутентифицирующих фактора:
То, что Вы знаете, например пароль или PIN.
То, что Вы имеете, например, кредитная карта, аппаратный ключ или ключевой файл на флешке.
То, что Вы есть, например, отпечаток пальца, скан радужки или иная биометрия.

Распространенные реализации двухфакторной аутентификации используют "то, что Вы знаете" (пароль) как один из факторов, и либо "то, что вы имеете" (физическое устройство), либо "то, что Вы есть" (биометрия) в качестве второго фактора. Примером ДФА может служить банковская карта.

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

Взято без изменения с ресурса: http://www.pgpru.com/biblioteka/slovarj/dvuhfaktornajaautentifikacija