Voytek wrote:
I just looked through some logs, and, see a lot of attempted access like:
# grep "illegal user" secure
Dec 29 10:10:11 koala sshd[20080]: input_userauth_request: illegal user jane
Dec 29 10:10:14 koala sshd[20080]: Failed password for illegal user jane
from 20
3.42.32.89 port 56720 ssh2
...
what should I do to increase security ?
There are a few steps, all worthwhile.
1) Don't make it insanely easy
/etc/ssh/sshd_config:
PermitEmptyPasswords no
PermitRootLogin no
People that want to do a root login can use sudo (config sudo's
/etc/suduers with
root ALL=(ALL) ALL
%wheel ALL=(ALL) ALL
and add those people to the "wheel" group).
2) Limit the acceptable users
Add a group, I use "ssh" (ie, groupadd -r ssh)
Add users allowed to ssh in to that group.
Configure sshd
AllowGroups ssh
3) Restrict IP addresses
Configure /etc/hosts.deny with
ALL: ALL
Configure /etc/hosts.allow with
ALL: 127.
ALL: [::1]/128
sshd: ALL
Modifying the sshd line to your particular access policy.
Obviously you might need more lines if you run other
services too. Monitor /var/log/secure and /var/log/messages.
4) Consider non-password authentication
I use public key authentication for most machines. This is
pretty easy to set up for a single user. The major restriction
is that you shouldn't use it for chains of logins like:
a> ssh b
b> ssh c
Then disable password authentication. Then all these password
scanners can't succeed because they are stopped at a most
basic level.
PasswordAuthentication no
KerberosAuthentication no
ChallengeResponseAuthentication no
What I'd really like from sshd is public key authentication and
then password authentication (ie, something you have, something
you know) but sshd can't do that.
----------------------------------
The documentation on setting up a remote public key account is really
poor. Here's the procedure (adapted from an AARNet internal procedure):
On your client
client$ scp .ssh/id_dsa.pub server.example.edu.au:tmp.pub
[EMAIL PROTECTED]'s password: **********
id_dsa.pub 100% 604 3.8MB/s 00:00
[
If you don't have a .ssh/id_dsa.pub then create one using
client$ ssh-keygen -t dsa
If you get complaints during key generation about lack of entropy
(common on lightly-loaded headless servers), then establish another
login session and force some disk activity (eg, du -s /).
]
Now connect to server.example.edu.au and add the client's public key
to the list of authorised hosts. Note US spelling:
client$ ssh server.example.edu.au
[EMAIL PROTECTED]'s password: **********
server$ cat tmp.pub >> .ssh/authorized_keys
server$ chmod a=,u=rw .ssh/authorized_keys
server$ rm tmp.pub
Don't log out (you might need a prompt if testing fails).
Test the connection
client$ ssh server.example.edu.au
Enter passphrase for key '/home/fab/.ssh/id_dsa': **********
Note that it is asking for the password for your client machine's ssh
private key (the password you typed when you first ran ssh-keygen on
the client machine), not your password for server.
You still need to know your server.example.edu.au password for running
sudo, as that's the only way to gain root short of logging on through
the console.
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
