Re: Is OpenSSH 3.5p1 secure?
From: Zaakarij Selassij (zaakarij@broken.org)
Date: 02/06/03
- Next message: BAG: "Re: Vexing issue w/no password, identity file-based authentication"
- Previous message: BAG: "User Configuration Problem"
- In reply to: William Peckham: "Re: Is OpenSSH 3.5p1 secure?"
- Next in thread: TrackerLot: "Re: Is OpenSSH 3.5p1 secure?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: zaakarij@broken.org (Zaakarij Selassij) Date: 6 Feb 2003 10:07:40 -0800
Some comments on William's text and some further recommendations for
you:
> 1. Do not allow root access over ssh.
This is very good advice as this, in conjunction with proper privilege
separation, goes a long way to reducing the exposure of your root
account (there is an entire discussion on this topic with the subject
of "PermitRootLogin=yes versus su" from just before this thread was
created).
> 2. Do allow access over ssh for one and only one user.
Or allow access to a specific group (sshusers, for example) using the
'AllowGroups' directive, and then manually add or remove users to/from
this group as you see fit - this will allow you to manage your user
access w/o having to HUP the sshd.
> 3. Use only private key (not password) authentication.
There are numerous authentication methods available to you via PAM...
_public_ (William's post above is likely just a typo) key auth is not
necessarily the strongest method or the most manageable, but it can be
substantially stronger than password auth so long as you protect your
private key with adequate encryption and an adequate decryption
challenge (this can be quite difficult on a distributed basis, but
since you're the only user you have to worry about then you shouldn't
have a problem).
Here are a couple specific recommendations for you that you may wish
to consider:
1. Remove both the reference to the Protocol 1 RSA key (HostKey
$PATH/ssh_host_key) in sshd_config and the key itself (if you
generated it to begin with). It goes without saying that I'm assuming
you're not using protocol 1.
2. Make sure your Protocol 2 RSA or DSA sshd keys are at the very
least 1024 bit keys (there was a recent fuss about <=1024 bit RSA keys
when a paper by Shamir came out regarding a relatively inexpensive
cracking tool.. some ppl are recommending 2048+ bit keys, but there
are both pros and cons to differing key lengths).
3. Force the sshd to only accept strong ciphers - an example of this
would be to set ‘Ciphers' to "Ciphers aes256-cbc", and ‘Macs' to "Macs
hmac-sha1" in sshd_config.
4. And some explicit sshd_config recommendations (these may not all
apply to your situation, but they can help to strengthen security
nonetheless - refer to the sshd_config man page for explanations on
what each of these does and you'll likely be able to derive my reasons
for their settings):
a. PermitEmptyPasswords no
b. HostbasedAuthentication no
c. ChallengeResponseAuthentication no
d. PAMAuthenticationViaKbdInt no
e. IgnoreRhosts yes
f. IgnoreUserKnownHosts yes
g. RhostsAuthentication no (SSH1 only)
h. RhostsRSAAuthentication no (SSH1 only)
i. RSAAuthentication no (SSH1 only)
j. LoginGraceTime 20
k. MaxStartups 10:30:60
l. KeepAlive yes
m. StrictModes yes
n. UseLogin no
Using wrappers was mentioned by someone as well; this is useful to you
even if you do come from a wide variety of hosts as you can use it to
blackhole known offenders so that they are unable to even reach the
sshd if or when a remote exploit comes about. This may not be the
most robust method, but I think that you really ought not discount it
out-of-hand.
Willem goes on to make other good points, so if you take everything
that people have said in this thread into consideration then you
should be pretty well off.
One last thing; it's wise to modify your ssh_config file as well even
though local users can override the settings at run-time. The reason
for this is simple: users must knowingly inhibit the default security
of the system for outbound connections.
I hope this helps,
-zaakarij
> NOTHING is perfectly secure. Anything can be made MORE secure by running it
> as securly as possible. The defaults in the most recent ssh versions are
> pretty good, but you have to evaluate your settings based upon your
> environment. Even old 'risky' versions of ssh are many times more secure
> than unencrypted telnet and ftp traffic and services! No matter how good
> the software, if you configure a backdoor you have no one else to blame if
> someone exploits it. If you decide you want to ANYWAY, be aware of the
> risks and take reasonable precautions.
> > Thank you guys... but you're both wrong :-)
> > I ussualy use only one account (and that is root account...) to log in,
> and
> > there is nobody else who use ssh on my server box. So in fact there is no
> > use restricting that in AllowUser directive. What I ask you is how to
> > protect sshd against exploits that can be used by hackers. They don't have
> > accounts on my box, so setting AllowUser won't change anything. I just
> want
> > to be sure that they won't use some trivial security hole to grant root
> > priviliges, without knowing the password of course. So are there any
> > directives that should be set so as to keep sshd secure? I've already set
> > UsePrivilegeSeparation. I've also heard something about AuthBSD....
> >
> > ArteQ
> >
- Next message: BAG: "Re: Vexing issue w/no password, identity file-based authentication"
- Previous message: BAG: "User Configuration Problem"
- In reply to: William Peckham: "Re: Is OpenSSH 3.5p1 secure?"
- Next in thread: TrackerLot: "Re: Is OpenSSH 3.5p1 secure?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
