Fedora 10: SSH dsa keys not working.

ESC201 · 01-24-2009, 07:21 PM

Hey guys, I'm working on setting up an automated rsync script but for the life of me, I can't get the ssh keys to work. I followed this guide multiple times but to no avail. I don't have an error message or anything to post; just that it's not working. When I try to SSH in it goes straight to asking for me a password but with the verbose flag enabled ssh says that it tries my key first then falls back to a password. My distro is Fedora 10 if it makes a difference. (on both systems) Is there something that is common to overlook or to forget? Any help is awesome because this is becoming very frustrating. Thanks.

kenneho · 01-25-2009, 03:35 AM

Hi.

Maybe you could give us a short walkthrough of what you have done, so that we more easily can help you see where things are going wrong?

Regards,
kenneho

ESC201 · 01-25-2009, 08:33 AM

Basically, I do this...

Code:

(On the local machine)
ssh-keygen -t dsa
scp ~/.ssh/id_dsa.pub user@remotehost:~

(now through ssh on remote machine)
mkdir .ssh
chmod 700 .ssh
mv id_dsa.pub .ssh/
touch .ssh/authorized_keys
chmod 600 .ssh/authorized_keys
cat .ssh/id_dsa.pub >> .ssh/authorized_keys

Then I restart sshd on both systems and on the local machine I try to ssh in to my remote system using "ssh -i id_dsa.pub user@remotehost" (Of course replace user and such with the real info).

One thing I have noticed is that in the key that is generated, at the end it uses my computer's name but I connect to my other computers using their ip's. Could this be a problem?

Also, I've uncommented the location of the authorized_keys files in my sshd.conf files on both systems.

kenneho · 01-25-2009, 11:48 AM

I'm not an SSH expert, but this seems about right.

But try this: (Optionally, delete all SSH-related files on the remote server). Then SSH into the remote server, this should create the SSH files you need (at least the authorized keys file). Log out. Next, copy the public key the the remote computer. Does this help?

Note that when using SSH keys, and if you don't have a SSH agent running, you'll need to type in the SSH key password once per session. You're sure this is not the password you were promted for before?

Btw, why have you uncommented the location of the authorized_keys files in the sshd.conf files on both systems?

ESC201 · 01-25-2009, 06:56 PM

I removed the .ssh directories on both machines and did everything again and still nothing. I am asked for my password everytime I connect despite successfully logging in previously. I also tried using rsa instead of dsa.

I was looking through my config files to see if I needed to change something and I saw that a line with the authorized keys file was commented so maybe it wasn't seeing the file. I re-commented it and nothing changed however.

anomie · 01-25-2009, 07:09 PM

On the sshd server side, post the results of: ls -ld ~

With strict modes (enabled by default), no one but the owner can have write permissions to the home directory.

ESC201 · 01-25-2009, 09:28 PM

I'm not sure which system you want the output for (I assume the remote but here's both anyway).

Remote...

Code:

drwxrwx--- 53 Shane Shane 4096 2009-01-25 21:53 /home/Shane

Local...

Code:

drwxrwx--- 59 Shane Shane 12288 2009-01-25 20:28 /home/Shane

jschiwal · 01-25-2009, 09:42 PM

Code:

(On the local machine)
ssh-keygen -t dsa
scp ~/.ssh/id_dsa.pub user@remotehost:~

(now through ssh on remote machine)
mkdir .ssh
chmod 700 .ssh
mv id_dsa.pub .ssh/
touch .ssh/authorized_keys
chmod 600 .ssh/authorized_keys
cat .ssh/id_dsa.pub >> .ssh/authorized_keys

Here you are making the public key on the remote server the same as the public key on your local machine. You should have unique key pairs on each machine.

Also read the comments above the "UsePAM" line in /etc/ssh/sshd_config. It explains the config options to use for PublicKey encryption. Once you can log in manually with just keys, then disable password authentication completely:

Code:

# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

Keep one ssh session open, so you can test logging in from a different terminal session. That way you can revert changes made and not lock yourself out.

---

Since you are using your personal home directory, It seems to me that one of the machines you are connecting is your home workstation. Maybe a desktop or laptop that you tend to leave on. If this is the case and these aren't two remote servers, look into ssh-agent and ssh-add to manually enter a pass phrase when logging into your account. If one of these is a laptop, and it is lost, without protecting your private key, an attacker would be able ssh into the remote server and destroy everything in your account on that system. So much for syncing.

anomie · 01-25-2009, 10:33 PM

Quote:

Originally Posted by ESC201

I'm not sure which system you want the output for (I assume the remote but here's both anyway).

Remote...

Code:

drwxrwx--- 53 Shane Shane 4096 2009-01-25 21:53 /home/Shane

Local...

Code:

drwxrwx--- 59 Shane Shane 12288 2009-01-25 20:28 /home/Shane

Maybe you missed my comment, but on the server side only the owner can have write permissions for the user's home directory.

$ chmod g-w ~

Then try again...

ESC201 · 01-26-2009, 08:29 PM

I have to be missing something big here. I've tried every possible combination of the solutions suggested here. anomie, here is the output of "ls -ld ~" now...

Code:

drwxr-x--- 53 Shane Shane 4096 2009-01-26 21:13 /home/Shane

It didn't have any noticeable effect.

and here is my sshd config file from the remote system...

Code:

#	$OpenBSD: sshd_config,v 1.80 2008/07/02 02:24:18 djm 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
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# Disable legacy (protocol version 1) support in the server for new
# installations. In future the default will change to require 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

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

# 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
#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
#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

# 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 and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to '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 LANGUAGE

#AllowAgentForwarding yes
AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#ShowPatchLevel no
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no
#ChrootDirectory none

# no default banner path
#Banner none

# override default of no subsystems
Subsystem	sftp	/usr/libexec/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#	X11Forwarding no
#	AllowTcpForwarding no
#	ForceCommand cvs servere

Maybe it's just something in there. I don't know at this point. jschiwal, I am doing this on my local lan between my desktop and my laptop so I'm not terribly concerned about having a passphrase-less key setup especailly because I plan to implement some extra security once I get it working so it shouldn't be a problem. Thank you for the tip though.

anomie · 01-26-2009, 11:24 PM

Quote:

Originally Posted by ESC201

I have to be missing something big here. I've tried every possible combination of the solutions suggested here. anomie, here is the output of "ls -ld ~" now...

Is that on the client or server side? (Group/other write permissions can not be in place on the server side for the user's home directory when strict modes are enabled.)

A default Fedora installation should be as simple as:
$ ssh-keygen -b 2048 -t rsa
$ scp .ssh/id_rsa.pub user@some.host:~

Then on the server side you append id_rsa.pub to .ssh/authorized_keys (which needs to be readable only by the home directory owner). That's it unless you've been playing with permissions or tweaking sshd_config.

ESC201 · 01-27-2009, 06:16 PM

Well it was a permissions problem after all. I did "chmod -R 700 ~" and remade the keys and all is well. Thank you very much anomie for this and same to you jschiwal for your help. It's very much appreciated.

sanemanmad · 01-05-2010, 03:05 PM

I was having the same exact issue on my Fedora 11 install. Because I have setup keys on literally over 150 servers (Red-Hat) at work, I was not concerned about steps taken to setup keys, however i was still being promted for my password. In the end, chmod -R 700 ~ solved the issue.

I am still unable to ssh from user1@HOST to user2@HOST2; however I am now able to ssh user1@HOST to user1@HOST using keys. I will update again if I get the first working