Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm trying to setup SSH login on a CentOS 5.5 on an OpenITC VPS.

I should say this doesn't appear to have SELinux installed, as commands such as sestatus don't work.

I currently have two users, root and M. I wasn't sure where to put the authorised_keys file, so it's in both /root/.ssh/ and /home/M/.ssh and root is the owner of the former (and the file) and M is the owner of the latter (and the file). The folder permissions are 700 and the files are 600.

When I try and login with Putty Link (plink -v x.x.x.x), whether I try and login as root or M I get the following:

Looking up host "x"
Connecting to x port 22
Server version: SSH-2.0-OpenSSH_4.3
We claim version: SSH-2.0-PuTTY_Release_0.60
Using SSH protocol version 2
Doing Diffie-Hellman group exchange
Doing Diffie-Hellman key exchange with hash SHA-1
Host key fingerprint is:
x
Initialised AES-256 SDCTR client->server encryption
Initialised HMAC-SHA1 client->server MAC algorithm
Initialised AES-256 SDCTR server->client encryption
Initialised HMAC-SHA1 server->client MAC algorithm
Pageant is running. Requesting keys.
Pageant has 1 SSH-2 keys
login as: root
Trying Pageant key #0
Server refused public key

My /etc/ssh/sshd_config is:

#Port 22
#Protocol 2,1
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 1h
#ServerKeyBits 768

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
SyslogFacility AUTHPRIV
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6

AllowGroups root M
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 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

# 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 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
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
X11Forwarding yes
#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 /some/path

# override default of no subsystems
Subsystem   sftp    /usr/libexec/openssh/sftp-server
share|improve this question
add comment

2 Answers

up vote 4 down vote accepted

The file name is : authorized_keys, not authorised_keys.

/root/.ssh/authorized_keys ; 1z and 1s. 
share|improve this answer
    
Thanks. That's all it was! –  doveman Feb 8 '12 at 15:15
add comment

Make sure your rights on the server are correct:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

When using putty, make sure you converted your private key with puttygen.exe before giving it to putty!

If you are less restrictive about your public key, you could also edit the security to

chmod 644 ~/.ssh/authorized_keys
share|improve this answer
    
Thanks. I actually generated the keys with puttygen.exe and pasted it into the authorized_keys file. It's all working now anyway. So do I need authorized_keys in both /root/.ssh/ and /home/M/.ssh/ or if I have it only in /root/.ssh/ will both root and M be able to use it to login? –  doveman Feb 8 '12 at 15:17
    
All public keys in authorized_keys will allow those keys to be used to log on with that user. If you want to log in both users with the same key, both user needs them in their .ssh-folder. You might just want to disable root-login, as an added level of security. When you login with you`M`-Account you can always use su - to become root. –  Bart De Vos Feb 8 '12 at 15:34
1  
Thanks for explaining that. I probably will just disable the root account then. OpenITC provide a separate Recovery Console account that I can use if necessary anyway. –  doveman Feb 8 '12 at 16:47
    
I've disabled root-login and password auth now. This doesn't prevent logging in as root with the password via the Recovery Console though, which seems somewhat of a security hole. It doesn't seem like much could be done about it, as it requires me to login with the Recovery account first, before prompting me for a normal username/password. –  doveman Feb 9 '12 at 1:41
    
This is normal because the Recovery Console is using a serial console . This makes the 'physical' (tty1) console available via the Recovery Console but isn't based on ssh. Therefor, the settings you make, won't be noticeable via your Recovery Console. –  Bart De Vos Feb 9 '12 at 6:59
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.