I have a user account configuration with ssh public/private key that works on multiple servers centos and rhel. One server (Server F) that is not working in centos 6.8. When i ssh into server f I get prompted for a password. I have verified the config and it all is good. I put sshd into debug mode on server f on port 2200. when I ssh into server f on port 2200 i drop into a shell with no password prompt. Port 22 on server f accepts other user logins all with a password. There are no iptables firewall rules on server f. I have dug through the logs and am not spotting any indications as to why I cant login without a password.
Any ideas?
So on your server F you have sshd listening on two ports, 22 and 2200. The latter works as intended, but the former doesn't. Any differences in the config?
I don't have any proposals, but two comments:
authorized_keys should be in the directory .ssh , not at the same level.
ssh is quite picky with permissions. In your dir listing, the . characters indicate files with a security context. You may want to try without.
Yes correct, I did not want to risk messing with port 22 and the sshd running on that port in case it stopped working I may not be able to log back in. So I set up a sshd on port 2200 for testing purposes. I did compare sshd config on another centos 6.8 server. Then i copied the good copy / gold copy of sshd from the cent 6.8 server that is accepting login from the same user with no issues. The new sshd config on server f did not fix this issue. This is a very strange problem.
[admin@server f ~]$ ls -Z .ssh/authorized_keys
-rw-------. admin admin unconfined_u:object_r:default_t:s0 .ssh/authorized_keys
Good Server
ls -Z .ssh/authorized_keys
-rw-------. admin admin unconfined_u:object_r:default_t:s0 .ssh/authorized_keys
Good Server selinux is set to SELINUX=permissive
Bad server selinux is set to SELINUX=enforcing
I just went and checked the current status of of server f for selinux and it shows
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: permissive
Policy version: 24
Policy from config file: targeted
It seems I would need to reboot this server to have its status changed to permissive
When you make sure you can login on the sshd port 2200 instance as fallback, you may play with the sshd on port 22 and possibly break it.
Just make sure that no changes are persistent. For example, use a different config file as a playground for your tests.
If it's an option to reboot, write a watchdog script that reboots the server with restored config - which happens automatically (e. g. if a certain file is older than x minutes)
Did you go down to debug2/debug3 loglevel?
...and running sessions are not terminated on sshd restarts. Just make sure some date flows back and forth, so it does not go stale and is terminated at the configured limits.But if you get in trouble, if you loose your ssh connection is away better be very very careful.
--- Post updated at 11:38 PM ---
And make sure your fallback sshd is not running in foreground and is connected to your ssh-session. Running the fallback sshd in a screen session is one better option.
I stopped sshd and edited sshd_config and moved from port 22 to port 2200. Started sshd and I was able to ssh into server F without entering a password. When I moved the port back to 22 I was prompted for a password again.
This is how I am running sshd for testing on port 2200 while running the system sshd on port 22. debug mode is 3 in this example
sudo /usr/sbin/sshd -ddd -p 2200
From the man page for sshd
-d Debug mode. The server sends verbose debug output to the system log, and does not put itself in the background. The server also will
not fork and will only process one connection. This option is only intended for debugging for the server. Multiple -d options
increase the debugging level. Maximum is 3.
...both exact commands you are using for the ok and the failed attempt
...post debug output debug2 loglevel for both attempts for the server side and the client side(for server use -ddd or LogLevel Debug2 in config, for client use -o LogLevel=Debug2
... your clients .ssh/config and /etc/ssh/ssh_config
Make sure to change sensitive data before posting.
Neo
I didnt specify a port number during my key creation. I have used this same key pair to successfully log in to 100s of servers.
RudiC
I am using the same user when I attempt to login. I have scheduled a reboot to put selinux into permissive mode.
I am wondering if this is related to a PAM issue, I am digging into the PAM modules now.
# This file is being maintained by Puppet.
# DO NOT EDIT
# $OpenBSD: sshd_config,v 1.73 2005/12/06 22:38:28 reyk Exp $
# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.
# This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin
# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.
#Port 22
#Port 2200
#Port 22
#Protocol 2,1
Protocol 2
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024
# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#SyslogFacility AUTH
LogLevel DEBUG3
#LogLevel INFO
# Authentication:
#LoginGraceTime 120
LoginGraceTime 120
#PermitRootLogin yes
PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
PasswordAuthentication yes
#PermitEmptyPasswords no
# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication yes
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPIAuthentication yes
#GSSAPICleanupCredentials yes
GSSAPICleanupCredentials yes
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication mechanism.
# Depending on your PAM configuration, this may bypass the setting of
# PasswordAuthentication, PermitEmptyPasswords, and
# "PermitRootLogin without-password". If you just want the PAM account and
# session checks to run without PAM authentication, then enable this but set
# ChallengeResponseAuthentication=no
#UsePAM no
#UsePAM yes
# Accept locale-related environment variables
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL
#AllowTcpForwarding yes
AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
ClientAliveInterval 0
#ClientAliveCountMax 3
#ShowPatchLevel no
#UseDNS yes
UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no
#ChrootDirectory none
# no default banner path
#Banner none
Banner none
#XAuthLocation /usr/bin/xauth
XAuthLocation /usr/bin/xauth
# override default of no subsystems
Subsystem sftp /usr/libexec/openssh/sftp-server
KerberosAuthentication no
PubkeyAuthentication yes
UsePAM yes
GSSAPIAuthentication yes
AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys