# ssh authentication problem [RESOLVED]

## nanoo

Hi,

I am trying to set up my Gentoo box as a server for various applications, connecting to it with a Mac Powerbook client. I would like to start off with getting sshd on the Gentoo box up and running, however I am running into problems with the authentication... I expect that I am overlooking something obvious, however after spending a great deal of time troubleshooting my setup, I keep coming up with nothing. I searched these forums, but other people's errors seem to be with different issues (e.g. iptables). 

So, firstly I am just trying to connect to the localhost in order to make sure that things are working before trying connections with the Powerbook client. Here is the /etc/ssh/sshd_config file:

```

Port 787

Protocol 2

#AddressFamily any

#ListenAddress 0.0.0.0

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

ServerKeyBits 768

# Logging

# obsoletes QuietMode and FascistLogging

SyslogFacility AUTH

LogLevel INFO

# Authentication:

LoginGraceTime 120

PermitRootLogin no

StrictModes yes

MaxAuthTries 6

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

PermitEmptyPasswords no

# Change to no to disable s/key passwords

ChallengeResponseAuthentication yes

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

# Depending on your PAM configuration, this may bypass the setting of

# PasswordAuthentication, PermitEmptyPasswords, and

# "PermitRootLogin without-password". If you just want the PAM account and

# session checks to run without PAM authentication, then enable this but set

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

# no default banner path

#Banner /some/path

# here is the new patched ldap related tokens

# entries in your LDAP must have posixAccount & ldapPublicKey objectclass

#UseLPK yes

#LpkLdapConf /etc/ldap.conf

#LpkServers  ldap://127.0.0.4 ldap://127.0.0.3 ldap://127.0.0.1/

#LpkUserDN   ou=users,dc=phear,dc=org

#LpkGroupDN  ou=groups,dc=phear,dc=org

#LpkBindDN cn=Manager,dc=phear,dc=org

#LpkBindPw secret

#LpkServerGroup mail

#LpkForceTLS no

#LpkSearchTimelimit 3

#LpkBindTimelimit 3

# override default of no subsystems

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

```

and here is my /etc/pam.d/sshd:

```

#%PAM-1.0

#From guide for sshd setup

auth       required     pam_stack.so service=system-auth

auth       required     pam_tally.so deny=4 magic_root lock_time=5 unloock_time=3600

auth       required     pam_shells.so

auth       required     pam_nologin.so

account    required     pam_stack.so service=system-auth

account    required     pam_tally.so

password   required     pam_stack.so service=system-auth

session    required     pam_stack.so service=system-auth

```

I have been working at using key based authentication using this as a reference:

http://www.gentoo.org/doc/en/keychain-guide.xml

My server has the host name 'morbo', and I have a user 'zoidberg' that I am trying to connect with using ssh. 

So I:

```

zoidberg@morbo ~ $ ssh-keygen -t dsa

Generating public/private dsa key pair.

Enter file in which to save the key (/home/zoidberg/.ssh/id_dsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /home/zoidberg/.ssh/id_dsa.

Your public key has been saved in /home/zoidberg/.ssh/id_dsa.pub.

The key fingerprint is: [fingerprint] 

zoidberg@morbo ~ $ sudo cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys

zoidberg@morbo ~ $ cat ~/.ssh/authorized_keys

ssh-dss [key]== zoidberg@morbo

```

(note that I replaced the long fingerprint and key with [fingerprint] and [key] respectively)

then:

```

zoidberg@morbo ~ $ sudo /etc/init.d/sshd start

 * Starting sshd ...                                                                          [ ok ]

```

and finally:

```

zoidberg@morbo ~ $ ssh -v -l zoidberg morbo

OpenSSH_4.2p1, OpenSSL 0.9.7e 25 Oct 2004

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: Connecting to morbo [127.0.0.1] port 787.

debug1: Connection established.

debug1: identity file /home/zoidberg/.ssh/id_rsa type -1

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

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

debug1: match: OpenSSH_4.2 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

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

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

The authenticity of host 'morbo (127.0.0.1)' can't be established.

RSA key fingerprint is [fingerprint].

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added 'morbo' (RSA) to the list of known hosts.

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,keyboard-interactive

debug1: Next authentication method: publickey

debug1: Trying private key: /home/zoidberg/.ssh/id_rsa

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

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

debug1: Next authentication method: keyboard-interactive

Password:

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

Password:

```

When asked for the password, I am assuming what the want is the passphrase that I used to generate the keys - that is what the guide suggests (assuming i read it correctly....). However it does not allow me to connect - any ideas on what I am doing wrong here?

Thanks in advance,

nanooLast edited by nanoo on Sun Jan 22, 2006 9:08 pm; edited 1 time in total

----------

## truc

Why do you use sudo to perform this:

```
sudo cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
```

  :Question:  The problem might be there, can you give us your sudoers file? I mean if you use sudo (without a username) then the command is run as if you were root, that said: the file ~/.ssh/id_dsa.pubis then /root/.ssh/id_dsa.pub same remarq with ~/.ssh/authorized_keys. So I think you should try no using sudo for this step, before trying anything else...

----------

## nanoo

That's a very good point - I can't think of why I used the sudo there; it's certainly not necessary.  

Unfortunately the problem remains. I removed the keys from zoidberg's .ssh directory and tried the whole thing over:

```

zoidberg@morbo ~ $ rm /home/zoidberg/.ssh/authorized_keys

zoidberg@morbo ~ $ rm /home/zoidberg/.ssh/id_dsa

zoidberg@morbo ~ $ rm /home/zoidberg/.ssh/id_dsa.pub

zoidberg@morbo ~ $ rm /home/zoidberg/.ssh/known_hosts

zoidberg@morbo ~ $ ssh-keygen -t dsa

Generating public/private dsa key pair.

Enter file in which to save the key (/home/zoidberg/.ssh/id_dsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /home/zoidberg/.ssh/id_dsa.

Your public key has been saved in /home/zoidberg/.ssh/id_dsa.pub.

The key fingerprint is:

[fingerprint]

zoidberg@morbo ~ $ cat /home/zoidberg/.ssh/id_dsa >> /home/zoidberg/.ssh/authorized_keys

zoidberg@morbo ~ $ cat /home/zoidberg/.ssh/authorized_keys

-----BEGIN DSA PRIVATE KEY-----

Proc-Type: 4,ENCRYPTED

DEK-Info: DES-EDE3-CBC,77EF1483C28269C0

[key]

-----END DSA PRIVATE KEY-----

zoidberg@morbo ~ $ sudo /etc/init.d/sshd start

 * Starting sshd ...                                                      [ ok ]

zoidberg@morbo ~ $ ssh -v -l zoidberg morbo

OpenSSH_4.2p1, OpenSSL 0.9.7e 25 Oct 2004

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: Connecting to morbo [127.0.0.1] port 787.

debug1: Connection established.

debug1: identity file /home/zoidberg/.ssh/id_rsa type -1

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

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

debug1: match: OpenSSH_4.2 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

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

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

The authenticity of host 'morbo (127.0.0.1)' can't be established.

RSA key fingerprint is [fingerprint].

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added 'morbo' (RSA) to the list of known hosts.

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,keyboard-interactive

debug1: Next authentication method: publickey

debug1: Trying private key: /home/zoidberg/.ssh/id_rsa

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

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

debug1: Next authentication method: keyboard-interactive

Password:

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

Password:

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

Password:

```

Actually though, looking it over, the output from 

```

cat /home/zoidberg/.ssh/authorized_keys

```

is different than before, so I think you were right that the sudo was problematic...

nanoo

----------

## truc

You copied id_dsa in authorized_keys instead of id_dsa.pub  :Wink:  It looks like you have to do it an other time;) 

(in fact just do: cat ~/.ssh/id_dsa.pub > ~/.ssh/authorized_keys )

----------

## nanoo

 :Embarassed:  Sorry for that oversight... tab-completion is my favourite feature as well as my largest source of mistakes....  :Smile: 

Now I of course see why the output of the authorized_keys file was different - it was the private and not the public key. 

So I redid it one more time, and unfortunately the result was the same:

```

zoidberg@morbo ~ $ rm /home/zoidberg/.ssh/id_dsa

zoidberg@morbo ~ $ rm /home/zoidberg/.ssh/id_dsa.pub

zoidberg@morbo ~ $ rm /home/zoidberg/.ssh/authorized_keys

zoidberg@morbo ~ $ rm /home/zoidberg/.ssh/known_hosts

zoidberg@morbo ~ $ ssh-keygen -t dsa

Generating public/private dsa key pair.

Enter file in which to save the key (/home/zoidberg/.ssh/id_dsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /home/zoidberg/.ssh/id_dsa.

Your public key has been saved in /home/zoidberg/.ssh/id_dsa.pub.

The key fingerprint is:

[fingerprint] zoidberg@morbo

zoidberg@morbo ~ $ cat ~/.ssh/id_dsa.pub > ~/.ssh/authorized_keys

zoidberg@morbo ~ $ cat ~/.ssh/authorized_keys

ssh-dss [key]= zoidberg@morbo

zoidberg@morbo ~ $ sudo /etc/init.d/sshd start

 * Starting sshd ...                                                      [ ok ]

zoidberg@morbo ~ $ ssh -v -l zoidberg morbo

OpenSSH_4.2p1, OpenSSL 0.9.7e 25 Oct 2004

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: Connecting to morbo [127.0.0.1] port 787.

debug1: Connection established.

debug1: identity file /home/zoidberg/.ssh/id_rsa type -1

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

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

debug1: match: OpenSSH_4.2 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

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

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

The authenticity of host 'morbo (127.0.0.1)' can't be established.

RSA key fingerprint is [fingerprint].

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added 'morbo' (RSA) to the list of known hosts.

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,keyboard-interactive

debug1: Next authentication method: publickey

debug1: Trying private key: /home/zoidberg/.ssh/id_rsa

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

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

debug1: Next authentication method: keyboard-interactive

Password:

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

Password:

```

Is it maybe something with the configuration file for ssh and not sshd? The guides I looked at didn't seem to require many options added to ssh_config, I think they mostly just wanted you replace '# Protocol 2,1' with 'Protocol 2'. I did that, and of course changed the port to the same as in sshd_config. At any rate, just in case it is important, here is my ssh_config:

```

# Host *

#   ForwardAgent no

#   ForwardX11 no

#   RhostsRSAAuthentication no

#   RSAAuthentication yes

#   PasswordAuthentication yes

#   HostbasedAuthentication no

#   BatchMode no

#   CheckHostIP yes

#   AddressFamily any

#   ConnectTimeout 0

#   StrictHostKeyChecking ask

#   IdentityFile ~/.ssh/identity

#   IdentityFile ~/.ssh/id_rsa

#   IdentityFile ~/.ssh/id_dsa

Port 787

Protocol 2

#   Cipher 3des

#   Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc

#   EscapeChar ~

```

Thanks for the help so far,

nanoo

----------

## truc

OK, that let's try my first idea:

I don't use PAM so I don't know really how it can work, but I do know that PAM and sshd can do very wierd things together if not well configured..

Let's try it without PAM:

In you sshd_config

```
#UsePAM yes
```

Then don't forget to restart sshd

BTW  *truc wrote:*   

> You copied id_dsa in authorized_keys instead of id_dsa.pub  It looks like you have to do it an other time;)
> 
> (in fact just do: cat ~/.ssh/id_dsa.pub > ~/.ssh/authorized_keys )

 

I said that because, you didn't need to start with ssh-keygen all over again... You just had to run the command I gave just above...

But now, each time you will have to add a new key in your authorized_keys, use >> (using only > erase first the file and then write into it...)

BTW "2" It looks like you have allowed every command with sudo without a password, just be carefull with that... (I personnally (would) have allowed only the really needed command, with or without password depending on the command...) If someone can somehow log on your box with this user, it's exactly as if it were the root :S )Last edited by truc on Mon Jan 16, 2006 8:08 pm; edited 2 times in total

----------

## nanoo

Ok, that sounds like a good way of isolating what is going wrong - I'll definately try it without PAM when I get back from work. 

I see what you meant earlier as well (I didn't read it that way the first time - and didn't actually realize that subtle difference between '>' and '>>'). 

That is a good point about not requiring a password for sudo with user 'zoidberg': I set that up very early out of convenience, with the idea that I would return to a more secure setup later... a mix of forgetfulness and, let's face it, laziness, has kept me from securing it. I think that getting ssh running will force me to move to a more secure setup  :Smile: . 

nanoo

----------

## nanoo

Hmm... well something is definately up... upon commenting out the use of PAM, I'm all of a sudden denied without even the option to enter a password...

Here is what I did:

```

zoidberg@morbo ~ $ sudo nano -w /etc/ssh/sshd_config

```

and commented out the 'UsePam yes'; here is the file as it stands now:

```

Port 787

Protocol 2

#AddressFamily any

#ListenAddress 0.0.0.0

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

ServerKeyBits 768

# Logging

# obsoletes QuietMode and FascistLogging

SyslogFacility AUTH

LogLevel INFO

# Authentication:

LoginGraceTime 120

PermitRootLogin no

StrictModes yes

MaxAuthTries 6

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

PermitEmptyPasswords no

# Change to no to disable s/key passwords

ChallengeResponseAuthentication yes

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

# Depending on your PAM configuration, this may bypass the setting of

# PasswordAuthentication, PermitEmptyPasswords, and

# "PermitRootLogin without-password". If you just want the PAM account and

# session checks to run without PAM authentication, then enable this but set

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

# no default banner path

#Banner /some/path

# here is the new patched ldap related tokens

# entries in your LDAP must have posixAccount & ldapPublicKey objectclass

#UseLPK yes

#LpkLdapConf /etc/ldap.conf

#LpkServers  ldap://127.0.0.4 ldap://127.0.0.3 ldap://127.0.0.1/

#LpkUserDN   ou=users,dc=phear,dc=org

#LpkGroupDN  ou=groups,dc=phear,dc=org

#LpkBindDN cn=Manager,dc=phear,dc=org

#LpkBindPw secret

#LpkServerGroup mail

#LpkForceTLS no

#LpkSearchTimelimit 3

#LpkBindTimelimit 3

# override default of no subsystems

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

```

then:

```

zoidberg@morbo ~ $ ssh-keygen -t dsa

Generating public/private dsa key pair.

Enter file in which to save the key (/home/zoidberg/.ssh/id_dsa):

/home/zoidberg/.ssh/id_dsa already exists.

Overwrite (y/n)? y

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /home/zoidberg/.ssh/id_dsa.

Your public key has been saved in /home/zoidberg/.ssh/id_dsa.pub.

The key fingerprint is:

[fingerprint] zoidberg@morbo

zoidberg@morbo ~ $ cat ~/.ssh/id_dsa.pub > ~/.ssh/authorized_keys

zoidberg@morbo ~ $ sudo /etc/init.d/sshd restart

 * Starting sshd ...                                                      [ ok 

]zoidberg@morbo ~ $ ssh -v -l zoidberg morbo

OpenSSH_4.2p1, OpenSSL 0.9.7e 25 Oct 2004

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: Connecting to morbo [127.0.0.1] port 787.

debug1: Connection established.

debug1: identity file /home/zoidberg/.ssh/id_rsa type -1

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

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

debug1: match: OpenSSH_4.2 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

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

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 'morbo' is known and matches the RSA host key.

debug1: Found key in /home/zoidberg/.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,keyboard-interactive

debug1: Next authentication method: publickey

debug1: Trying private key: /home/zoidberg/.ssh/id_rsa

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

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

debug1: Next authentication method: keyboard-interactive

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

debug1: No more authentication methods to try.

Permission denied (publickey,keyboard-interactive).

```

So looking over the sshd_config file, I can't think of what I have done that doesn't allow the use of key based authentication...

One thing about the ssh output that confuses me as well is:

```

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

```

Wouldn't the public key be in .ssh/id_dsa.pub and not in .ssh/id_dsa?

I'm going to think about this some more - thanks so much for the help so far,

nanoo

----------

## truc

 *nanoo wrote:*   

> Hmm... well something is definately up... upon commenting out the use of PAM, I'm all of a sudden denied without even the option to enter a password...

 

It's normal for the password.. PAM was overiding your sshd config, in which you had already before:

```
# To disable tunneled clear text passwords, change to no here!

PasswordAuthentication no

# Change to no to disable s/key passwords

ChallengeResponseAuthentication yes 
```

So before, looking at your config, you should not be asked a password, but you were because of PAM, look inside sshd_config again:

```
# 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 mechanism.

# Depending on your PAM configuration, this may bypass the setting of 
```

Ok now?

With PAM disable--> normal behaviour without tricky setting  :Smile: 

Well now we're here... your key doesn't work... let's look at it:

when you create it you use 

```
ssh-keygen -t dsa
```

 Well it doesn't look enough since  *man ssh-keygen wrote:*   

> 
> 
> Options:     -b bits
> 
>              Specifies the number of bits in the key to create.  Minimum is 512 bits.
> ...

 

Oh, but your key is supposed to be 768 bits isn't it?

So create a 768 bits key:

```
 ssh-keygen -t dsa -b 768 
```

then 

```
 cat ~/.ssh/id_dsa.pub > ~/.ssh/authorized_keys 
```

 (only one">" this time again..)

And tell us if it's better...Last edited by truc on Wed Jan 18, 2006 5:43 pm; edited 1 time in total

----------

## nanoo

That is very true, and I really should have thought to look at the default setting for keygen. Sadly work is interfering with my plans to test this (of course, once I get sshd going, I'll  be able to test these sorts of things FROM work  :Smile:  ), but I will post back once I've gotten a chance to try it. 

nanoo

----------

## nanoo

No luck...

```

zoidberg@morbo ~ $ ssh-keygen -t dsa -b 768

Generating public/private dsa key pair.

Enter file in which to save the key (/home/zoidberg/.ssh/id_dsa):

/home/zoidberg/.ssh/id_dsa already exists.

Overwrite (y/n)? y

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /home/zoidberg/.ssh/id_dsa.

Your public key has been saved in /home/zoidberg/.ssh/id_dsa.pub.

The key fingerprint is:

[fingerprint] zoidberg@morbo

zoidberg@morbo ~ $ cat ~/.ssh/id_dsa.pub > ~/.ssh/authorized_keys

zoidberg@morbo ~ $ sudo /etc/init.d/sshd restart

Password:

 * Stopping sshd ...                                                      [ ok ]

 * Starting sshd ...                                                      [ ok ]

zoidberg@morbo ~ $ ssh -v -l zoidberg morbo

OpenSSH_4.2p1, OpenSSL 0.9.7e 25 Oct 2004

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: Connecting to morbo [127.0.0.1] port 787.

debug1: Connection established.

debug1: identity file /home/zoidberg/.ssh/id_rsa type -1

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

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

debug1: match: OpenSSH_4.2 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

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

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 'morbo' is known and matches the RSA host key.

debug1: Found key in /home/zoidberg/.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,keyboard-interactive

debug1: Next authentication method: publickey

debug1: Trying private key: /home/zoidberg/.ssh/id_rsa

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

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

debug1: Next authentication method: keyboard-interactive

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

debug1: No more authentication methods to try.

Permission denied (publickey,keyboard-interactive).

```

I'm lost here. Maybe it's time to just go with password based authentication?

nanoo

----------

## magic919

I'd have to say I've not read every word of the preceding posts.  However, this bit

 *Quote:*   

> debug1: Trying private key: /home/zoidberg/.ssh/id_rsa
> 
> debug1: Offering public key: /home/zoidberg/.ssh/id_dsa 

 

caught my eye.  Shouldn't the private key be /home/zoidberg/.ssh/id_dsa, not _rsa?  Do you have some old keys in there you could clear out?

----------

## nanoo

I was similarly confused by that output from OpenSSH. My understanding of how the key authentication works is kind of sketchy, but judging from this output from ssh-keygen:

 *Quote:*   

> 
> 
> Your identification has been saved in /home/zoidberg/.ssh/id_dsa.
> 
> Your public key has been saved in /home/zoidberg/.ssh/id_dsa.pub.
> ...

 

I would have thought that the private key would be in .ssh/id_dsa and the public key in .ssh/id_dsa.pub

But the output from OpenSSH makes it seem like it's looking for the private key in .ssh/id_rsa and looking for the public key in .ssh/id_dsa, or does it just look that way to me?

As for old keys, I don't think that I have any kicking around. I've only been trying this in the last few days, and each attempt I either manually remove or overwrite the old keys that are present in ~/.ssh

nanoo

----------

## Esel Theo

 *truc wrote:*   

> Why do you use sudo to perform this:
> 
> ```
> sudo cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
> ```
> ...

 

Wrong. The ~ will be expanded by the shell before sudo even comes into play.

Still, no need to use sudo at all here.

(Btw. if you want to only edit files with root permissions you might like the sudoedit command.)

----------

## nanoo

Hadn't heard of sudoedit, and come to think of it I mostly use sudo when editing config files that require root permission. I'll look into it. 

But you're right that there was no reason to use sudo there - my mistake. I've also followed up on some good advice earlier and secured sudo with a password (in anticipation of getting sshd working  :Smile:  ). 

nanoo

----------

## truc

 *Esel Theo wrote:*   

>  *truc wrote:*   Why do you use sudo to perform this:
> 
> ```
> sudo cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
> ```
> ...

 

Ok my mistake  :Sad: 

BTW: I just didn't think enough, although  I 've read man bash the past weeks, I didn't think about it (expansion comes first IIRC )

----------

## nanoo

Well, for now I'll be using the password approach:

```

zoidberg@morbo ~ $ ssh -v -l zoidberg morbo

OpenSSH_4.2p1, OpenSSL 0.9.7e 25 Oct 2004

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: Connecting to morbo [127.0.0.1] port 787.

debug1: Connection established.

debug1: identity file /home/zoidberg/.ssh/id_rsa type -1

debug1: identity file /home/zoidberg/.ssh/id_dsa type -1

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

debug1: match: OpenSSH_4.2 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

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

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

The authenticity of host 'morbo (127.0.0.1)' can't be established.

RSA key fingerprint is 6a:5e:6e:c3:40:8a:46:74:63:38:d2:b2:c4:99:4d:6e.

Are you sure you want to continue connecting (yes/no)? yes

Failed to add the host to the list of known hosts (/home/zoidberg/.ssh/known_hosts).

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,password,keyboard-interactive

debug1: Next authentication method: publickey

debug1: Trying private key: /home/zoidberg/.ssh/id_rsa

debug1: Trying private key: /home/zoidberg/.ssh/id_dsa

debug1: Next authentication method: keyboard-interactive

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

debug1: Next authentication method: password

zoidberg@morbo's password:

debug1: Authentication succeeded (password).

debug1: channel 0: new [client-session]

debug1: Entering interactive session.

Last login: Thu Jan 19 23:57:43 2006 from localhost

```

From what I've read it's unsafe, but I can't figure out this key-based authentication...

Thanks to those who posted for their help though. 

nanoo

----------

## magic919

This morning I've followed what you did, as if it was a HOWTO.  I tried a few things as it did not work for me.  To get mine working I did a chmod 400 on the public key file. I also found that ssh - user caused problems for me (as it was not the user I was running as).  I then did su - user and tried ssh -v hostname and that was cool.

----------

## truc

There is something really wierd.. 

BTW: here is how I do (and it works  :Wink:  ) :

```
confcat /etc/ssh/sshd_config

Protocol 2

AllowUsers truc someoneelse

ServerKeyBits 1024

LogLevel VERBOSE

PermitRootLogin no

MaxAuthTries 3

IgnoreRhosts no

PasswordAuthentication no

X11Forwarding yes

MaxStartups 3

Subsystem   sftp   /usr/libexec/sftp-server
```

(btw: I'm running sshd with xinetd)

Here is how I do:

```
cd ~

ssh-keygen -t dsa -b 1024

cat .ssh/id_dsa.pub >> .ssh/authorized_keys

```

----------

## eleanor

Hey, can I ask you how to create a dsa or rsa key pait in order nobody will be able to connect exept the one I'll sent that key to (I would sent it manually - ssh won't sent it avtomatically - so I'll use mail client for example to send that key to him and then he would save that key in ~/.ssh/ directory and the connection would be enabled? Is is possible?

----------

## truc

usually, it is the client who create the key and then give the public one to the server, this public key will be stored in ~/.ssh/authorized_keys where ~ is expanded as beeing the home directory of the client you're trying to login via ssh.. BTW, if the server create the key on its own (that's not the way is is supposed to be done AFAIK ) , I think the server has to send the public and the private key to the client (onthe server you'll still have to do 

cat .ssh/id_dsa.pub >> .ssh/authorized_keys  ) 

But doing this, are you aware you're opening a big security hole? I mean, the public key shouldn't leave the client computer...

----------

## nanoo

 *Quote:*   

> 
> 
> To get mine working I did a chmod 400 on the public key file. I also found that ssh - user caused problems for me (as it was not the user I was running as). I then did su - user and tried ssh -v hostname and that was cool.
> 
> 

 

That's very interesting - I was googling around last night, and I came across this issue with permissions (apparently sshd does not like it when anyone can have write access to the public key, which is understandable), but when I tried the suggested permissions I had the same result. Still, there was a little discrepancy between the various sources about what permissions were appropriate (some said 644, some 600 I think); I'll try 400 and see whether it works for me. I'll also try just:

```

ssh -v hostname

```

from the correct user - that's interesting (and unexpected, at least to me) that this caused problems. 

 *Quote:*   

> 
> 
> confcat /etc/ssh/sshd_config
> 
> Protocol 2
> ...

 

and it can't hurt to just try this setup and see whether it works for me. I can't put my finger on what in my config file is causing the weirdness, but this is certainly worth a try! 

Thanks to both of you for the posts.

Of course there are the usual work constraints  :Sad:  ...

I'll post back as soon as I get a chance to try those things.

Thanks again,

nanoo

----------

## truc

 *nanoo wrote:*   

>  *Quote:*   cat /etc/ssh/sshd_config
> 
> Protocol 2
> 
> AllowUsers truc someoneelse
> ...

 

Don't forget to replace with your real username  :Smile: 

 *Quote:*   

> 
> 
> Thanks to both of you for the posts.
> 
> 

 You're welcome  :Smile: 

----------

## nanoo

Yes!

Well I can't say that I'm entirely sure what the problem was, but moving to truc's sshd_config seemed to work! (I adjusted the AllowUsers, Port, and Subsystem parts to reflect my own system) Here is what I get now:

```

zoidberg@morbo ~ $ ssh -v morbo

OpenSSH_4.2p1, OpenSSL 0.9.7e 25 Oct 2004

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: Connecting to morbo [127.0.0.1] port 787.

debug1: Connection established.

debug1: identity file /home/zoidberg/.ssh/id_rsa type -1

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

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

debug1: match: OpenSSH_4.2 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

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

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 'morbo' is known and matches the RSA host key.

debug1: Found key in /home/zoidberg/.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,password,keyboard-interactive

debug1: Next authentication method: publickey

debug1: Trying private key: /home/zoidberg/.ssh/id_rsa

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

debug1: Server accepts key: pkalg ssh-dss blen 818

debug1: PEM_read_PrivateKey failed

debug1: read PEM private key done: type <unknown>

Enter passphrase for key '/home/zoidberg/.ssh/id_dsa':

```

Thanks so much again! This is a real load off my mind. I may continue to fool around with it to try to isolate where the problem was, but for now it's nice to have the pubkey authentication up and working. 

nanoo

----------

## truc

happy it works for you now  :Smile: 

BTW if on day you know what was wrong, I would be interested, since I really have no idea:)

----------

## cleber

Hi there!

Well, I am having the same problem, but even using truc's sshd_config, it's not working  :Sad: 

This is what happens:

If I generate the keys on my machine, and send the id_dsa.pub to another computer, it works. But if I copy this same key to my local authorized_keys2 and try to ssh localhost, it doesn't.

Also, if I do the same operation on the other computer, getting the public id_dsa.pub key and adding it to my authorized_keys, it doesn't work.

In other words, it works when I try to access the other computer, but it doesn't when I try to access mine.

I am accepting password authentication by now, so it output this (trying to ssh from other computer)

```
user@othercomputer ~/.ssh $ ssh localcomputer -v

OpenSSH_4.2p1, OpenSSL 0.9.7e 25 Oct 2004

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: Connecting to cleber.homeunix.org [x.y.w.z] port 22.

debug1: Connection established.

debug1: identity file /home/doisks/.ssh/identity type -1

debug1: identity file /home/doisks/.ssh/id_rsa type -1

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

debug1: Remote protocol version 1.99, remote software version OpenSSH_4.2

debug1: match: OpenSSH_4.2 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

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

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 'cleber.homeunix.org' is known and matches the RSA host key.

debug1: Found key in /home/doisks/.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,keyboard-interactive

debug1: Next authentication method: publickey

debug1: Trying private key: /home/doisks/.ssh/identity

debug1: Trying private key: /home/doisks/.ssh/id_rsa

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

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

debug1: Next authentication method: keyboard-interactive

Password:

```

Does any body knows if there is another configuration file or something that prevents ssh from alowing public key authentication?

----------

## truc

 *cleber wrote:*   

> Hi there!
> 
> Well, I am having the same problem, but even using truc's sshd_config, it's not working 
> 
> This is what happens:
> ...

 

Could you be a bit more clear on who is the server, and who is the client? also, keep in mind, that it is the public key, that you have to paste from the client (in the someting.pub file) to the server (in the authorized_keys)

----------

## cleber

 *Quote:*   

> Could you be a bit more clear on who is the server, and who is the client? also, keep in mind, that it is the public key, that you have to paste from the client (in the someting.pub file) to the server (in the authorized_keys)
> 
> 

 

Sure.

I'm testing on 2 machines:

[*] Server A

[*] Server B

I made the keys from Server A, and exported the id_dsa.pub to Server B. This way I am able to log in into Server B using public keys.

But when I do the same thing for Server B, that is, generate the key with 

```
ssh-keygen -t dsa -b 1024
```

, and export the id_dsa.pub to Server A (into ~/.ssh/authorized_keys2), I unable to connect to Server A using Public Key.

Also, if I copy Server A id_dsa.pub to Server A .ssh/authorized_keys2 (localhost, in this case), it doesn't work either.

So, it works when connecting to Server B, but not when I'm trying to connect to server A.

All of this using the sshd_config file that was posted before on this thread.

So my question is, is there any other configuration file that prevents sshd from accepting public key authentication?

----------

## truc

[why_not] trying to use ~/.ssh/authorized_keys instead of ~/.ssh/authorized_keys2 [/why_not]

did you modified the ListenAdress inf sshd_config? Are you using the good user?(the one you've just configured)

No more idea sorry  :Sad: 

----------

## cleber

I tried both authorized_keys and authorized_keys2, without success.

Also, the config file is identical to your post (truc)...

I'm not sure what's happening. This machine instalation is verry old (~2003), and I'm keeping it up to date with emerge worlds, may be it's a time for a re-install  :Smile: 

I'll try to figure out what's happening, and will post back if I got any clues.

Thanks!

----------

## truc

You shouldn't have to reinstall !

You should look into ssh_config in /etc/ssh/, and into ~/.ssh/ssh_config if you have. ( this one on the server A), you could also made one post with all this config files (ssh & sshd)

----------

## cleber

/etc/ssh/sshd_config

```
Protocol 2

AllowUsers user1 user2

ServerKeyBits 1024

LogLevel VERBOSE

PermitRootLogin no

MaxAuthTries 3

IgnoreRhosts no

#PasswordAuthentication no

X11Forwarding yes

MaxStartups 3

Subsystem sftp /usr/libexec/sftp-server
```

I've commented out the Password authentication, as the public key is not working, but I still need to log in  :Wink: 

And the /etc/ssh/ssh_config file have all the lines commented.

Can you tell me where is that sshd logs? Is it /var/log/messages? It's not logging anything in there...

It would be easier to understand what's happening if I could see what sshd is receiving and etc. The log (parameter -v) from the ssh client just says that is sends the key, and then try other authentication method...

Thanks

----------

