Solved

can't use public/private keys to get in through SSH

Posted on 2011-03-15
26
1,656 Views
Last Modified: 2012-05-11
I just made a new box and I have enabled the public/private key setup that we have on all of our other boxes. This runs a .pl script to log you in with root privs, but all the command history and everything else comes through under your own user account.

With this one box however, it won't connect and I get: Disconnected: no supported authentication methods available.

I have the same files as other boxes using this setup, the permissions on all files and ssh directory are the same, the authorized keys file is the same, and I've been through every article on Google about this.

Also, when going from another server using: ssh -v -p(port number) servername.domain.com
I get:

debug1: Host 'servername.domain.com' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:17
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Offering public key: /root/.ssh/id_dsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic)

Does anyone have anything I can try here to get this working like the other boxes...
0
Comment
Question by:willlandymore
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 12
  • 9
  • 5
26 Comments
 
LVL 31

Expert Comment

by:farzanj
ID: 35138213
Which keys are you using, DSA or RSA?

What are the permissions of your .ssh folders?

What are the permissions of your key files?

ls -ld .ssh
ls -l .ssh
0
 
LVL 1

Author Comment

by:willlandymore
ID: 35138240
RSA keys

drwx------. 2 root root 4096 Mar 14 23:31 /root/.ssh
-rw-------. 1 root root 4472 Jan 28 06:44 authorized_keys
0
 
LVL 31

Expert Comment

by:farzanj
ID: 35138309
I suppose that you already have:
~/.ssh/id_rsa key on the Source Machine <-- PRIVATE KEY
And
~/.ssh/authorized_keys contains the counter part public key.


Just a quick test:  I am doing this because after many such troubleshootings, I sometimes found this silly thing.

Try dsa keys

ssh-keygen -t dsa

Copy the public key to the ~/.ssh/authorized_keys and see if that would make it work.
0
Enterprise Mobility and BYOD For Dummies

Like “For Dummies” books, you can read this in whatever order you choose and learn about mobility and BYOD; and how to put a competitive mobile infrastructure in place. Developed for SMBs and large enterprises alike, you will find helpful use cases, planning, and implementation.

 
LVL 1

Author Comment

by:willlandymore
ID: 35138397
I can do that, but because these keys are just copied from one box to another (and they're all working on the other boxes) I don't believe the keys are actually the problem here.

This system is working on 45 other servers and all the files were copied directly to this one. I even rebuilt the server yesterday to make sure I didn't botch something with the install....
0
 
LVL 31

Expert Comment

by:farzanj
ID: 35138513
Can you log on at all if you enter your password?

If not, you may want to check your TCP wrappers.

Your IP address or hostname should be in
/etc/hosts.allow

Make sure there is no firewall (IP tables entry) blocking it

iptables -F  (on both hosts).

service iptables stop

What kind of Linux is it?
0
 
LVL 78

Expert Comment

by:arnold
ID: 35138539
Do the other 45 systems have the same version as the one that does not ?
It looks as though the attempt is for a DSA key match
the DSA and RSA .pub belong in authorized_keys2 for SSH v2.
The other issue to check is whether this server is configured to allow Root logins.
/etc/ssh/sshd_config
PermitRootLogin yes

http://ubuntuforums.org/showthread.php?t=1314425
Check /var/log/messages to make sure selinux is not the one blocking the login.
0
 
LVL 1

Author Comment

by:willlandymore
ID: 35138749
we have a script running where you are putting in root, but it's actually logging in as you.

This system is RHEL6 and the other ones are a mixture of RHEL4, 5, 6.

The setup is identical on all boxes and I have even re-written the sshd_conf file in case there was some problem with the copy that messed it up. However, always the same outcome.
0
 
LVL 31

Expert Comment

by:farzanj
ID: 35138787
Did you try checking

iptables -F
service iptables stop

vi /etc/hosts.allow
sshd : <IP-ADDR>
0
 
LVL 78

Expert Comment

by:arnold
ID: 35138995
Overwriting a configuration where you have different version is a rather poor approach.
Can you check the server's /var/log/messages /var/log/secure /var/log/audit/audit.log for information that might explain the issue.
try ssh -1

Try a more verbose log for ssh using the -vvv
See which protocol it is connecting with. make sure that the "user" that is presented actually has the id_dsa id_rsa and identity keys in their .ssh directory.

Look at the authorized_keys to make sure there are no extraneous characters there
cat -v authorized_keys
Were these authorized keys copied/scped?  
0
 
LVL 31

Expert Comment

by:farzanj
ID: 35139046
He already said, it is access denied.  I don't think you need any more information before you would check what is blocking the authorization.  Am I write Arnold?
0
 
LVL 1

Author Comment

by:willlandymore
ID: 35139081
iptables is stopped and you can tell that there is no problem with connecting because you go in through putting and it will say "login as:". So it's making the connection but as soon as you put in the username it's trashes it.
0
 
LVL 78

Expert Comment

by:arnold
ID: 35139220
farzani, the checks you suggest are not an issue given the ssh connection is establish which knocks out the iptables issue.
The ssh daemon goes through the checks which knocks out the hosts.deny/hosts.allow rules if existed the sshd daemon would have dropped the connection without the added processing reflected in the verbose log.

The configuration you copied over the one included might be incomplete/incompatible.
run in sequence:
grep openssh /var/log/rpm
locate the -server
rpm --verify openssh-server
this will tell you which files are out of whack.
Do you have another RHEL 6 from which you can copy the configuration?

Is the only type of access to this system is via console?
0
 
LVL 1

Author Comment

by:willlandymore
ID: 35139228
Also, it's not overwriting with a different version. I just said we had 4,5, and 6 boxes. But I was taking the configuration from the 6 box and putting it on another 6 box. Same version, same everything.

The keys were copied in the same way that they always are from another working system. I have checked on the spaces before and there was nothing. I also tried removing the call to the .pl file we have that is being run from the authorized keys file and just using the key, but that was no go.

I have checked the /var/log/messages and secure and the only things I could find were:

Mar 15 09:57:22 server sshd[14828]: Server listening on server.domain.com port 22.
Mar 15 09:57:24 server sshd[14828]: Received signal 15; terminating.
Mar 15 09:57:25 server sshd[14846]: Server listening on server.domain.com port 22.
Mar 15 09:57:35 server sshd[14849]: Received disconnect from client_machine: 14: No supported authentication methods available

type=USER_END msg=audit(1300203001.939:49316): user pid=14935 uid=0 auid=0 ses=103 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:session_close acct="root" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success'

from another server with -vvv
==============================
debug2: we sent a gssapi-with-mic packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug3: no such identity: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug3: no such identity: /root/.ssh/id_rsa
debug1: Offering public key: /root/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic)
0
 
LVL 1

Author Comment

by:willlandymore
ID: 35139271
yeah, I copied the files from another (working) RHEL6 box and then made sure the permissions were identical. The only thing I changed was the listening address in the sshd_conf file.

I can also access the system through the VM console...

rpm --verify openssh-server
S.5....T.  c /etc/ssh/sshd_config

and there is no rpm directory on that box....
0
 
LVL 78

Expert Comment

by:arnold
ID: 35139528
sshd_config is the only one who has changed from the install.

What is issuing a restart?
Mar 15 09:57:24 server sshd[14828]: Received signal 15; terminating.
Do you have a monitor of the system that is incorrectly configure and keeps resetting SSHD?
0
 
LVL 1

Author Comment

by:willlandymore
ID: 35139557
no, that would have been me after I made a change attempting to fix this and then restarted the sshd.

I actually deleted the sshd_config file and then copied the text right from the file on the working RHEL6 box too and that was the same thing.

Just totally stumped here about how I can have an identical configuration on another identical OS and it's not working on one of them.
0
 
LVL 78

Expert Comment

by:arnold
ID: 35139695
Could you double check the authorized_keys files in the root user's shell?
try ssh -2 -vvv
Did you also copy the server keys from one system to the other?
Try this, delete the keys in /etc/ssh/ssh_host*
The start script will regenerate new ones on start. /etc/init.d/sshd

there is a way using ssh -2 -4
-2 sets SSH protocol version2
-4 tells it to use IPv4 connection method.

Could you check the state of the system when the connection is being made since this is a VM, might it lack the resources to setup an SSH session?
0
 
LVL 1

Author Comment

by:willlandymore
ID: 35139888
the VM that this is on is even more powerful than the other one that is working so I don't 'think' that would be an issue....

same results with the -2

I copied the server keys from the working RHEL6 box and then I also made a new file and took them out of the working one and put them into the new server.

Deleted the keys and then regenerated them but still nothing....although it was nice to see a difference now when it warned me about the key being different. :)

0
 
LVL 78

Expert Comment

by:arnold
ID: 35143040
Server keys are unique to the server and should not be copied.
Presumably you deleted this server's entry from your known_hosts files.

Could you make sure that your id_rsa.pub and your id_dsa.pub are are added into authorized_keys2 and see whether that makes a difference. Also comment out the GSS* options or disable them GSS<parameter> no
And see if that makes a difference.
The ssh connection should fall through and prompt for the password, but in your case given you are getting a deny, you may have the setup that prevents root login.

Create another user on the system and copy the authorized_keys* into its home dir/.ssh and see if ssh -vvv <newuser>@remoteserver -p <port> has issues as well.
0
 
LVL 1

Author Comment

by:willlandymore
ID: 35144283
sorry, when I said server keys I was actually meaning the user keys from the authorized_keys file...just to say that there was no way that the keys were wrong because they had been taken from a working box.
0
 
LVL 78

Expert Comment

by:arnold
ID: 35147403
are you able while logged into the VM console, ssh -vvvv root@localhost
Are you able to get a session?
You may have other issues that is causing difficulties.
0
 
LVL 1

Author Comment

by:willlandymore
ID: 35148539
same deal where it says:

permission denied (publickey, .....)
0
 
LVL 78

Expert Comment

by:arnold
ID: 35149192
check your /etc/nsswitch.conf passwd file?
check your /etc/pam.d/system-auth*
run system-config-authentication you may have omitted/locked out remote access
0
 
LVL 1

Author Comment

by:willlandymore
ID: 35149286
[root@server home]# system-config-authentication
Traceback (most recent call last):
  File "/usr/sbin/system-config-authentication", line 27, in <module>
    import msgarea
  File "/usr/share/authconfig/msgarea.py", line 19, in <module>
    import gtk, gobject
  File "/usr/lib/python2.6/site-packages/gtk-2.0/gtk/__init__.py", line 64, in <module>
    _init()
  File "/usr/lib/python2.6/site-packages/gtk-2.0/gtk/__init__.py", line 52, in _init
    _gtk.init_check()
RuntimeError: could not open display
0
 
LVL 78

Accepted Solution

by:
arnold earned 500 total points
ID: 35149750
compare the /etc/pam.d/system-auth* on this system to one that works. Similarly for nsswitch.conf.
double check the openssh version on each of the 6s to see if they are the same.

You could use strace -f -p <pid of sshd daemon> in one shell,
then using another attempt the ssh connection and see what it was doing prior to the failure.
 disable selinux if you have it enabled and see if that resolves the issue. i.e. you have an selinux policy that is interferring.
0
 
LVL 1

Author Comment

by:willlandymore
ID: 35151140
oh man, it was SELinux.

Once I got that sorted out and rebooted it connected right away.

Man, kudos for sticking with this. :)

Thanks.
0

Featured Post

The Orion Papers

Are you interested in becoming an AWS Certified Solutions Architect?

Discover a new interactive way of training for the exam.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

BIND is the most widely used Name Server. A Name Server is the one that translates a site name to it's IP address. There is a new bug in BIND (https://kb.isc.org/article/AA-01272), affecting all versions of BIND 9 from BIND 9.1.0 (inclusive) thro…
The purpose of this article is to demonstrate how we can use conditional statements using Python.
Learn how to get help with Linux/Unix bash shell commands. Use help to read help documents for built in bash shell commands.: Use man to interface with the online reference manuals for shell commands.: Use man to search man pages for unknown command…
Learn how to find files with the shell using the find and locate commands. Use locate to find a needle in a haystack.: With locate, check if the file still exists.: Use find to get the actual location of the file.:

724 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question