Ask Your Question
0

Can't ssh (openssh) to localhost (fedora 20). No logs?

asked 2014-07-15 03:19:43 -0500

creftos gravatar image

updated 2014-09-30 06:52:58 -0500

mether gravatar image

I'm trying to just ssh from localhost on a fresh Fedora 20 install. No firewall issues because it's all local. I have ssh-keygen'd and added the id_rsa.pub to my authorized keys. (used default location, no passphrase) I've been messing around with this for the last couple days in my off time and can't seem to get it to work. I CAN log in via ssh if I use a password, but I want to use ssh keys. There are no logs in /var/log/secure like I've seen with CentOS in the past. There is some ssh info in /var/log/audit, but it doesn't really seem to give any information I can use to figure out why it's not working. Any ideas? Any help getting logging to work or getting sshd to accept my connection attempts would be greatly appreciated. Thanks in advance!

My sshd_config file is below:

#   $OpenBSD: sshd_config,v 1.90 2013/05/16 04:09:14 dtucker 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:/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 override the
# default value.

# If you want to change the port on a SELinux system, you have to tell
# SELinux about this change.
# semanage port -a -t ssh_port_t -p tcp #PORTNUMBER
#
# Port 22
AddressFamily any
ListenAddress 0.0.0.0
#ListenAddress ::

# The default requires explicit activation of protocol 1
Protocol 2

# 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
#HostKey /etc/ssh/ssh_host_ecdsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Ciphers and keying
#RekeyLimit default none

# Logging
# obsoletes QuietMode and FascistLogging
SyslogFacility AUTH
#SyslogFacility AUTHPRIV
LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

RSAAuthentication yes
PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile  .ssh/authorized_keys

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# 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
#PermitEmptyPasswords no
PasswordAuthentication no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
#KerberosUseKuserok yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPIAuthentication yes
#GSSAPICleanupCredentials yes
#GSSAPICleanupCredentials no
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# Set this to 'yes' to enable PAM authentication, account processing, 
# and session processing. If this is enabled, PAM ...
(more)
edit retag flag offensive close merge delete

Comments

1

Perhaps, SELinux? Try setenforce 0.

abadrinath gravatar imageabadrinath ( 2014-07-15 03:35:52 -0500 )edit
2

To see what happens use: ssh -v [host], it'll provide verbose output from the connection attempt, and you should be able to see what's gong wrong.

cobra gravatar imagecobra ( 2014-07-15 04:02:53 -0500 )edit

+1 great idea!

abadrinath gravatar imageabadrinath ( 2014-07-15 04:18:26 -0500 )edit

have you checked ownership (owned by you) and permissions of .ssh (should be 0700) and ssh/authorized_keys (should be 0600) ?

tonioc gravatar imagetonioc ( 2014-07-15 05:53:48 -0500 )edit

@hello After doing a setenforce 0, I now get an error in addition to public key denied: "Agent admitted failure to sign using the key. Permission denied (publickey)."

creftos gravatar imagecreftos ( 2014-07-15 10:47:11 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
1

answered 2014-07-15 14:37:18 -0500

So, the reason setenforce 0 allows the additional error you're receiving is probably that the SELinux context of your key is incorrect. If that is the case, it will prevent your SSH Agent from seeing and/or accessing the key file, which is why you're not getting more detailed logging messages when SELinux is enabled.

To resolve the matter, execute ls -Z against your file and ensure the SELinux context is unconfined_u:object_r:ssh_home_t:s0. If it is not correct, fix it! (Ask if you need help, but you should be able to simply run restorecon ~/.ssh to fix it if necessary).

Once the key file's SELinux context is correct, you need to add the private key identity to your SSH authentication agent. Since your key file bears a default name (id_rsa) - just execute ssh-add and, assuming that command succeeds, try connecting again.

edit flag offensive delete link more

Comments

Awesome. That fixed my problem! for some reason it was set as unconfined_u:object_r:home_root_t:s0 instead of ssh_home_t. I had to use chcon because restorecon didn't work for some reason. Maybe because my user is an administrative user? Thanks!

creftos gravatar imagecreftos ( 2014-07-17 00:17:20 -0500 )edit

Ah, well the issue is that you have your key in the root user's home directory, so if you restore the context to the configured defaults, it will restore the context you listed. You probably shouldn't be using SSH to connect to a system as the root user, but if you're just messing around with an unimportant home system, it's not a HUGE deal. It'd probably be worth your while to configure your system so that you can do what you need to do as a standard user, though.

Glad I could help!

bitwiseoperator gravatar imagebitwiseoperator ( 2014-07-17 16:01:33 -0500 )edit

Question Tools

1 follower

Stats

Asked: 2014-07-15 03:19:43 -0500

Seen: 3,008 times

Last updated: Jul 15 '14