Конфиг вашего SSH хранится в /etc/ssh/sshd_config.
Открыть можно, скажем через редатор nano

# nano /etc/ssh/sshd_config

В нем
PermitRootLogin no

Перед этим создайте пользователя который имеет доступ к SSH, а то не зайдете никогда.

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

# su -

https://habr.com/company/ruvds/blog/314166/

Данные последнего входа в систему

Выясните данные последнего входа в систему. Делается это с помощью команды lastlog.

$>lastlog

▍История команд

Взгляните на историю команд, узнайте, когда именно их вводили:

$>history

Если список команд выводится без даты – настройте соответствующие параметры утилиты history.

▍Журнал auth.log

Следующий способ проверки – просмотр файла /var/log/auth.log. Например, с помощью такой команды:

$>sudo vi /var/log/auth.log

Здесь можно найти список всех, кто пытался подключиться к серверу по SSH.

▍IP-адреса

Для того, чтобы выяснить IP-адреса, с которых подключались к серверу, воспользуйтесь такой командой:

$>zgrep sshd /var/log/auth.log* | grep rhost | sed -re 's/.*rhost=([^ ]+).*/\1/' | sort –u

▍Журналы Apache

Проверьте журналы Apache:

$>sudo vi /var/log/apache2/access.log
$>sudo vi /var/log/apache2/error.log

▍Поиск подозрительных процессов

Если вы уверены в том, что сервер взломан, разыщите процесс злоумышленника. Например, список всех процессов можно получить такой командой:

$>ps aux | less

▍Список заданий cron

Анализируя сервер на предмет взлома, полезно будет проверить список заданий cron, в который злоумышленник вполне мог добавить что-то своё.

$>crontab -l | grep -v ‘^#’

Независимо от того, выявила ли проверка попытки взлома, безопасности много не бывает. Поэтому вот – несколько советов по защите сервера.

Защита

Рекомендации по защите сервера, в основном, касаются отслеживания и блокирования подозрительной активности, а также регулярного обновления программного обеспечения.

▍Запрет входа root-пользователей по SSH

Для повышения уровня безопасности сервера стоит запретить вход root-пользователей по SSH.

$>sudo vi /etc/ssh/sshd_config
PermitRootLogin no

▍Автоматические обновления

Включите автоматические обновления безопасности с использованием пакета unattended-upgrades. Сначала его надо установить:

$>sudo apt-get install unattended-upgrades

Следующий шаг – настройка:

$>sudo dpkg-reconfigure -plow unattended-upgrades

Пакет можно вызвать и самостоятельно:

$>sudo unattended-upgrade

▍Настройка блокировок

Установите пакет fail2ban. Для того, чтобы блокировать с его помощью подозрительных SSH-пользователей, воспользуйтесь этим руководством, поле чего настройте систему отчётов.
Для того, чтобы узнать, сколько раз fail2ban заблокировал некий IP-адрес, воспользуйтесь такой командой:

$>sudo awk '($(NF-1) = /Ban/){print $NF}' /var/log/fail2ban.log | sort | uniq -c | sort –n

Для того, чтобы просмотреть весь файл журнала fail2ban, введите следующее:

$>sudo zgrep -h "Ban "/var/log/fail2ban.log* | awk '{print $NF}' | sort | uniq –c

Для поиска проблемных подсетей подойдёт такая команда:

$>sudo zgrep -h "Ban " /var/log/fail2ban.log* | awk '{print $NF}' | awk -F\. '{print $1"."$2"."}' | sort | uniq -c | sort -n | tail

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

Например, вот как заблокировать подключения к sshd-порту из подсети 221.229.*.*:

$>sudo iptables -I INPUT -p tcp -s 221.229.0.0/255.255.0.0 --dport ssh -j REJECT --reject-with tcp-reset

Для того, чтобы узнать о том, что именно было заблокировано правилами iptables, можно воспользоваться такой командой:

$>sudo iptables -vnL INPUT --line-numbers

Для того, чтобы правила iptables сохранялись после перезагрузки сервера, установите в Ubuntu пакет iptables-persistent.

$>sudo apt-get install iptables-persistent
$>cat /etc/iptables/rules.v4

Если вы отредактировали правила iptables, используйте такую команду:

$>sudo bash -c "iptables-save  > /etc/iptables/rules.v4"

Файл с правилами не рекомендуется править вручную, так как его формат важен для того, чтобы всё работало как надо.

plink -ssh адрес_SSH_сервера -C -N -l логин -pw пароль -D 127.0.0.1:8081

After for:

Browsers: в графу «Узел SOCKS» укажите адрес 127.0.0.1, порт 8081, поставьте галочку «SOCKS5»

Programs: FreeCap 

ssh -t root@server.ru "cd /dir ; bash"

link

/etc/ssh/sshd_config

and set log level:

LogLevel DEBUG3

Then try to authenticate, and when it fails, look for log file:

/var/log/secure

LogLevel is defined in /etc/ssh/sshd_config. The default log is/var/log/auth.log unless defined otherwise in sshd_config

It sounds like you are attempting to add a users key into root’s authorized_keys file instead of the users authorized_keys file.

Just to clarify:

roots key should be in /root/.ssh/authorized_keys

users key should be in /home/USERNAME/.ssh/authorized_keys

It is possible to store the keys in /etc/ssh as you suggested, but not in the way that you are doing it. This is generally done when the users home directory is encrypted. In order for this to work, you need to make sure the following is done:

# mkdir /etc/ssh/USERNAME
# chmod 755 /etc/ssh/USERNAME
# chown USERNAME /etc/ssh/USERNAME
# touch /etc/ssh/USERNAME/authorized_keys
# chmod 644 /etc/ssh/USERNAME/authorized_keys
# chown USERNAME /etc/ssh/USERNAME/authorized_keys
# cat /home/USERNAME/.ssh/authorized_keys > /etc/ssh/USERNAME/authorized_keys
# echo "AuthorizedKeysFile /etc/ssh/%u/authorized_keys" >> /etc/ssh/sshd_config

Note: You might want to actually edit /etc/ssh/sshd_config instead of just appending to the end, as it is possible that you already have an AuthorizedKeysFile set.