On Tue, 15 Jul 2008 08:53:18 -0700, c wrote:

> Folks,
>
> We have some devious developers that use ssh between two Solaris
> servers.
>
> They run ssh-keygen -t rsa etc etc and set up their auto login between
> the two servers.
>
> Is there a setting in /etc/ssh/sshd_config that I can change to ALWAYS
> ask for a password and prevent ssh from using public/private key
> authentication ?
>
> We'd ideally like to be able to rotate the passwords after the
> developers leave and not leave this potiental for a back door into our
> systems. Disabling ssh is not an option as we ( root users ) use it all
> the time..

For OpenSSH I believe that one can add an entry to the
sshd_config file to control this.

Are you positive that you want to do this though? Password
authentication is far less secure than public key authentication, and
when your developers leave you can remove from your system the public
they used in order to log in passwordless.

c writes:

> Folks,
>
> We have some devious developers that use ssh between two Solaris
> servers.
>
> They run ssh-keygen -t rsa etc etc and set up their auto login between
> the two servers.
>
> Is there a setting in /etc/ssh/sshd_config that I can change to ALWAYS
> ask for a password and prevent ssh from using public/private key
> authentication ?
>
> We'd ideally like to be able to rotate the passwords after the
> developers leave and not leave this potiental for a back door into our
> systems. Disabling ssh is not an option as we ( root users ) use it
> all the time..
>
> Bit new to this so please bear with me.

You are attempting to implement a technical control on a people issue,
and actually may end up making things less secure in the process. :-)

The good news is that these developers aren't weakening your security,
more than likely.

Key based auth is actually more secure than password auth as it
resists brute force attacks much better. If you've checked log files
for any sshd on the internet, you know that brute force attacks are
out there in force!

I believe your primary concern should instead be sure that these
developers have protected their private keys with a passphrase that's
not trivially broken, and that their keys are not world readable
(though I'm not sure if openssh will even use such keys).

This brings up the interesting question of whether there are tools to
audit those.

By the way, I work on a hgihly secured system for a client, and that
one WONT't allow anything but key based auth. Password based auth is
disabled by administrative choice. Key based auth is where it's
at.


--
Todd H.
http://www.toddh.net/

On 15 Jul, 19:39, comph...@toddh.net (Todd H.) wrote:

> Key based auth is actually more secure than password auth as it
> resists brute force attacks much better. * If you've checked log files
> for any sshd on the internet, *you know that brute force attacks are
> out there in force!

Survey says.... maybe not. Many lazy programmers use passphrase-less
SSH keys for all sorts of inappropriate system access. And the
behavior of ssh-keygen to allow such passwords, by default, by simply
refusing to type in a passphrase contributes heavily to the problem,
and to the attitude, that merely using SSH keys makes things secure.

Having an unprotected SSH key is as bad as taping your password under
your keyboard, and they're much easier to steal off of backup tapes or
NFS shares. If you're somewhat aggressive about your site security,
it's a good policy to check user's .ssh/ directories for password-free
keys.

Nico Kadel-Garcia writes:

> On 15 Jul, 19:39, comph...@toddh.net (Todd H.) wrote:
>
>> Key based auth is actually more secure than password auth as it
>> resists brute force attacks much better. * If you've checked log files
>> for any sshd on the internet, *you know that brute force attacks are
>> out there in force!
>
> Survey says.... maybe not. Many lazy programmers use passphrase-less
> SSH keys for all sorts of inappropriate system access. And the
> behavior of ssh-keygen to allow such passwords, by default, by simply
> refusing to type in a passphrase contributes heavily to the problem,
> and to the attitude, that merely using SSH keys makes things secure.
>
> Having an unprotected SSH key is as bad as taping your password under
> your keyboard, and they're much easier to steal off of backup tapes or
> NFS shares. If you're somewhat aggressive about your site security,
> it's a good policy to check user's .ssh/ directories for password-free
> keys.

Which, if you read the rest of my post other than what you trimmed and
quoted, you'd see I agree with as well.


--
Todd H.
http://www.toddh.net/

On 16 Jul, 05:19, comph...@toddh.net (Todd H.) wrote:
> Nico Kadel-Garcia writes:
> > On 15 Jul, 19:39, comph...@toddh.net (Todd H.) wrote:
>
> >> Key based auth is actually more secure than password auth as it
> >> resists brute force attacks much better. * If you've checked log files
> >> for any sshd on the internet, *you know that brute force attacks are
> >> out there in force!
>
> > Survey says.... maybe not. Many lazy programmers use passphrase-less
> > SSH keys for all sorts of inappropriate system access. And the
> > behavior of ssh-keygen to allow such passwords, by default, by simply
> > refusing to type in a passphrase contributes heavily to the problem,
> > and to the attitude, that merely using SSH keys makes things secure.
>
> > Having an unprotected SSH key is as bad as taping your password under
> > your keyboard, and they're much easier to steal off of backup tapes or
> > NFS shares. If you're somewhat aggressive about your site security,
> > it's a good policy to check user's .ssh/ directories for password-free
> > keys.
>
> Which, if you read the rest of my post other than what you trimmed and
> quoted, you'd see I agree with as well.
>
> --
> Todd H.http://www.toddh.net/

I'm sorry, Todd, for missing the details of your post. I do agree with
you on most of it as well.

But you commented on weak keys: I will stand by my concern over the
existing, common practice of using *no* passphrase on keys. It drives
me nuts, and is one of the most common mistakes. I've had an
unfortunate security conversation with several Sourceforge
contributors about *NOT* storing their password free keys on NFS
shares. The rampant mishandling of SSH keys, and the storage of HTTP/
HTTPS/svnserve keys in plain text locally, are someof my big problems
with Subversion itself as a source control system, and why I'm
studying up on git right now.

You also missed that 'not readable' for SSH keys is nowhere enough
protection. NFS shares of home directories are pretty trivially
readable by anyone, and backup tapes can and do get perused by others.
This sort of thing is why I'm more eager than ever to pursue single-
sign-on Kerberized authentication, for SSH users especially. There's a
Putty variant that supports this now, and it's scheduled to go into
the next Putty release if I remember Simon Tatham's comments on this
correctly. And I'm pursuing it for RHEL use.

Todd H. ha scritto:
> c writes:
>
> You are attempting to implement a technical control on a people issue,
> and actually may end up making things less secure in the process. :-)
>
> The good news is that these developers aren't weakening your security,
> more than likely.
>
> Key based auth is actually more secure than password auth as it
> resists brute force attacks much better. If you've checked log files
> for any sshd on the internet, you know that brute force attacks are
> out there in force!
>
> I believe your primary concern should instead be sure that these
> developers have protected their private keys with a passphrase that's
> not trivially broken, and that their keys are not world readable
> (though I'm not sure if openssh will even use such keys).
>
> This brings up the interesting question of whether there are tools to
> audit those.
>
> By the way, I work on a hgihly secured system for a client, and that
> one WONT't allow anything but key based auth. Password based auth is
> disabled by administrative choice. Key based auth is where it's
> at.

You forgot that system password can be locked (even automatically on
expire time) using standard user-management tools.
Public key must be removed or renamed manually.

The problem can be avoided if OpenSSH will implement a feature that
optionally can require _both_ key and password authentication, as Tectia
or F-Secure ssh implementations do.

On 16 Jul, 09:24, brontolo wrote:
> Todd H. ha scritto:
>
>
>
> > c writes:
>
> > You are attempting to implement a technical control on a people issue,
> > and actually may end up making things less secure in the process. *:-)
>
> > The good news is that these developers aren't weakening your security,
> > more than likely.
>
> > Key based auth is actually more secure than password auth as it
> > resists brute force attacks much better. * If you've checked log files
> > for any sshd on the internet, *you know that brute force attacks are
> > out there in force!
>
> > I believe your primary concern should instead be sure that these
> > developers have protected their private keys with a passphrase that's
> > not trivially broken, and that their keys are not world readable
> > (though I'm not sure if openssh will even use such keys).
>
> > This brings up the interesting question of whether there are tools to
> > audit those.
>
> > By the way, I work on a hgihly secured system for a client, and that
> > one WONT't allow anything but key based auth. *Password based auth is
> > disabled by administrative choice. * *Key based auth is where it's
> > at.
>
> You forgot that system password can be locked (even automatically on
> expire time) using standard user-management tools.
> Public key must be removed or renamed manually.
>
> The problem can be avoided if OpenSSH will implement a feature that
> optionally can require _both_ key and password authentication, as Tectia
> or F-Secure ssh implementations do.

Have you successfully used this?

There are plenty of procedures, such as rsync over SSH based backup
procedures and Subversion access, that do require unattended access.
It's the sort of thing that makes me wish that chroot cages had been
properly implemented for OpenSSH 5. (All chroot users having the same,
shared chroot cage is fairly nutty: the paches to support per-user
chroot cages have been around for years, and I'm confused why those
weren't used.)

Nico Kadel-Garcia ha scritto:
> Have you successfully used this?

Oh, yes! I run for years sshd2 from SSH Communication on several
servers, including one used for a commercial web hosting service.

> There are plenty of procedures, such as rsync over SSH based backup
> procedures and Subversion access, that do require unattended access.
> It's the sort of thing that makes me wish that chroot cages had been
> properly implemented for OpenSSH 5. (All chroot users having the same,
> shared chroot cage is fairly nutty: the paches to support per-user
> chroot cages have been around for years, and I'm confused why those
> weren't used.)

Tectia offers specific sub configuration on per-user or per-host basis.
So, you can allow a batch user to access only with key (or only with
password) enforcing other restriction.

On Tue, 15 Jul 2008 18:14:27 -0700 (PDT) Nico Kadel-Garcia wrote:
| On 15 Jul, 19:39, comph...@toddh.net (Todd H.) wrote:
|
|> Key based auth is actually more secure than password auth as it
|> resists brute force attacks much better. ? If you've checked log files
|> for any sshd on the internet, ?you know that brute force attacks are
|> out there in force!
|
| Survey says.... maybe not. Many lazy programmers use passphrase-less
| SSH keys for all sorts of inappropriate system access. And the
| behavior of ssh-keygen to allow such passwords, by default, by simply
| refusing to type in a passphrase contributes heavily to the problem,
| and to the attitude, that merely using SSH keys makes things secure.
|
| Having an unprotected SSH key is as bad as taping your password under
| your keyboard, and they're much easier to steal off of backup tapes or
| NFS shares. If you're somewhat aggressive about your site security,
| it's a good policy to check user's .ssh/ directories for password-free
| keys.

Maybe more people would do this if the agent were easier to work with.
I tried it several years ago and it really just didn't work right. No
one helped, so I gave up on it. Biggest issue (but not the only one)
was making sure each ssh client could find the agent. Something better
than an environment variable is needed.

--
|WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
| by the abuse department, bellsouth.net is blocked. If you post to |
| Usenet from these places, find another Usenet provider ASAP. |
| Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

c writes:
>We'd ideally like to be able to rotate the passwords after the
>developers leave and not leave this potiental for a back door into our
>systems.

In that case I would, if I were you, focus on the issue of access after the
developers leave.

For that, nothing beats deleting their accounts. When people leave, to avoid
having them log in to your computers, delete their accounts.

Note that you can delete the account by removing the line from /etc/passwd
without deleting its home directory, if you're concerned that there might be
valuable source code which they forgot to check in, etc.

But I suspect from your phrasing that you might have group accounts with
passwords known to multiple people. I think that this is the problem here.
Each account should have one user, only. When that person leaves, rather than
changing the password and giving the account to someone else, the account
should be deleted.

It's easy and cheap to create and delete accounts. It's difficult to manage
multi-user accounts.

Last month, Nico Kadel-Garcia wrote:
> This sort of thing is why I'm more eager than ever to pursue single-
> sign-on Kerberized authentication, for SSH users especially. There's a
> Putty variant that supports this now, and it's scheduled to go into
> the next Putty release if I remember Simon Tatham's comments on this
> correctly.

Nico, you may be interested to hear that the Kerberos patch we've
been polishing was committed into the PuTTY source control
repository yesterday, and last night's nightly build completed
successfully. So the current development snapshots should now
support Kerberos, if you're lucky. Testing and comments would be
welcome!
--
Simon Tatham "_shin_, n. An ingenious device for
finding tables and chairs in the dark."