2

I just setup a vanilla ubuntu lucid (10.04) system with openssh-server. I'm trying to setup publickey authentication, and it only works if I first connect using password authentication and leave that session open. All new concurrent sessions will work with publickey.

I've taken all the steps to ensure the correct permissions are in place on my server-side home directory. 

chmod go-w ~/
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

My client-side RSA 2048 bit public key is appended (one line only) to the authorized_keys files. My RSA keys have blank passphrases also.

I'm baffled as to what might cause this. I know it has to be something with my server configuration. I've heard that if configuration isn't secure "enough" that it will not permit publickey authentication, but I'm confused as to what that could be. 

# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile    %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

The rest is default. PublicKey works, but not for the first session.

Thanks in advance!

Nathan
  • 123
  • 1
  • 5
  • have you tried with "PasswordAuthentication no" set? also you should probably only try this if you set a back door up real quick with NC or something – Jimsmithkka Aug 17 '10 at 03:42
  • also check and see if SELinux is massing with anything, if its not configured correctly it can mess with things – Jimsmithkka Aug 17 '10 at 04:36
  • Check the server logs (`/var/log/auth.log`) for messages when authentication fails. Also look at `ssh -vvv` when passwordless authentication succeeds, to see why it's succeeding. – Gilles 'SO- stop being evil' Aug 17 '10 at 09:14
  • Encrypted (eCryptfs) home directories? – andol Aug 17 '10 at 10:59
  • Thanks everyone, Andol, it looks like my home folder IS encrypted. I had forgotten about that since it was a toy install. I'll look at disabling that. Jim, I have tried password auth to no with no luck. I also used ssh -vvv -o PasswordAuthentications=publickey to force the client to use publickey. I get the Permission Denied (publickey,password) response. – Nathan Aug 18 '10 at 16:23

4 Answers4

3

If you have an encrypted home directory, the way Ubuntu does it with EcryptFS, then that would explain what you are experiencing. Your ~/.ssh/authorized_keys firsts becomes available after you have made your first passworded login.

One way of allowing direct login by ssh keys is to specific AuthorizedKeysFile outside the home directory. This might be done by using %u (user) instead of %h (home directory) in the path. Another option is to put a copy of ~/.ssh/authorized_keys in your "unmounted" version of your home directory. That is what lays underneath the EcryptFS mount.

Yet, not sure how much good any of these solutions will really do you. You will still (kind of) need to login using your password to be able to access your regular home directory. It is your user password which is used to unwrap the passphrase needed to mount/decrypt your EcryptFS home directory. Yes, you could still mount/decrypt manually, but that almost seems like a different question.

andol
  • 6,938
  • 29
  • 43
  • Yes. You got it! I just removed my encrypted home drive and that fixed the problem. This command helped me remove my encrypted home folder. ecryptfs-setup-private --undo – Nathan Aug 18 '10 at 20:12
1

My guess is that it works once you are logged with password authentification because on client side you have set ControlMaster/ControlPath which allow reuse of connection for subsequent connections.

Try to increase log level on server side by setting the LogLevel to DEBUG3 and dig the logs (/var/log/auth.log) to see what's going on.

On client side add -vvv to the ssh command line to see which keys your client is using.

With both infos you should be able to figure out what's gpoing on.

hellvinz
  • 3,046
  • 2
  • 17
  • 9
  • I've tried this on both server and client, but I see generic skips from attempting publickey with rsa, to dsa, then to password authentication. I realized I have an encrypted home folder. I'm going to disable that and retry. – Nathan Aug 18 '10 at 16:25
0

Your authorized_keys file needs to live in the .ssh folder and it should have 644 permissions.

wolfgangsz
  • 8,847
  • 3
  • 30
  • 34
0

cp ~/.ssh/authorized_keys /etc/authorized_keys

and change /etc/ssh/sshd_config

AuthorizedKeysFile /etc/authorized_keys

and reload sshd /etc/init.d/ssh restart