SSH Security

Craig321 · 21 Jan 2009 at 09:23

Hi,

I'm running an SSH server on my PC for remote access, it's been running for a while now with no problems and seems to be fairly secure.

However, as SSH gives full access to the computer could someone check that I haven't missed anything in the sshd_config file please? (can't restrict the hosts that connect to the server, I connect from a dynamic IP).

Code:

Port 443
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# Disable legacy (protocol version 1) support in the server for new
# installations. In future the default will change to require explicit
# activation of protocol 1
Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh_host_rsa_key
#HostKey /etc/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

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

# Authentication:

#LoginGraceTime 2m
PermitRootLogin no
StrictModes no
MaxAuthTries 2
#MaxSessions 10

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile	.ssh/authorized_keys

# For this to work you will also need host keys in /etc/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 no

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

#AllowAgentForwarding 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
#PermitTunnel no
#ChrootDirectory %h

# default banner path
Banner /etc/banner.txt

# override default of no subsystems
Subsystem	sftp	/usr/sbin/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#	X11Forwarding no
#	AllowTcpForwarding no
#	ForceCommand cvs server

Is there anything that I've missed security-wise there, or any stupid mistakes?

Thanks,
Craig.

daz · 21 Jan 2009 at 09:35

I would disable direct root login. You've also got SSH on a non standard port so that's good start too.

Mickey · 21 Jan 2009 at 09:41

Everything looks alright suppose, one thing you might want to consider (something I do) is only allowing a selected accounts to login from outside the local network. I use a special account with a stupidly long password, then you can su to any user you want once logged in.

The advantage of this is that even if someone knows your normal login details, or have their own account (for whatever reason), they still can't connect to your system remotely unless you allow them to.

You can do this easily by editing your access settings (should be something like /etc/security/access.conf) with settings similar to:

+:ALL:192.168.1.
+:usernameForExternalUse:ALL
-:ALL:ALL

Craig321 · 21 Jan 2009 at 09:41

daz said:
I would disable direct root login. You've also got SSH on a non standard port so that's good start too.

I think that should already be disabled with PermitRootLogin no - or does something else need to be put in there?

Mickey said:
Everything looks alright suppose, one thing you might want to consider (something I do) is only allowing a selected accounts to login from outside the local network. I use a special account with a stupidly long password, then you can su to any user you want once logged in.

The advantage of this is that even if someone knows your normal login details, or have their own account (for whatever reason), they still can't connect to your system remotely unless you allow them to.

You can do this easily by editing your access settings (should be something like /etc/security/access.conf) with settings similar to:

+:ALL:192.168.1.
+:usernameForExternalUse:ALL
-:ALL:ALL

Will do, I'm guessing that directory/file needs to be created manually - it's not there on mine?

Thanks,
Craig.

Mickey · 21 Jan 2009 at 10:05

Craig321 said:
Will do, I'm guessing that directory/file needs to be created manually - it's not there on mine?

Thanks,
Craig.

You should already have an access.conf somewhere, /etc/security/access.conf is where it is on debian.

Craig321 · 21 Jan 2009 at 13:36

Mickey said:
You should already have an access.conf somewhere, /etc/security/access.conf is where it is on debian.

Can't find it anywhere - running OpenSSH on cygwin

Mickey · 21 Jan 2009 at 13:57

Oh right, assumed you were running some sort of linux, sorry. No idea.

Craig321 · 21 Jan 2009 at 15:46

Mickey said:
Oh right, assumed you were running some sort of linux, sorry. No idea.

Unfortunately I'm not as I have a lot of Windows applications I need to run on the same server. I'd definitely go for Linux on the server if I could.

I thought cygwin emulated Linux anyway? I'm confused as to why that file doesn't exist :/

Craig321 · 21 Jan 2009 at 16:03

Oops double post.

BigglesPiP · 21 Jan 2009 at 17:40

Have you updated openssh (via the cygwin installer) since the Debian OpenSSL/OpenSSH fiasco? Including the subsequent list of blacklisted keys.

You could require both public key, and keyboard authentication. With a well generated key pair (on your client) then guard your client's private key like your life depends on it.

Most of all, keep an eye on the last login location which is printed whenever you login yourself.

Craig321 · 22 Jan 2009 at 00:22

Do you mean public key and keyboard authentication as in a normal username and password and then further authentication using the generated keys?

I'm currently using a key that requires a password when it's used.

Yep it's all updated, I installed SSH onto my new server a couple of days ago.

BigglesPiP · 22 Jan 2009 at 19:48

Something like that, yes, but the key bit comes 1st, then you login to the box.

Craig321 · 24 Jan 2009 at 13:29

OK

Thanks for the help.