Invalid ssh identification string

Thread: SSH identification string

Thread Tools
Display

SSH identification string

Hi all,
I am encountering an odd problem. My auth.log is filled with these messages.

Throughout my searching of the forums and of google I have found nothing. Some people have said it is a possible DDOS attack although I doubt that because my logs are spammed with this message from the second I turn the server on after not being on for a few days. I recentally re-installed the server OS to get a clean slate (it is my dev server). Ubuntu 12.10 is installed on an old IBM Netvista I had lying around, SSH is not on port 22 and I am using RSA authentication for log in.

Any help is appriciated, thanks in advance
— D4rk0wl

Re: SSH identification string

According to this thread (http://ubuntuforums.org/showthread.php?t=1551004) the admin said the issue stopped once gnome-keyring had been updated.

Some things I would try: Make sure not other network services are running, things which might also try to monitor SSH to see if it is alive or not. Remove openssh from the server and monitor the network traffic to see if something is still trying to connect to to port 22.

Re: SSH identification string

I also saw that post I have not yet attempted to update the gnome-keyring, I will attempt that when I get home and post back the results. Although is Ubuntu server running Gnome Keyring without a GUI? The services I have running on the server are Apache, Samba, Subsonic (Music), and Webmin. I thought webmin might be the culprit because I know it adds a nice GUI front end. Although it is the same thing when I turn it off.
Another thing I might note is that I do not have SSH running on the deafult port. I did this in attempts to weed out the bots and kiddies. On my last setup I was successful.

Thanks in advance,
— D4rk0wl

Last edited by d4rk0wl; December 31st, 2012 at 04:31 AM .

Re: SSH identification string

So through trial and error I have discovered that it is in relation to the port I am running it on. If I set it to the deafult port I do not get these error messages anymore however when I change the port number that is when the error starts popping up.

I attempted to start the service with all other services disabled and that had no effect.

I know the sshd_config is for the server and ssh_config is for the client. I attempted to change the port in the client config to the same port and that had no effect.

Last edited by d4rk0wl; December 31st, 2012 at 04:30 AM .

Re: SSH identification string

Since all the entries reference 127.0.0.1 this is not happening from outside the server. Whoever suggested a DDOS attack either wasn’t paying sufficient attention to the logs you provided, or didn’t know what he or she was talking about.

If you ask for help, do not abandon your request. Please have the courtesy to check for responses and thank the people who helped you.

Re: SSH identification string

That is what I thought as well, although other people were saying it was possible for an attacker to spoof localhost. Which I didn’t think was possible.

As I said before, when I change the port back to 22 this message goes away and currentally port 22 is blocked by my firewall. It is only when I put the service on the alternate port that this message appears. Which is odd because on my old setup this was not an issue.

Читайте также:  Картридж для epson stylus 830

Re: SSH identification string

Perhap another benign process (network monitor, port scanner, netcat, etc) is connecting to your SSH port, leading sshd to request authentication. which of course never arrives.

Re: SSH identification string

Update:
So it seems another process was using the port I was attempting to run the SSH service on. I was running the service on port 9902 and I deiced to change it. After I changed the port to another random port those error messages seemingly stopped.

I don’t know why they were not there last time I ran the server on that port and now they were, but I would much rather change my firewall configuration around then chase a problem I have no idea about.

So I guess I can concider this one solved for now, thanks everbody!

Re: SSH identification string

Sorry to bump up one of my posts, but I found the real solution to the problem.

After I changed it to another port within a few days the same error started popping up. Through more trial and error I found the error started occuring after I changed my pcmonitor configuration. I feel so stupid now, I should of known the PC monitor would of been listening on the port I told it to Oh well, at least I now know my problem.
Regards,
— D4rk0wl

Last edited by d4rk0wl; January 4th, 2013 at 03:42 AM .

Источник

Аккуратнее с ssh

Вот один день посидел с внешним IP-адресом, и нате пожалуйста: индусы какие-то по ssh ломятся:

May 15 15:42:15 Notebook sshd[18851]: Did not receive identification string from 211.110.213.50
May 15 15:47:42 Notebook sshd[19169]: Invalid user admin from 211.110.213.50
May 15 15:47:45 Notebook sshd[19173]: Invalid user test from 211.110.213.50
May 15 15:47:48 Notebook sshd[19182]: Invalid user guest from 211.110.213.50
May 15 15:47:52 Notebook sshd[19186]: Invalid user webmaster from 211.110.213.50
May 15 15:47:55 Notebook sshd[19195]: Invalid user mysql from 211.110.213.50
May 15 15:48:02 Notebook sshd[19204]: Invalid user oracle from 211.110.213.50

May 15 15:50:11 Notebook sshd[19442]: Did not receive identification string from 211.110.213.50

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

Так что придумываем пароли позаковыристей 🙂

Re: Аккуратнее с ssh

Устрица, а логины без пароля признак ЯХВБР.

Re: Аккуратнее с ssh

Re: Аккуратнее с ssh

Это распространенное явление. Имеет смысл прикрыть от негодяев свой 22 правилами iptables.

Источник

sshd[PID]: Did not receive identification string from IP #112

Comments

Fusl commented Oct 10, 2015

When executing a deploy on one of my servers I can see this in the auth.log:

After 15:20:06 I can finally see ASYD successfully connecting to the host and doing something, it then stops again until 15:20:14, continues there, stops again until 15:20:50 and then finishes the rest of the deploy. Mind taking a look at this issue?

The text was updated successfully, but these errors were encountered:

Choms commented May 3, 2016

So I was looking at this issue and I can reproduce it, however is not clear what is causing it. According to the internet that usually means connectivity issues, but this is not the case as the connection works just fine (those 36 seconds must be a long running task). In any case, I noticed one of those pops for every command sent over the SSH connection.

I also saw a related issue in net-ssh/net-ssh#315 but I tried with the latest version of the gem (3.1.1) and it’s still happening. My bet is something underlying this gem.

Honestly I have no idea on how to solve this, as it seems it’s not a real issue neither affecting the normal functioning of ASYD but just spamming the logs with those lines.

PS: I changed the way ASYD interacts with the clients by SSH on the devel branch, now it opens a persistent connection for the whole deploy instead of a new connection for each line, so that should also help network-wise to avoid rate limiting and connection spam in the logs. Will do a major release this week (also supporting MacOSX and more)

Читайте также:  Bitdefender antivirus scanner linux

Источник

Thread: «Did not receive identification string» in auth.log

Thread Tools
Display

«Did not receive identification string» in auth.log

I noticed the above showing up in my /var/log/auth.log and was wondering if someone could explain what they mean. It’s from a local IP I use Putty to SSH in from, so I’m sure it’s not some sort of hack attempt, but I’m really not sure what it might be. Thanks for any help.

Re: «Did not receive identification string» in auth.log

1) Are you using public/private keys to secure your SSH connection?
2) Have you tried running PuTTY in verbose mode? That might give you more info about how PuTTY is attempting to authenticate.
3) The regularity of the timestamp series looks like a running service rather than a manual login attempt. Are you running anything else that might be attempting to access your server? Do the timestamps correlate to your logins via PuTTY, or do they appear even when you shut down that process?

Re: «Did not receive identification string» in auth.log

I am seeing almost the same thing. Every 30 secs I get a failed connection attempt. but for me it comes from ::1 (the IPv6 localhost address). I upgrades my sshd logging level to «DEBUG» and this is what I get:

I haven’t seen this before. I do have OpenVPN running. but I don’t think that matters. (And OpenVPN has nothing to do with sshd, so I’m stumped.)

I have bridged config set up with a br0 also. and I’m running Asterisk and FreePBX. (Just tossing out possible troublemakers here. )

It can’t be cron because cron only runs every minute (at the soonest). Hmm. maybe a looping gdm that won’t boot? Dunno.

This is on a 10.4 Virtual Machine running under KVM.

[EDIT]
Found it. This is a known issue with FreePBX. It polls port 22 for listening (as part of the FreePBX monitoring), resulting in the errors.

The FreePBX bug is not fixed and has been given low priority. *sigh*

Last edited by realloc; January 9th, 2011 at 06:41 AM . Reason: Found the culprit

Источник

Устранение неполадок SSH: ошибки аутентификации

В первой статье этой серии вы узнали о том, как и в каких ситуациях вы можете попробовать исправить ошибки SSH. Остальные статьи расскажут, как определить и устранить ошибки:

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

После установления соединения и инициирования протокола система может проверить подключение пользователя к системе. SSH поддерживает множество механизмов аутентификации. В этом руководстве рассмотрены два наиболее распространенных механизма: парольная аутентификация и аутентификация на основе SSH-ключей.

Требования

  • Убедитесь, что можете подключиться к виртуальному серверу через консоль.
  • Проверьте панель на предмет текущих проблем, влияющих на работу и состояние сервера и гипервизора.

Основные ошибки

Отказ в доступе (парольная аутентификация)

Примечание: Если вы настроили на сервере SSH-ключи и отключили PasswordAuthentication, сервер не поддерживает паролей. Используйте SSH-ключ, чтобы подключиться к серверу.

Клиенты PuTTY и OpenSSH выдают такое сообщение:

root@111.111.111.111’s password:
Permission denied (publickey,password).
PuTTY Error output
root@111.111.111.111’s password:
Access denied
Server sent disconnect message
type 2 (protocol error):
«Too many authentication failures for root»

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

  • Убедитесь, что вы используете правильное имя пользователя. В CoreOS используйте пользователя core. В FreeBSD используйте аккаунт пользователя freebsd.
  • Парольная аутентификация пользователя может быть нарушена. Проверьте, поддерживает ли парольную аутентификацию веб-консоль сервера. Если она не поддерживает пароли, вам придется попытаться сбросить пароль или обратиться за помощью к службе поддержки, чтобы восстановить доступ.
  • Убедитесь, что сервер поддерживает парольную аутентификацию.

Отказ в доступе (аутентификация на основе SSH-ключей)

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

Читайте также:

Читайте также:  Как прочистить головку принтера canon pixma g1411

Вы можете получить такую ошибку:

Permission denied (publickey).
PuTTY Error output
Disconnected: No supported authentication methods available (server sent: publickey)

Многие наиболее распространенные проблемы, связанные с аутентификацией на основе ключей, вызваны неправильными правами доступа к файлам или правами собственности. Чтобы устранить проблему, попробуйте сделать следующее:

  • Убедитесь, что файл authorized_keys и сам закрытый ключ имеют правильные права доступа и собственности.
  • Убедитесь, что сервер поддерживает аутентификацию на основе ключей SSH.
  • Убедитесь, что клиент SSH может получить закрытый ключ. Если вы используете PuTTY, убедитесь, что ключи SSH правильно настроены в сессии. Если вы используете OpenSSH, убедитесь, что у закрытого ключа SSH есть соответствующие привилегии.
  • Убедитесь, что файл authorized_keys содержит правильный открытый ключ, и что открытый ключ добавлен на сервер.
  • Возможно, вы используете закрытый ключ, который больше не поддерживается сервисом OpenSSH. Эта ошибка обычно затрагивает серверы OpenSSH 7+ при использовании закрытого DSA-ключа SSH. Обновите конфигурацию сервера.

Консоль не поддерживает пароли

Если вы не можете восстановить доступ к консоли, это может указывать на проблемы с файловой системой или конфигурацией в подсистеме PAM, которые влияют на механизм аутентификации. Эта ошибка также повлияет на попытки сбросить пароль root и войти в систему через консоль.

В консоли появляется форма аутентификации:

Ubuntu 14.04.4 LTS server tty1
server Login:
Password:

Но после ввода пароля появляется ошибка:

После сброса пароля вы получите:

You are required to change your password immediately (root enforced)
Changing password for root.
(Current) UNIX Password:

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

При успешном завершении вам будет предложено дважды ввести новый пароль:

Enter new UNIX password:
Retype new UNIX password:

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

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

Устранение неполадок

Проверка доступных методов аутентификации

Если вы используете подробный вывод или следите за логами SSH-клиента, убедитесь, что в сообщении, описывающем методы аутентификации, указаны password и/или publickey.

debug1: Authentications that can continue: publickey,password

Если вы не нашли в списке метод аутентификации, который хотите использовать, откройте файл /etc/ssh/sshd_config. В нём часто допускается ошибка: PasswordAuthentication имеет значение yes, а PermitRootLogin – no или without-password для пользователя root.

Исправьте эту ошибку, перезапустите сервис.

Настройка прав доступа и собственности

Сервер и клиент OpenSSH имеют строгие требования к привилегиям и правам собственности на файлы ключей.

Сервер и клиент OpenSSH должны иметь следующие права:

./ssh должен принадлежать текущему аккаунту.

/.ssh/authorized_keys должен принадлежать текущему аккаунту.

Кроме того, клиент должен также иметь такие права:

/ .ssh / config – 600.

Эти изменения можно внести с помощью консоли.

Проверка открытого и закрытого ключа

Если вы забыли, какой закрытый ключ соответствует тому или иному открытому ключу, инструменты OpenSSH и PuTTY помогут вам сгенерировать открытый ключ на основе зарытого ключа. Полученный результат вы можете сравнить с файлом

Чтобы восстановить открытый ключ на основе закрытого ключа в среде OpenSSH, используйте ssh-keygen и укажите путь к закрытому ключу.

/.ssh/id_rsa
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfBiMwCU1xoVVp0VbSYV3gTDV/jB57IHdILQ8kJ2622//Lmi4gDPlxA6HXVKq8odkGD/5MjqUw85X2rwEbhoBul74+LCToYJvvvBaDPCgg5z1icCKIJ1m/LJBrGNqPKCgqFWu0EH4/EFP2XIQqWqX1BZtJu/2YWrTr+xFOE/umoYmOd+t3dzQqMsv/2Aw+WmA/x/B9h+41WrobDgCExYNLPYcD0PO7fpsa8CcrZCo+TUWCe7MgQQCSM6WD4+PuYFpUWGw3ILTT51bOxoUhAo19U8B2QqxbMwZomzL1vIBhbUlbzyP/xgePTUhEXROTiTFx8W9yetDYLkfrQI8Q05+f

В среде PuTTY команда PuTTYgen.exe загружает интерфейс, в котором можно использовать опцию Load и импортировать закрытый ключ. PuTTY хранит такие файлы в формате .ppk (нужно знать место хранения файла).

Импортировав ключ, вы увидите окно с разделом Public key for pasting into OpenSSH authorized_keys file. В нём и будет искомый открытый ключ. Выделите текст и вставьте его в файл. Он сгенерирует открытый ключ.

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfBiMwCU1xoVVp0VbSYV3gTDV/jB57IHdILQ8kJ2622//Lmi4gDPlxA6HXVKq8odkGD/5MjqUw85X2rwEbhoBul74+LCToYJvvvBaDPCgg5z1icCKIJ1m/LJBrGNqPKCgqFWu0EH4/EFP2XIQqWqX1BZtJu/2YWrTr+xFOE/umoYmOd+t3dzQqMsv/2Aw+WmA/x/B9h+41WrobDgCExYNLPYcD0PO7fpsa8CcrZCo+TUWCe7MgQQCSM6WD4+PuYFpUWGw3ILTT51bOxoUhAo19U8B2QqxbMwZomzL1vIBhbUlbzyP/xgePTUhEXROTiTFx8W9yetDYLkfrQI8Q05+f imported-openssh-key

Можно проигнорировать комментарий после открытого ключа (imported-openssh-key).

В любом случае этот открытый ключ нужно добавить в файл

OpenSSH 7 и устаревшие ключевые алгоритмы

В системах с OpenSSH 7 (FreeBSD и CoreOS по умолчанию) старые ключи DSA не поддерживаются.

Ключи ssh-dss считаются слабыми, вместо них рекомендуют использовать более надёжные современные алгоритмы.

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

Однако в качестве обходного пути вы можете установить в PubkeyAcceptedKeyTypes значение +ssh-dss в файле /etc/ssh/sshd_config.

Заключение

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

Источник

Поделиться с друзьями
КомпСовет
Adblock
detector