CentOS 6 with Hiawatha initial setup ssh agent problems

Question

I have a VPS that I have installed cmake, and Hiawatha on to without problems. The ip address provides a webpage when viewed in the browser so that is working fine.

My document root is to be loaded from my git repository on assembla.com.

I am running the console remotely as the VPS root user. Let me show how I am trying to do this.

Step 1:

[root@server /]$ cd .\
[root@server ~]$ cd .ssh/id_rsa

Then I remove all keys since I've already messed with them and failed I'll start clean.

[root@server id_rsa]$ rm -f *
[root@server id_rsa]$ dir    ->(and nothing comes up)
[root@server id_rsa]$ ssh-keygen -t rsa -f mykey
[root@server id_rsa]$ dir    ->(mykey    mykey.pub)

Let's say I make the password be dog1234 and enter it once for each prompt.

[root@server id_rsa]$ cd ../
[root@server .ssh]$ chmod 600 -R id_rsa

Now to check to see what ssh-agents are running...

[root@server .ssh]$ ps aux | grep ssh

The output is...

root     29700  0.0  0.0  57704   764 ?        Ss   00:32   0:00 ssh-agent
root     29718  0.0  0.0  57704   724 ?        Ss   00:38   0:00 ssh-agent
root     29782  0.0  0.0  57704   768 ?        Ss   01:32   0:00 ssh-agent -s
root     29884  0.0  0.0  57704   752 ?        Ss   02:03   0:00 ssh-agent -s
root     29893  0.0  0.0 103248   844 pts/0    S+   02:17   0:00 grep ssh

The last one is the command I ran to check these. In keeping clean starts in mind I kill each of those PIDs...

[root@server .ssh]$ kill 29700
[root@server .ssh]$ kill 29718
[root@server .ssh]$ kill 29782
[root@server .ssh]$ kill 29884

To verify that it killed them...

[root@server .ssh]$ ps aux | grep ssh

The output once again...

root     29899  0.0  0.0 103248   848 pts/0    S+   02:22   0:00 grep ssh

Which is the grep command itself. If i try to kill 29899 it says it doesn't exist, which is correct since the command has already finished executing and it is not an ssh agent.

Now this is most likely where things go bad. First, I want to make notice of the fact that this terminal behaves differently being CentOS than ubuntu, which I am used to. For some reason, any command that has a question that requires a yes or no response causes current processes from terminal commands to break and stop.

For example when I did the command earlier:

ssh-keygen -t rsa -f mykey

I added -f mykey to name the file. If I waited for the prompt to enter a name it fails. Does anyone know why this is happening? Is it because I am connected to the server remotely? Is this a possible reason that my password (which I am about to get to) isn't working?

Now I start the ssh-agent since I killed them all.

[root@server .ssh]$ eval `ssh-agent`

Output...

Agent pid 29910

Then...

[root@server .ssh]$ cd id_rsa
[root@server id_rsa]$ ssh-add -l

Output...

The agent has no identities.

Now I need to add them.

[root@server id_rsa]$ ssh-add mykey.pub

This is where I don't understand what's happening.

[root@server id_rsa]# ssh-add mykey.pub
Enter passphrase for mykey.pub:
Bad passphrase, try again for mykey.pub:
Bad passphrase, try again for mykey.pub:
Bad passphrase, try again for mykey.pub:
Bad passphrase, try again for mykey.pub:
Bad passphrase, try again for mykey.pub:
Bad passphrase, try again for mykey.pub:

I am entering dog1234 as the password, and this appears to keep on going indefinitely.

Config file...

vim /etc/ssh/sshd_config

#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
#AuthorizedKeysCommand none
#AuthorizedKeysCommandRunAs nobody

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

# 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
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

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

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding 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
#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 server

Lastly, I do not have an authorized_keys folder in the .ssh directory. All of the things I have found in other questions do not seem to work.

Why can I not add the identity?

Answer 1

It looks like you might be backwards.

ssh-add adds an identity, which is your private key, to your authentication agent on the box you're typing into the terminal on. ssh will later use this to authenticate to a remote host. However, as often as not you don't need to do this and can simply copy the id_rsa file into place in ~/.ssh/ (and set its mode chmod 400). This file is often encrypted (a wise choice), but in this case it's not a private key so of course you can't decrypt it.

The file ending in .pub is your public key. You would provide this to the remote GIT host or whatever else you are authenticating to. You don't need to keep this value private; you can share it among all the people to whom you authenticate. They have a 1:1 correspondence with private keys.

When you specify the -f option to ssh-keygen, it doesn't touch id_rsa. You will have to put the generated private key in place yourself. You can also specify an option (I believe it's -i for identity file) to ssh to specify an alternative identity (the one you just created) when authenticating. However, since I am sure your web service is running with its own service account it should be perfectly OK to not do this and just use the default path ~/.ssh/id_rsa.

I don't believe ~/.ssh/id_rsa is supposed to be a directory. In my experience, it is a file containing one private key.

Answer 2

You are generating the key mykey in a non standard directory ~/.ssh/id_rsa which doesn't help with people's understanding of your problem.

You also seem to be trying to add the public mykey.pub file to ssh-agent when you need to add the private mykey file. man 1 ssh-agent refers.

ssh-agent is a program to hold private keys used for public key authentication (RSA, DSA)

Note the next bit of the man page too

The idea is that ssh-agent is started in the beginning of an X-session or a login session, and all other windows or programs are started as clients to the ssh-agent program.

Clean up what you've already done, delete ~/.ssh/id_rsa and it's contents then kill all the ssh-agent processes, if you have other keys in ~/.ssh then temporarily remove them, then try this

$ cd ~/.ssh $ ssh-keygen -t rsa -f mykey Generating public/private rsa key pair. Enter passphrase (empty for no passphrase):dog1234 Enter same passphrase again:dog1234 Your identification has been saved in mykey. Your public key has been saved in mykey.pub. ...

So now you have a public key mykey.pub and a private key mykey. Copy the public key to wherever you need it to be, I've put mine remote_host in ~/.ssh/authorized_keys which has the permissions appropriately set.

To test your newly generated keys

ssh user@remote_host -i ~/.ssh/mykey
Enter passphrase for key '/home/user/.ssh/mykey':dog1234
Last login: Tue Dec 10 09:04:56 2013 from 2001:470:1f09:6e5:225:dead:beef:9c04
$ exit

good so the keys work as expected, let's get the ssh-agent sorted. Remember what the man page said

The idea is that ssh-agent is started in the beginning of an X-session or a login session, and all other windows or programs are started as clients to the ssh-agent program.

To test ssh-agent lets run a bash shell that can access the ssh-agent

$ ssh-agent bash
$ ssh-add -l
The agent has no identities.

$ssh user@remote_host
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Note that the above fails because we didn't supply a key file to ssh with -i mykey and we haven't yet added a key to the ssh-agent.

ssh-add ~/.ssh/mykey
Enter passphrase for /home/user/.ssh/mykey:dog1234 
Identity added: /home/user/.ssh/mykey (/home/user/.ssh/mykey)

So test it

ssh user@remote_host Last login: Tue Dec 10 09:18:00 2013 from 2001:470:1f09:6e5:225:dead:beef:9c04

ta dar! working as expected because ssh got the key from the agent.