I have put together a few notes on how to use public key authentication
with SSH.

http://www.edafe.org/slack.html#authentication

Is this way of setting up sshd safe, or have I perhaps misconfigured
something?

Regards,
Edafe

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In alt.os.linux.slackware, Edafe Knabe dared to utter,
> I have put together a few notes on how to use public key authentication
> with SSH.
>
> Is this way of setting up sshd safe, or have I perhaps misconfigured
> something?

Yeah it's safe. I assume you're worried that ssh no longer requires
your password to log you in, and that since anyone could conceivably
get your public SSH key, that anyone could log in as you if they have
it. That's not the case. Some one must have your public AND your
private key to authenticate. The public key is useless without the
private key (and vice-versa). As long as your private key is safe and
sound, everything should be fine. From what I understand (and I may be
wrong), it's quite a bit more difficult to determine the proper private
SSH key even if you know the public key than it is to brute force an
MD5 password.

- --
It is better to hear the rebuke of the wise,
Than for a man to hear the song of fools.
Ecclesiastes 7:5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB7/dElKR45I6cfKARAohuAKCkLdSFMtW/4iK/UqN0dAQKM0wLAgCghsw9
9mZl2MlxEEqkot8aUi3d6Cg=
=HpSi
-----END PGP SIGNATURE-----

On Thu, 20 Jan 2005 15:10:44 +0000, Edafe Knabe wrote:

> I have put together a few notes on how to use public key authentication
> with SSH.
>
> http://www.edafe.org/slack.html#authentication

Nice article.

> Is this way of setting up sshd safe,

That depends entirely upon what /exactly/ you're trying to protect againt.
Just a guess, your objective is to mitigate the automated user/password
pair scans? If so, then yes it's save.

Anyways just running the service on some random port (say 8765 or
whatever) and haveing your passwords resist "john the ripper" proably does
away with that also. And you wouldn't need to take any key with you, then...

If this was about the ability to use SSO with "ssh-agent" , then this is
indeed a fine setup. However, on a big LAN, Kerberos would be the prevered
method for this (that _does_ have key aging and central account management.)

> or have I perhaps misconfigured something?

Well administation might be a pain if you have lots of users, with:
``AllowUsers'' - so rather then using that, i would probably use:

AllowGroups ssh

vigr <- create a group "ssh" and put the allowed users in there...

But as far as the rest of the setup goes, no way to know. There will still
be some possibe attack angles, in your setup (as outlined). As it wouldn't
fore instance protect against direct attack to exploit the server
software, or a key-logger on the client you happen to connect from.

Some things you might consider doing could be configureing the buildin
tcpwrappers (libwrap) like in: /etc/hosts.deny - ALL : ALL
Then allow only machines _you_ ever connect from, like in /etc/hosts.allow

sshd : KNOWN@some.box.lan, some.other.box.com

Where "KNOWN" mandates an identd to be running on that client machine,
basically just read "man 5 hosts_access" for this.

To protect against key-lggers you might consider using OPIE or S/Key
(one-time passwords) which on Slackware would require a recompile of the
server software (Heimdal includes OTP as well, btw).

--
-Menno.

On Thu, 20 Jan 2005 19:52:38 +0000, Menno Duursma wrote:

> To protect against key-lggers you might consider using OPIE or S/Key

s/lggers/loggers/

> (one-time passwords) which on Slackware would require a recompile of the
> server software

Wait-up, most probably this isn't true. As you should be able to just
compile/install a replacement "login" with support for it. And have sshd
fire that off, rather then use it's build-in by uncommenting:

UseLogin yes

http://inner.net/opie
http://www.nas.nasa.gov/Groups/Security/OPIE/

I haven't tryed this (on Linux - FreeBSD has it default...) and you might
find if painfull to work with, or just not care for it. But just so you
know about it's availability.

HTH.

--
-Menno.

On Thu, 20 Jan 2005 18:24:07 -0000, +Alan Hicks+ <alan@lizella.netWORK> wrote:
> Some one must have your public AND your private key to authenticate.
> The public key is useless without the private key (and vice-versa).

That's not strictly true. To log into a remote system, the remote
system should have the public key, the local system should have the
private key and the user should have the passphrase. To log into the
remote system, only the private key and the passphrase are needed,
although there is no harm in the public key being on the local system.

I restrict how many machines have my private key and use ssh-agent,
along with ~/.ssh/config to decide whether I can then forward SSH
connections from that remote system to specific other systems.

> As long as your private key is safe and sound, everything should be
> fine.

That's precisely correct.

> From what I understand (and I may be wrong), it's quite a bit more
> difficult to determine the proper private SSH key even if you know
> the public key than it is to brute force an MD5 password.

For DSA keys, this is true. For RSA, and possibly DSA1, keys, I'm not
sure, although they are considered less secure than DSA.


--
Simon <simon@no-dns-yet.org.uk> **** GPG: F4A23C69
"We demand rigidly defined areas of doubt and uncertainty."
- Douglas Adams

On Thu, 20 Jan 2005 15:10:44 GMT, Edafe Knabe <no@mail.com> wrote:
> I have put together a few notes on how to use public key authentication
> with SSH.
>
> http://www.edafe.org/slack.html#authentication
>
> Is this way of setting up sshd safe, or have I perhaps misconfigured
> something?

That's fine (good, even). Depending on the type of network connection,
you may need to increase LoginGraceTime slightly. It can take longer
than 15 seconds on very slow/lagged connections.

Also, you might need to point out the format of the 'AllowUsers' line,
so that people don't lock themselves out.


--
Simon <simon@no-dns-yet.org.uk> **** GPG: F4A23C69
"We demand rigidly defined areas of doubt and uncertainty."
- Douglas Adams

On Thu, 20 Jan 2005 19:52:38 GMT, Menno Duursma <pan@desktop.lan> wrote:
> Some things you might consider doing could be configureing the buildin
> tcpwrappers (libwrap) like in: /etc/hosts.deny - ALL : ALL
> Then allow only machines _you_ ever connect from, like in /etc/hosts.allow
>
> sshd : KNOWN@some.box.lan, some.other.box.com

To add to this, I'd only use IP addresses in hosts.allow. Someone
running their own reverse DNS could conceivably set the reverse DNS for
their IP address to, for example, 'some.other.box.com', which would
mean that they then have more of a chance of getting into your machine.
This, of course, is only if your DNS setup in any way interacts with
the outside world, which most do.

Changing your own reverse DNS entry, when you handle your own reverse
DNS, is trivial and there are lots of people that I don't trust that
handle their own reverse DNS.


--
Simon <simon@no-dns-yet.org.uk> **** GPG: F4A23C69
"We demand rigidly defined areas of doubt and uncertainty."
- Douglas Adams

Simon wrote:

> On Thu, 20 Jan 2005 19:52:38 GMT, Menno Duursma <pan@desktop.lan> wrote:
>> Some things you might consider doing could be configureing the buildin
>> tcpwrappers (libwrap) like in: /etc/hosts.deny - ALL : ALL
>> Then allow only machines _you_ ever connect from, like in
>> /etc/hosts.allow
>>
>> sshd : KNOWN@some.box.lan, some.other.box.com
>
> To add to this, I'd only use IP addresses in hosts.allow. Someone
> running their own reverse DNS could conceivably set the reverse DNS for
> their IP address to, for example, 'some.other.box.com', which would
> mean that they then have more of a chance of getting into your machine.
> This, of course, is only if your DNS setup in any way interacts with
> the outside world, which most do.
>
> Changing your own reverse DNS entry, when you handle your own reverse
> DNS, is trivial and there are lots of people that I don't trust that
> handle their own reverse DNS.
>
>


It's worth blocking the appropriate port by default at the firewall as well.
Most decent firewalls allow sensible control of port access by connecting
host.

On Fri, 21 Jan 2005 10:38:02 +0000, Keith Matthews <invalid@frequentous.co.uk>
wrote:
[tcp_wrappers security]
> It's worth blocking the appropriate port by default at the firewall as well.
> Most decent firewalls allow sensible control of port access by connecting
> host.

I do that too (using iptables to configure netfilter). I like to use
as many layers of security as are possible & practical.


--
Simon <simon@no-dns-yet.org.uk> **** GPG: F4A23C69
"We demand rigidly defined areas of doubt and uncertainty."
- Douglas Adams

Thanks for all your replies.

From time to time I need to be able to connect to my server at home, as well
as administer a couple of machines remotely. I use ssh, because it seems
the most appropriate tool for this purpose.

The exclusive use of public key authentication hopefully eliminates the risk
of brute-force attacks.

Because I mostly connect over the internet from nodes obtaining their
respective IP addresses dynamically, I didn't think that using tcpwrappers
would be practical. Unfortunately, my firewall does not allow the control
of port access by connecting host, either (in truth, I didn't even know
such functionality was available).

Even though there are not many users to administer, using AllowGroups ssh
instead of AllowUsers username in sshd_config makes sense.

I increased the LoginGraceTime to 20.

As far as direct attacks to exploit the server software are concerned, my
hope is that by now OpenSSH will have few vulnerabilities left.
Furthermore, I regularly use slapt-get to obtain what updates are
available...

Are there any disadvantages to using a random port instead of port 22?

I have added a link to this thread.

http://www.edafe.org/slack.html#authentication

Thanks again,
Edafe