Well I can't seem to get it to work, and I was wondering, what, if it is the case, did I do wrong in the sshd_config file:

+++++++++++++++++++++++
Package generated configuration file
# See the sshd(8) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2

# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key

#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 2048

# Logging
SyslogFacility AUTH
LogLevel INFO

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

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

UsePAM no
+++++++++++++++++++

If this is wrong, then where else do I set it up and where do I copy my keys (from my client)?

Your config file is missing the comments with full instructions:
Also check the permissons of ~/.ssh/, your home directory & ~/.ssh/id_rsa. And append the public key to the servers ~/.ssh/authorized_keys file.

Then log in with the "-vv" option. Read the results on what failed. Also check the log on the server.

Hi SuperDude,

Please tell us more specifically what doesn't work. What are you trying to do? What did expect to happen? What happened instead? Why do you think you should do anything in the sshd_config file?

Jschival assumes you wanted to turn on PAM authentication.

If you want to log in without typing a password, jschival is correct. For investigating, I'd suggest running "sshd -d" on the server, maybe on a high port. If any of the things jschival suspects are wrong, it will tell you very clearly what's wrong.

/Quigi

What I expected to happen was after doing ssh user@serverIP, I would be asked for the pass phrase to the Key, then followed by a promp for the password for user or no password at all.

Now when I ssh in to it, what happens is I simply get asked for the password to user, and that's it. I don't think, or at the very most, I don't know if its using the keys that I generated on my mac and transfered over to my server.

Is their a way to see if the keys are being used or if the system is running all the correct processes?

OK, I'm lost. What are you trying to achieve?

You mention keys. I thought you meant the kind generated by ssh-keygen, but you'd typically used those so you can log in to a server without supplying a password. But you say you expect a prompt for the user's password. So I must be misunderstanding.

What kind of keys are you talking about? How did you generate and transfer them? If you mean RSA or DSA keys generated by ssh-keygen after all, run "ssh -v server". E.g., I have ~/.ssh/id_dsa, and when I run with "-v", I see this debugging output:
Here, type -1 (minus one) means the file wasn't found. The "identity file" part refers strictly to the client; at this point it doesn't matter whether you transferred anything to any server.

Ssh asks for the pass phrase for the key unless that pass phrase is empty.

/Quigi

The comments I posted explain how to use PAM for session control, but use the public key for authentication.
The two settings given at the end of the comments are the same as your settings. IMHO, if the server uses PAM for regular logins, then using "UsePAM yes" makes sense to have the same session controls that a local login would have.

When you created your key pair on the client, did you include a pass-phrase? The use of the passphrase unlocks the private key on the client. It has nothing to do with the server's configuration. As a matter of fact, you could use the same public key on several servers, and unlock it the same way. If you need to contact different ssh servers, or will log in more than once per shell session, you may find using ssh-agent and ssh-add convenient. Look at the manpage for ssh-keygen. You can still use ssh-keygen to add a pass phrase to lock your private key.

---

Because you were asked for your regular username/password, even though the config file (/etc/ssh/sshd_config) disabled PasswordAuthentication, and ChallengeResponceAuthentication, I'm wondering if what you posted is the sshd_config file from the server or the client. You need to edit the server's sshd_config. I'm not home now, so I can't check my sshd_config, but as far as I can tell, the only difference between your sshd_config file and mine is I use "UsePAM yes" and have my user name in an "AllowUsers" entry. This will disallow other users, which includes system users. This is an easy way to protect against brute force attacks against system users. Script kiddie attacks will try root, and know system user names.

Another possibility is that the startup script for the server's sshd service uses a different config file. You can either read the startup script, or look in /proc/<PID of sshd>/cmdline and see if the -f <config_file> option was used to load the configuration from a non-default location.

Yet another possibility is if on the server, sshd is controlled by xinetd. You will need to check for an /etc/xinet.d/sshd configuration. Even if there is such a file, the service via xinetd may be disabled.

SuperDude,

You might want to try ssh -vvv user@host, copy all of the debug up til it asks you for your password, and paste it back to us. You can just ctrl + c out of it at that point and wait.

Make sure you have already performed the following:

ssh-keygen -b 2048 -t rsa
( That will generate your key with 2048 Bit RSA )
*insert passphrase*

Now, in order to login to the other box, the user you are logging in as has to have in their ~/.ssh/authorized_keys file, the contents of your freshly generated ~/.ssh/id_rsa.pub.

There is a pretty sweet utility to automate this for you called ssh-copy-id and its usually installed by default on just about any distro i have tried to use it on.

Also, make sure you are loading your keys. Try the following:

ssh-agent sh -c 'ssh-add < /dev/null && bash'

That will load them up for you. Once you have completed all of the above, you should be well on your way to sshing it up with keys .

------------------------------------
Michael Piekarski
Network Engineer
mpiekarski@hostmysite.com
www.hostmysite.com