# SSHD and Public Key Authentication

## danthehat

Right, so I wanted to setup a trust based public key authentication system between two computers in my network.  When I try to ssh to the server, this happens:

```
dcowsill@compaq ~ $ ssh -v -l dcowsill -i .ssh/id_rsa 192.168.0.102

OpenSSH_4.5p1, OpenSSL 0.9.8d 28 Sep 2006

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: Connecting to 192.168.0.102 [192.168.0.102] port 22.

debug1: Connection established.

debug1: identity file .ssh/id_rsa type 1

debug1: identity file /home/dcowsill/.ssh/id_rsa type 1

debug1: Remote protocol version 2.0, remote software version OpenSSH_4.5

debug1: match: OpenSSH_4.5 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_4.5

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug1: kex: server->client aes128-cbc hmac-md5 none

debug1: kex: client->server aes128-cbc hmac-md5 none

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

debug1: Host '192.168.0.102' is known and matches the RSA host key.

debug1: Found key in /home/dcowsill/.ssh/known_hosts:1

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

debug1: Next authentication method: publickey

debug1: Offering public key: .ssh/id_rsa

debug1: Authentications that can continue: publickey

debug1: Offering public key: /home/dcowsill/.ssh/id_rsa

debug1: Authentications that can continue: publickey

debug1: No more authentication methods to try.

Permission denied (publickey).

```

Basically, just the debugging information behind the last error message.  My client offers the correct id_rsa file (I have verified this dozens of different ways) and the user has permission to log into the system.

Here's the output when I run sshd in debug mode:

```
Connection from 192.168.0.101 port 4288

debug1: Client protocol version 2.0; client software version OpenSSH_4.5

debug1: match: OpenSSH_4.5 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_4.5

debug1: permanently_set_uid: 22/22

debug1: list_hostkey_types: ssh-rsa,ssh-dss

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug1: kex: client->server aes128-cbc hmac-md5 none

debug1: kex: server->client aes128-cbc hmac-md5 none

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received

debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT

debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug1: SSH2_MSG_NEWKEYS received

debug1: KEX done

debug1: userauth-request for user dcowsill service ssh-connection method none

debug1: attempt 0 failures 0

debug1: PAM: initializing for "dcowsill"

debug1: userauth-request for user dcowsill service ssh-connection method publickey

debug1: attempt 1 failures 1

debug1: test whether pkalg/pkblob are acceptable

debug1: PAM: setting PAM_RHOST to "192.168.0.101"

debug1: PAM: setting PAM_TTY to "ssh"

debug1: temporarily_use_uid: 1000/1000 (e=0/0)

debug1: trying public key file /root/.ssh/authorized_keys

debug1: restore_uid: 0/0

debug1: temporarily_use_uid: 1000/1000 (e=0/0)

debug1: trying public key file /root/.ssh/authorized_keys

debug1: restore_uid: 0/0

Failed publickey for dcowsill from 192.168.0.101 port 4288 ssh2

debug1: userauth-request for user dcowsill service ssh-connection method publickey

debug1: attempt 2 failures 2

debug1: test whether pkalg/pkblob are acceptable

debug1: temporarily_use_uid: 1000/1000 (e=0/0)

debug1: trying public key file /root/.ssh/authorized_keys

debug1: restore_uid: 0/0

debug1: temporarily_use_uid: 1000/1000 (e=0/0)

debug1: trying public key file /root/.ssh/authorized_keys

debug1: restore_uid: 0/0

Failed publickey for dcowsill from 192.168.0.101 port 4288 ssh2

Connection closed by 192.168.0.101

```

As you can see, the server does not actually look for the correct public key.  The server looks for root's public key (which does not actually exist).  This means that public key authentication fails every time.  I have looked over my sshd_config file many times looking for the cause, and as you can see it is changed very little from the default:

```
#       $OpenBSD: sshd_config,v 1.74 2006/07/19 13:07:10 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/bin:/bin:/usr/sbin:/sbin

# 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

Protocol 2

#AddressFamily any

ListenAddress 192.168.0.102

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

# Logging

# obsoletes QuietMode and FascistLogging

SyslogFacility AUTH

LogLevel INFO

# Authentication:

#LoginGraceTime 2m

PermitRootLogin no

#StrictModes yes

#MaxAuthTries 6

RSAAuthentication yes

PubkeyAuthentication yes

AuthorizedKeysFile      ~/.ssh/authorized_keys

DenyGroups all

AllowGroups sshd

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

#PermitEmptyPasswords no

# Change to no to disable s/key passwords

ChallengeResponseAuthentication no

# Kerberos options

#KerberosAuthentication no

#KerberosOrLocalPasswd yes

#KerberosTicketCleanup yes

#KerberosGetAFSToken no

# GSSAPI options

#GSSAPIAuthentication no

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

#AllowTcpForwarding yes

#GatewayPorts no

#X11Forwarding no

#X11DisplayOffset 10

#X11UseLocalhost yes

PrintMotd yes

#PrintLastLog yes

#TCPKeepAlive yes

#UseLogin no

#UsePrivilegeSeparation yes

#PermitUserEnvironment no

#Compression delayed

#ClientAliveInterval 0

#ClientAliveCountMax 3

#UseDNS yes

#PidFile /var/run/sshd.pid

#MaxStartups 10

#PermitTunnel no

# no default banner path

#Banner /some/path

# override default of no subsystems

Subsystem       sftp    /usr/lib64/misc/sftp-server

# Example of overriding settings on a per-user basis

#Match User anoncvs

#       X11Forwarding no

#       AllowTcpForwarding no

#       ForceCommand cvs server

```

I can confirm that the ssh_config file on the client machine is absolutely default.

I am sorry about the verbosity of my post, but every little bit helps.  This problem is absolutely baffling to me, so I would appreciate further insights.

Thank you very much.

----------

## jonnevers

delete the remote ssh keys, as a regular user: 

```
rm ~/.ssh/id_[rd]sa*

cat "" > ~/.ssh/authorized_keys
```

on the local host, as a regular user:

```
ssh-keygen -t dsa

ssh-copy-id -i ~/.ssh/id_dsa.pub remote_hostname_or_ip

ssh remote_hostname_or_ip
```

----------

## danthehat

The new dsa keys do not work.  I believe the problem is these line from the server debug infos:

```
debug1: trying public key file /root/.ssh/authorized_keys

debug1: restore_uid: 0/0

debug1: temporarily_use_uid: 1000/1000 (e=0/0)

debug1: trying public key file /root/.ssh/authorized_keys

```

The server is looking at root's authorized_keys even though I am asking for a different user.

Thanks.

----------

## danthehat

This is a very trying issue, as I am not entirely sure what would cause this behaviour.  I would really appreciate some help.

Thank you.

----------

## danthehat

This is still a bothering issue and I would appreciate any assistance that the forums can field for me.

Thanks.

----------

## gsoe

In the command you use: 

```
dcowsill@compaq ~ $ ssh -v -l dcowsill -i .ssh/id_rsa 192.168.0.102
```

you try forcing ssh to use protocol 1, but in your sshd_config you accept only protocol 2. Protocol 1 does not offer public key authentication. I don't know what you have tried, but I suggest that you try following the keychain guide http://www.gentoo.org/doc/en/keychain-guide.xml literally and combine it with thorough reading of the manpages for ssh and sshd.

Good luck!

----------

## danthehat

 *gsoe wrote:*   

> In the command you use: 
> 
> ```
> dcowsill@compaq ~ $ ssh -v -l dcowsill -i .ssh/id_rsa 192.168.0.102
> ```
> ...

 

That's an 'L' like:

```
ssh [-l login_name]
```

Not a -1 like:

```
ssh -1 [-l login_name]
```

Thanks, though.  Any insight forces me to look at the circumstances again, and fresh eyes are what I need.

For kicks, I issued the following command with the same result:

```
dcowsill@compaq ~ $ ssh -v dcowsill@192.168.0.102 -i .ssh/id_rsa
```

----------

## gsoe

Oh, sorry! Guess I have to do to some man-reading...

Anyway I'm just having a look at my debug output, when I issue the equivalent command: Until and including the line

```
debug1: PAM: initializing for "dcowsill"
```

I get the exact same output (except for username and IP's of course), but then I immediately get

```
debug1: PAM: setting PAM_RHOST to "myhost"

debug1: PAM: setting PAM_TTY to "ssh" 
```

before the next userauth-request is done. Could you have a PAM-related problem?

This is my full debug output, I hope you can use it:

```
 Connection from 192.168.1.25 port 1455

debug1: Client protocol version 2.0; client software version OpenSSH_4.5

debug1: match: OpenSSH_4.5 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_4.5

debug1: permanently_set_uid: 22/22

debug1: list_hostkey_types: ssh-rsa,ssh-dss

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug1: kex: client->server aes128-cbc hmac-md5 none

debug1: kex: server->client aes128-cbc hmac-md5 none

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received

debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT

debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug1: SSH2_MSG_NEWKEYS received

debug1: KEX done

debug1: userauth-request for user gert service ssh-connection method none

debug1: attempt 0 failures 0

debug1: PAM: initializing for "gert"

debug1: PAM: setting PAM_RHOST to "newpc.xconsult.dk"

debug1: PAM: setting PAM_TTY to "ssh"

debug1: userauth-request for user gert service ssh-connection method publickey

debug1: attempt 1 failures 1

debug1: test whether pkalg/pkblob are acceptable

debug1: temporarily_use_uid: 1000/1000 (e=0/0)

debug1: trying public key file /home/gert/.ssh/authorized_keys

debug1: matching key found: file /home/gert/.ssh/authorized_keys, line 1

Found matching DSA key: bc:a6:33:3b:3e:e4:ef:25:9a:dc:4f:95:68:b4:b4:3e

debug1: restore_uid: 0/0

Postponed publickey for gert from 192.168.1.25 port 1455 ssh2

debug1: userauth-request for user gert service ssh-connection method publickey

debug1: attempt 2 failures 1

debug1: temporarily_use_uid: 1000/1000 (e=0/0)

debug1: trying public key file /home/gert/.ssh/authorized_keys

debug1: matching key found: file /home/gert/.ssh/authorized_keys, line 1

Found matching DSA key: bc:a6:33:3b:3e:e4:ef:25:9a:dc:4f:95:68:b4:b4:3e

debug1: restore_uid: 0/0

debug1: ssh_dss_verify: signature correct

debug1: do_pam_account: called

Accepted publickey for gert from 192.168.1.25 port 1455 ssh2

debug1: monitor_child_preauth: gert has been authenticated by privileged process

debug1: PAM: reinitializing credentials

debug1: permanently_set_uid: 1000/1000

debug1: Entering interactive session for SSH2.

debug1: server_init_dispatch_20

debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384

debug1: input_session_request

debug1: channel 0: new [server-session]

debug1: session_new: init

debug1: session_new: session 0

debug1: session_open: channel 0

debug1: session_open: session 0: link with channel 0

debug1: server_input_channel_open: confirm session

debug1: server_input_channel_req: channel 0 request pty-req reply 0

debug1: session_by_channel: session 0 channel 0

debug1: session_input_channel_req: session 0 req pty-req

debug1: Allocating pty.

debug1: session_new: init

debug1: session_new: session 0

debug1: session_pty_req: session 0 alloc /dev/pts/3

debug1: server_input_channel_req: channel 0 request shell reply 0

debug1: session_by_channel: session 0 channel 0

debug1: session_input_channel_req: session 0 req shell

debug1: PAM: setting PAM_TTY to "/dev/pts/3"

debug1: Setting controlling tty using TIOCSCTTY.

debug1: Received SIGCHLD.

debug1: session_by_pid: pid 4525

debug1: session_exit_message: session 0 channel 0 pid 4525

debug1: session_exit_message: release channel 0

debug1: session_by_channel: session 0 channel 0

debug1: session_close_by_channel: channel 0 child 0

debug1: session_close: session 0 pid 0

debug1: channel 0: free: server-session, nchannels 1

Connection closed by 192.168.1.25

debug1: do_cleanup

debug1: PAM: cleanup

Closing connection to 192.168.1.25

debug1: PAM: cleanup

debug1: session_by_tty: session 0 tty /dev/pts/3

debug1: session_pty_cleanup: session 0 release /dev/pts/3

```

Good luck again!

----------

## gsoe

I think I've found it:

sshd doesn't expand the ~ in

```
AuthorizedKeysFile      ~/.ssh/authorized_keys 
```

From man sshd_conf: *Quote:*   

>      AuthorizedKeysFile
> 
>              Specifies the file that contains the public keys that can be used
> 
>              for user authentication.  AuthorizedKeysFile may contain tokens
> ...

 Just use 

```
AuthorizedKeysFile      .ssh/authorized_keys 
```

Good ssh'ing!

----------

## danthehat

"And Root wrote gsoe into the Book of Server and counted him among the Saints, saying 'Rejoice!  Thy SSH server config is free of silly errors!'"

Thanks a bunch, so glad to finally be rid of these silly hindrances  :Smile: 

----------

