Thanks a lot for replying. Here are some updates.
I added debug to pam_google_authenticator and this was the debug output
Dec 11 19:55:55 62763fb62f43 sshd[25706]: debug1: sshd version OpenSSH_7.2, OpenSSL 1.0.2g 1 Mar 2016
Dec 11 19:55:55 62763fb62f43 sshd[25706]: debug1: private host key #0: [redacted]
Dec 11 19:55:55 62763fb62f43 sshd[25706]: debug1: private host key #1: [redacted]
Dec 11 19:55:55 62763fb62f43 sshd[25706]: debug1: private host key #2: [redacted]
Dec 11 19:55:55 62763fb62f43 sshd[25706]: debug1: private host key #3: [redacted]
Dec 11 19:55:55 62763fb62f43 sshd(pam_google_authenticator)[25708]: debug: start of google_authenticator for "root"
Dec 11 19:55:55 62763fb62f43 sshd(pam_google_authenticator)[25708]: debug: Secret file permissions are 0600. Allowed permissions are 0600
Dec 11 19:55:55 62763fb62f43 sshd(pam_google_authenticator)[25708]: debug: "/root/.google_authenticator" read
Dec 11 19:55:55 62763fb62f43 sshd(pam_google_authenticator)[25708]: debug: shared secret in "/root/.google_authenticator" processed
Dec 11 19:55:55 62763fb62f43 sshd(pam_google_authenticator)[25708]: debug: google_authenticator for host "xxx.xx.x.x"
Dec 11 19:56:04 62763fb62f43 sshd(pam_google_authenticator)[25708]: Dummy password supplied by PAM. Did OpenSSH 'PermitRootLogin <anything but yes>' or some other config block this login?
Dec 11 19:56:04 62763fb62f43 sshd(pam_google_authenticator)[25708]: Dummy password supplied by PAM. Did OpenSSH 'PermitRootLogin <anything but yes>' or some other config block this login?
Dec 11 19:56:04 62763fb62f43 sshd(pam_google_authenticator)[25708]: Invalid verification code for root
Dec 11 19:56:04 62763fb62f43 sshd(pam_google_authenticator)[25708]: debug: end of google_authenticator for "root". Result: Authentication failure
So it seemed like the verification token was incorrect. This was surprising since I had enabled the 4 minute intervals and verified the qr code matched the secret by entering both of them in my GA app. These lines caught my attention:
Dec 11 19:56:04 62763fb62f43 sshd(pam_google_authenticator)[25708]: Dummy password supplied by PAM. Did OpenSSH 'PermitRootLogin <anything but yes>' or some other config block this login?
Dec 11 19:56:04 62763fb62f43 sshd(pam_google_authenticator)[25708]: Dummy password supplied by PAM. Did OpenSSH 'PermitRootLogin <anything but yes>' or some other config block this login?
So I opened /etc/ssh/sshd and changed PermitRootLogin prohibit-password to PermitRootLogin yes
After that, I got the following debug logs
Dec 11 20:18:11 62763fb62f43 sshd(pam_google_authenticator)[25729]: debug: start of google_authenticator for "root"
Dec 11 20:18:11 62763fb62f43 sshd(pam_google_authenticator)[25729]: debug: Secret file permissions are 0600. Allowed permissions are 0600
Dec 11 20:18:11 62763fb62f43 sshd(pam_google_authenticator)[25729]: debug: "/root/.google_authenticator" read
Dec 11 20:18:11 62763fb62f43 sshd(pam_google_authenticator)[25729]: debug: shared secret in "/root/.google_authenticator" processed
Dec 11 20:18:11 62763fb62f43 sshd(pam_google_authenticator)[25729]: debug: google_authenticator for host "xxx.xx.x.x"
Dec 11 20:18:21 62763fb62f43 sshd(pam_google_authenticator)[25729]: debug: no scratch code used from "/root/.google_authenticator"
Dec 11 20:18:21 62763fb62f43 sshd(pam_google_authenticator)[25729]: Accepted google_authenticator for root
Dec 11 20:18:21 62763fb62f43 sshd(pam_google_authenticator)[25729]: debug: end of google_authenticator for "root". Result: Success
I was then able to ssh in successfully. For posterity, here is my /etc/pam.d/sshd file
# PAM configuration for the Secure Shell service
# Standard Un*x authentication.
auth required pam_google_authenticator.so debug
# @include common-auth
# Disallow non-root logins when /etc/nologin exists.
account required pam_nologin.so
# Uncomment and edit /etc/security/access.conf if you need to set complex
# access limits that are hard to express in sshd_config.
# account required pam_access.so
# Standard Un*x authorization.
@include common-account
# SELinux needs to be the first session rule. This ensures that any
# lingering context has been cleared. Without this it is possible that a
# module could execute code in the wrong domain.
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
# Set the loginuid process attribute.
session required pam_loginuid.so
# Create a new session keyring.
session optional pam_keyinit.so force revoke
# Standard Un*x session setup and teardown.
@include common-session
# Print the message of the day upon successful login.
# This includes a dynamically generated part from /run/motd.dynamic
# and a static (admin-editable) part from /etc/motd.
session optional pam_motd.so motd=/run/motd.dynamic
session optional pam_motd.so noupdate
# Print the status of the user's mailbox upon successful login.
session optional pam_mail.so standard noenv # [1]
# Set up user limits from /etc/security/limits.conf.
session required pam_limits.so
# Read environment variables from /etc/environment and
# /etc/security/pam_env.conf.
session required pam_env.so # [1]
# In Debian 4.0 (etch), locale-related environment variables were moved to
# /etc/default/locale, so read that as well.
session required pam_env.so user_readenv=1 envfile=/etc/default/locale
# SELinux needs to intervene at login time to ensure that the process starts
# in the proper default security context. Only sessions which are intended
# to run in the user's context should be run after this.
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
# Standard Un*x password updating.
# @include common-password
The only changes I have made are to comment out common-auth and common-password and add auth required pam_google_authenticator.so debug
Thanks for the help 
AlexNT писал(а): ↑
08.07.2009 21:22
ivan2ksusr писал(а): ↑
08.07.2009 15:39
AlexNT писал(а): ↑
07.07.2009 19:42
bartram писал(а): ↑
07.07.2009 17:41
*Sasha* писал(а): ↑
07.07.2009 17:23
bartram писал(а): ↑
07.07.2009 17:10
sshd[892]: error: PAM: authentication error for root from 192.168.0.100
sshd[892]: error: PAM: authentication error for root from 192.168.0.100а в конфиге ssh разрешено рутом заходить?
да. Раньше заходил
Судя по всему произошла потеря файла sshd_config, т.е. он обнулился (по причине внезапной перезагрузки) и разрешение заходить руту более не действует.
Кстати разрешать заход рутом по ssh это несколько небезопасно и повышает риск взлома системы…по поводу конфига полный бред, если бы слетел конфиг или как вы выразились обнулился(как это я вообще не представляю)то вообще ни кто не смог зайти, дело заключается в модуле pam который может быть блокирнул учетку рута
Вы уважаемый ivan2ksusr этими словами «по поводу конфига полный бред» демонстрируете лишь, как бы это сказать…
В общем вот вам скриншот если не верите. Обнулил sshd_config, запустил sshd — все прекрасно работает.Рута не пускает конечно же.
Можете попробовать самостоятельно произвести сей примитивный эксперимент.При сбое по питанию иногда возникает ситуация обнуления открытого на запись файла…
Я всего лишь предположил что потерян sshd_config и никакого «бреда» как Вы выразились я в этом не вижу.В логе сервера куда мы долбимся рутом, пишется именно вот это:
Jul 8 23:13:25 CRAZY1 sshd[3746]: error: PAM: authentication error for root from 200.100.0.7
FreeBSD g1.vifiteh 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 14:37:25 UTC 2009 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386
сделал бекап конфига и обнулил конфиг
total 142
-rw-r—r— 1 root wheel 125811 1 ??? 2009 moduli
-rw-r—r— 1 root wheel 1610 1 ??? 2009 ssh_config
-rw——- 1 root wheel 668 25 ??? 14:21 ssh_host_dsa_key
-rw-r—r— 1 root wheel 605 25 ??? 14:21 ssh_host_dsa_key.pub
-rw——- 1 root wheel 530 25 ??? 14:21 ssh_host_key
-rw-r—r— 1 root wheel 334 25 ??? 14:21 ssh_host_key.pub
-rw——- 1 root wheel 1675 25 ??? 14:21 ssh_host_rsa_key
-rw-r—r— 1 root wheel 397 25 ??? 14:21 ssh_host_rsa_key.pub
-rw-r—r— 1 root wheel 0 9 ??? 12:20 sshd_config
-rw-r—r— 1 root wheel 3492 9 ??? 12:19 sshd_config.backup
Далее
делаю рестарт sshd демона
пытаемся залогинится:
mbp-nbbv:~ nb-bv$ ssh anton@192.168.0.202
далее зависон и больше ни чего)
далее делаем обратную операцию:
и получаем:
mbp-nbbv:~ nb-bv$ ssh anton@192.168.0.202
Password:
Last login: Wed Jul 8 18:43:31 2009 from 192.168.0.220
Copyright © 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 7.1-RELEASE (GENERIC) #0: Thu Jan 1 14:37:25 UTC 2009
Welcome to FreeBSD!
Before seeking technical support, please use the following resources:
o Security advisories and updated errata information for all releases are
at http://www.FreeBSD.org/releases/ — always consult the ERRATA section
for your release first as it’s updated frequently.
o The Handbook and FAQ documents are at http://www.FreeBSD.org/ and,
along with the mailing lists, can be searched by going to
http://www.FreeBSD.org/search/. If the doc distribution has
been installed, they’re also available formatted in /usr/share/doc.
If you still have a question or problem, please take the output of
`uname -a’, along with any relevant error messages, and email it
as a question to the questions@FreeBSD.org mailing list. If you are
unfamiliar with FreeBSD’s directory layout, please refer to the hier(7)
manual page. If you are not familiar with manual pages, type `man man’.
You may also use sysinstall(8) to re-enter the installation and
configuration utility. Edit /etc/motd to change this login announcement.
%
В общем итоге при 0м конфиге как в вашем случае у меня ни чего не вышло, может быть я не так что делаю. А автор топика молодец, разобрался в чем дело, но и я так же был прав, когда еще написал то что перекалечило конфиг) В общем как говорится «век живи век учись»
Skip to navigation
Skip to main content
Infrastructure and Management
- Red Hat Enterprise Linux
- Red Hat Virtualization
- Red Hat Identity Management
- Red Hat Directory Server
- Red Hat Certificate System
- Red Hat Satellite
- Red Hat Subscription Management
-
Red Hat Update Infrastructure
- Red Hat Insights
- Red Hat Ansible Automation Platform
Cloud Computing
- Red Hat OpenShift
- Red Hat CloudForms
- Red Hat OpenStack Platform
- Red Hat OpenShift Container Platform
- Red Hat OpenShift Data Science
- Red Hat OpenShift Online
- Red Hat OpenShift Dedicated
- Red Hat Advanced Cluster Security for Kubernetes
-
Red Hat Advanced Cluster Management for Kubernetes
- Red Hat Quay
- OpenShift Dev Spaces
- Red Hat OpenShift Service on AWS
Storage
- Red Hat Gluster Storage
- Red Hat Hyperconverged Infrastructure
- Red Hat Ceph Storage
- Red Hat OpenShift Data Foundation
Runtimes
- Red Hat Runtimes
- Red Hat JBoss Enterprise Application Platform
-
Red Hat Data Grid
- Red Hat JBoss Web Server
- Red Hat Single Sign On
- Red Hat support for Spring Boot
- Red Hat build of Node.js
- Red Hat build of Thorntail
- Red Hat build of Eclipse Vert.x
-
Red Hat build of OpenJDK
- Red Hat build of Quarkus
Integration and Automation
- Red Hat Process Automation
- Red Hat Process Automation Manager
- Red Hat Decision Manager
All Products
Issue
Root is unable to login and following is logged in /var/log/secure
Sep 6 11:20:33 ieavu27 sshd[7802]: Connection from 10.68.132.21 port 53817 on 10.68.26.207 port 22
Sep 6 11:20:41 ieavu27 sshd[7802]: reverse mapping checking getaddrinfo for l007111.iehibdom.com [10.68.132.21] failed - POSSIBLE BREAK-IN ATTEMPT!
Sep 6 11:20:41 ieavu27 sshd[7802]: Postponed keyboard-interactive for root from 10.68.132.21 port 53817 ssh2 [preauth]
Sep 6 11:20:48 ieavu27 sshd[7802]: error: PAM: Authentication failure for root from 10.68.132.21
Sep 6 11:20:48 ieavu27 sshd[7802]: Failed keyboard-interactive/pam for root from 10.68.132.21 port 53817 ssh2
Sep 6 11:20:48 ieavu27 sshd[7802]: Postponed keyboard-interactive for root from 10.68.132.21 port 53817 ssh2 [preauth]
Environment
- Red Hat Enterprise Linux 7.x
- PAM
- SSHD
Subscriber exclusive content
A Red Hat subscription provides unlimited access to our knowledgebase, tools, and much more.
Current Customers and Partners
Log in for full access
Log In
-
#1
Can anyone explain to me why I’m finding this error messages on my server every day, and how can I get rid of this? please.
Example 1:
Code:
Jun 4 00:46:46 shell sshd[17263]: error: PAM: authentication error for root from 219.138.135.63
Jun 4 00:46:48 shell sshd[17294]: error: PAM: authentication error for root from 219.138.135.63
Example 2:
Code:
login: Jun 4 21:38:41 shell sshd[20901]: error: PAM: authentication error for illegal user admin from 23.97.212.138
Jun 4 21:38:41 shell sshd[20901]: error: Received disconnected from 23.97.212.138: 3: com.jcraft.jsch.JSchExeption: Auth cancel [preauth]
Jun 4 22:35:48 shell sshd[21022]: fatal: Read from socket failed: Connection reset by peer [preauth]
Example 3:
Code:
Jun 12 15:13:26 shell sshd[68139]: error: PAM: authentication error for illegal user genoveba from host188-177-static.4-79-b.business.telecomitalia.it
Jun 12 15:13:39 shell sshd[68142]: error: PAM: authentication error for illegal user amanda from host188-177-static.4-79-b.business.telecomitalia.it
Jun 12 15:13:45 shell sshd[68145]: error: PAM: authentication error for illegal user dark from host188-177-static.4-79-b.business.telecomitalia.it
I have FreeBSD 9.2
Thank you!
-
#2
Re: Error messages
People, or rather, bots, are trying to log in to your server by guessing account names. Please make sure that root login by sshd() is not allowed, and it is recommended to only allow login with an SSH key instead of passwords. Many people run
security/sshguard
to limit these attacks.
-
Thread Starter
-
#3
Last edited by a moderator: Oct 16, 2014
-
#4
Re: Error messages
In
/etc/ssh/sshd_config
, everything that is commented by default reflects the default settings. You don’t need to uncomment this below because it already is disabled.
Enabling SSH Key login only however you do have to enable and is probably a must for any box open to the Internet.
-
Thread Starter
-
#5
Re: Error messages
Splendid, Thank you!
-
#6
Hello,
I have a noob followup question … I saw these messages on a newly setup freeBSD11 box behind a commercial SOHO home router, e.g. Linksys, Dlink, etc… Does this mean my private network is comprised?? How else do they formulate such login attempts? Those source IPs are routable public IP, and, my sshd is not sitting on any public interface and there is no any forwarding with this box yet. Do I misread any thing? Thanks
-
#8
Thanks for the swift reply.
I accidentally used an IP, which was DMZed a long time ago, but wasn’t turned off… that is a big mystery solved ( phew )
