# SSH and Public Key Authorization - [solved]

## PatG

I am trying to set up my ssh to allow Public Key authentication.  Specifically using protocol 2 and DSA keys. After many attemps and reading way to many howtos guides etc. I am just stuck.

This is fresh Gentoo system and for now I am just trying to set this up on the local computer. (ie # ssh localhost)

Running  openssh-4.3_p2-r1

Here are my configs

sshd_conffig (just the uncommented lines)

```

Port 22

Protocol 2

SyslogFacility AUTH

LogLevel INFO

LoginGraceTime 30

PermitRootLogin no

StrictModes yes

MaxAuthTries 4

RSAAuthentication no

PubkeyAuthentication yes

AuthorizedKeysFile      ~/.ssh/authorized_keys

PasswordAuthentication no

PermitEmptyPasswords no

ChallengeResponseAuthentication yes

#UsePAM yes

TCPKeepAlive yes

Compression yes

ClientAliveInterval 30

ClientAliveCountMax 4

Subsystem       sftp    /usr/lib/misc/sftp-server

```

ssh_config

```

RhostsRSAAuthentication no

RSAAuthentication no

PasswordAuthentication no

IdentityFile ~/.ssh/id_dsa

Protocol 2

PubkeyAuthentication yes

PreferredAuthentications publickey

```

I have created my keys from the client with ssh_keygen and cat'ed the dsa key into ~/.ssh/authorized_keys2 and I have checked the file permissions.

-rw-r--r--   1 root root  598 May  6 08:59 authorized_keys2

If I set UsePAM Yes in sshd_config it works fine but I do not want to use password auth. (my end goal here is doing rsyncs over ssh for some system backups)

Here is the debug output from ssh

```

pat@jedi ~/.ssh $ ssh -vvv localhost

OpenSSH_4.3p2, OpenSSL 0.9.7e 25 Oct 2004

debug1: Reading configuration data /etc/ssh/ssh_config

debug2: ssh_connect: needpriv 0

debug1: Connecting to localhost [127.0.0.1] port 22.

debug1: Connection established.

debug3: Not a RSA1 key file /home/pat/.ssh/id_dsa.

debug2: key_type_from_name: unknown key type '-----BEGIN'

debug3: key_read: missing keytype

debug2: key_type_from_name: unknown key type 'Proc-Type:'

debug3: key_read: missing keytype

debug2: key_type_from_name: unknown key type 'DEK-Info:'

debug3: key_read: missing keytype

debug3: key_read: missing whitespace

debug3: key_read: missing whitespace

debug3: key_read: missing whitespace

debug3: key_read: missing whitespace

debug3: key_read: missing whitespace

debug3: key_read: missing whitespace

debug3: key_read: missing whitespace

debug3: key_read: missing whitespace

debug3: key_read: missing whitespace

debug3: key_read: missing whitespace

debug2: key_type_from_name: unknown key type '-----END'

debug3: key_read: missing keytype

debug1: identity file /home/pat/.ssh/id_dsa type 2

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

debug1: match: OpenSSH_4.3 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

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

debug2: fd 3 setting O_NONBLOCK

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

debug2: kex_parse_kexinit: ssh-rsa,ssh-dss

debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr

debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib

debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib

debug2: kex_parse_kexinit:

debug2: kex_parse_kexinit:

debug2: kex_parse_kexinit: first_kex_follows 0

debug2: kex_parse_kexinit: reserved 0

debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

debug2: kex_parse_kexinit: ssh-rsa,ssh-dss

debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr

debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib

debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib

debug2: kex_parse_kexinit:

debug2: kex_parse_kexinit:

debug2: kex_parse_kexinit: first_kex_follows 0

debug2: kex_parse_kexinit: reserved 0

debug2: mac_init: found hmac-md5

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

debug2: mac_init: found hmac-md5

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

debug2: dh_gen_key: priv key bits set: 127/256

debug2: bits set: 486/1024

debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

debug3: check_host_in_hostfile: filename /home/pat/.ssh/known_hosts

debug3: check_host_in_hostfile: match line 1

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

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

debug2: bits set: 500/1024

debug1: ssh_rsa_verify: signature correct

debug2: kex_derive_keys

debug2: set_newkeys: mode 1

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug2: set_newkeys: mode 0

debug1: SSH2_MSG_NEWKEYS received

debug1: SSH2_MSG_SERVICE_REQUEST sent

debug2: service_accept: ssh-userauth

debug1: SSH2_MSG_SERVICE_ACCEPT received

debug2: key: /home/pat/.ssh/id_dsa (0x8090688)

debug1: Authentications that can continue: publickey,keyboard-interactive

debug3: start over, passed a different list publickey,keyboard-interactive

debug3: preferred publickey

debug3: authmethod_lookup publickey

debug3: remaining preferred:

debug3: authmethod_is_enabled publickey

debug1: Next authentication method: publickey

debug1: Offering public key: /home/pat/.ssh/id_dsa

debug3: send_pubkey_test

debug2: we sent a publickey packet, wait for reply

debug1: Authentications that can continue: publickey,keyboard-interactive

debug2: we did not send a packet, disable method

debug1: No more authentication methods to try.

Permission denied (publickey,keyboard-interactive).

```

I see several oddities in the debug output but I have not been able to find any really good info on what some of this means.

As usual, any feedback is appreciated.Last edited by PatG on Mon May 08, 2006 5:16 am; edited 1 time in total

----------

## limn

 *sshd_config wrote:*   

> AuthorizedKeysFile      ~/.ssh/authorized_keys 

 

but that is not the same as

 *PatG wrote:*   

> ~/.ssh/authorized_keys2

 

----------

## PatG

True, but the key has been copied to both files.

Somewhere I read that the authorized_keys2 file was for protocol 2 and copied the key to there, but it was all lready in the authorized_keys file, just forgot to update the sshd_sonfig.

To be consistant with protocol 2 I made the change to sshd_config and restarted sshd, the debug output was *exactly* the same except for this line.

debug2: bits set: 501/1024 (it was 517/1024 previously)

One odd item I see is

Offering public key: /home/pat/.ssh/id_dsa

Based on what I have read the public key should be id_dsa.pub, is this just a debug output problem or is it really offering the private key?

----------

## limn

If AuthorizedKeysFile is not specified in sshd_config it will look for  authorized_keys or authorized_keys2, but if you specify it then you have to use that name for the file.

Try commenting out IdentityFile ~/.ssh/id_dsa in your ssh_config.

----------

## PatG

 *limn wrote:*   

> If AuthorizedKeysFile is not specified in sshd_config it will look for  authorized_keys or authorized_keys2, but if you specify it then you have to use that name for the file.

 

Yes, my goof on not updating the sshd_config to reflect that I wanted to use authorized_keys2. Again the public key was cat'ed to both files and either should have worked with when I specified the file in the config.

 *limn wrote:*   

> Try commenting out IdentityFile ~/.ssh/id_dsa in your ssh_config.

 

Tried it and no difference

debug1: Offering public key: /home/pat/.ssh/id_dsa

----------

## limn

Looks like this

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

should be

```
AuthorizedKeysFile    .ssh/authorized_keys
```

----------

## PatG

I have seen documentation showing both formats

~/.ssh/authorized_keys(2)

and 

.ssh/authorized_keys(2)

Either way produces the same result.  I do thank you for the help. I have been beating my head against the wall for days on this and have reviewed the documentastion very careully to no avail..

One of the biggest problems I see is that there are mustlple sets of documentation and even that on OpenSSH.com is out of date in places.

If anyone has a working set of config files (both sshd_config and ssh_config) for Public Key Authentication it would be great to see them.

I also checked my auth.log in hope of finding some output from sshd, there was nothing.

----------

## PatG

I was able to solve ths by manually starting sshd from a root console with

```
# /usr/sbin/sshd -ddd
```

This way I could watch the debug output from the daemon.

I saw this in the output from sshd

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

Problem was I was had put my keys in ~/.ssh.authorized_keys. (which is in /root )

I think some of the first documentation I read on this was someone who had written it working as root and that put me on the wrong track.

If I understand correctly now, when you use a public key authentication, each user who accesses via ssh will have an authorized_keys file in their /home/.ssh directory.  Is there a reason that there is not a sever wide common file to store the authorized keys in?  On the surface it would seem easier to know what keys existed and where they were from.

----------

## limn

Yes, each user will have their own $HOME/.ssh/authorized_keys, if they are to use keys for authentication.

The developers of SSH wanted it to be easy to use and so that users could even run the server  without special priviledges.

How would a server wide repository be administered? If users can write to the repository they might be able to manipulate other users keys. If only root can add or change the keys, then root or a root process must be available to do this at any time. This would add complexity and increase risk.

----------

## PatG

 *Quote:*   

> The developers of SSH wanted it to be easy to use and so that users could even run the server without special priviledges.
> 
> How would a server wide repository be administered? If users can write to the repository they might be able to manipulate other users keys. If only root can add or change the keys, then root or a root process must be available to do this at any time. This would add complexity and increase risk.

 

Yes, I can see the reasons for the way it is.

Now, if I have a server set up with Public Key Auth and no Password Auth I see it like this.

In order for the user to connect via ssh, the key MUST be in their authorized_keys file to begin with. Is there a method for a new remote user to add a key to their file (actually create the authorized_keys file)? The only way I see it working on the setup I have is to somehow transfer the key to the server (ftp, email, physical media) and then have the user (or root) physically on the server add the key to their file. I guess I could use an existing ssh user who already has a key and su root (direct root ssh login disabled) and copy the key from the client to the server as well. Do I have all of this correct?

The situation I have is that there will be several remote clients and one server. My plan is to have each client use rsync or unison to do remote backup over ssh. I was planning on having a distinct login and sync location (directory) on the server for each remote client because some data is sensitive in nature.  Becuase of this requirement I certainly cannot share keys or passphrases across machines and from what I see in the key files there is a client identifier (user@computer_name) as well so I assume I could not take the keys from one computer to another.

So my thinking is this:

1. I am at a new client, named xxx (these are primarily Windows boxes)

2. Install the ssh client (using cygwin)

3. Generate the id_dsa key pair.

4. Transfer the key to some physical media. (USB key)

5. Mount the USB key on the laptop already setup with ssh.

6. Use ssh to copy the key to te remote server. (to /copylocation)

7. Establish and ssh session and su when connected

8. Through su I create a new user account, yyy,  on the server and assign a password.

  Q. Is there a correct way (from a security standpoint) to setup this ssh only account? Like using /bin/false shell for ftp? Or something like a chroot jail? This user account should never be used for a direct login on the server but must be able to ssh and run rsync and/or unison.

9. Create the rsync location on the server. (/home/yyy)

10. Create /home/yyy/.ssh

11. Do chown on the new user directory so yyy can access the folders.

12. Do  # cat /copylocation/id_dsa.pub > /home/yyy/.ssh/authorized_keys

13. exit su and logoff ssh from the laptop

14. Now  I can ssh from the client box xxx wth user yyy?

Hopefully I am not way off here and have read enough to have most of this correct. Comments welcome.

----------

## think4urs11

 *PatG wrote:*   

> Now, if I have a server set up with Public Key Auth and no Password Auth I see it like this.
> 
> In order for the user to connect via ssh, the key MUST be in their authorized_keys file to begin with. Is there a method for a new remote user to add a key to their file (actually create the authorized_keys file)?

 

If the ssh server allows password login you could use net-misc/ssh-installkeys to distribute your key - not as safe of course due to password login needed but -from a users point of view- very easy to use.

If password login is not allowed ... then no, no direct way besides the workaround(s) you described.

Prefered way of course is to send the key to the server admin in a safe way. By that the benefit would be that you can be sure the key is implemented on the correct machine in the correct way (in terms of no MitM is possible).

When you compare (e.g. by phone) the host key you get for the first login with the real servers key you receive from the server admin (by phone or snail mail) you get annother layer of MitM protection.

----------

## wizard69

 *Quote:*   

>  Install the ssh client (using cygwin) 

 

have a look at putty ssh client for windows and puttygen for generating ssh key pairs with a windows client.

http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

----------

## PatG

 *Think4UrS11 wrote:*   

> Prefered way of course is to send the key to the server admin in a safe way. By that the benefit would be that you can be sure the key is implemented on the correct machine in the correct way (in terms of no MitM is possible).
> 
> 

 

If I understand correctly though. the public key by itself is useless. Is there any reason to think that doing a cat or scp of the public key in an ssh session is unsafe (assuming that the ssh server/session is uncompromised)?

Also, there is only a single server and I am the only one with root access to it.

----------

## think4urs11

 *PatG wrote:*   

>  *Think4UrS11 wrote:*   Prefered way of course is to send the key to the server admin in a safe way. By that the benefit would be that you can be sure the key is implemented on the correct machine in the correct way (in terms of no MitM is possible).
> 
>  
> 
> If I understand correctly though. the public key by itself is useless. Is there any reason to think that doing a cat or scp of the public key in an ssh session is unsafe (assuming that the ssh server/session is uncompromised)?

 

a) the public key by itself isn't secure in any way

b) the private key by itself is -to an attacker- useless if it has a strong passhrase. If it doesn't the attacker gets access to any server this key is useable for instantly if he is able to steal this private key.

c) It is safe by itself to do cat inside an existing session, but ... in order to be able to do that you have to have the server configured to allow something else then publickey-auth which -in most cases- is then by password/interactive which is not as safe as publickey is. (The password auth could be brute forced)

Hope this clearifies the issue a bit better.

----------

