Mailing List Archive

On Tue, Aug 31, 2010 at 10:51:08AM +0400, ???????? ???????????? wrote:
> I want to set ssh authorization through unix/pam with mandatory public
> key. I want will make sure that except the password the user has an
> acknowledgement of legitimacy in the form of a public key. Thus the
> password should be from unix/pam, not from key.
>
> I tried different variants. It turned out with key and without the
> password, or the password undertook from a key, instead of from
> unix/pam.

Public key authentication does not involve a password, and it does not
involve PAM.

If you are attempting to require the use of a passPHRASE on the private
key, then you need to be aware that the private key is only seen by the
ssh client, not the server. The server has no idea whether the key was
passPHRASE protected or not.

Server-side passWORDS have nothing at all to do with public key
authentication, or with the passPHRASES that are used to protect the
private keys.

We each other haven't understood.

I have adjusted authorization on a public key. But only two methods:

1. The server will authorize without the password (if the key formed
without the password).

2. The client ask the key password (if the key is protected by the password).

It is necessary for me:

1. What the client is mandatory had a public key without the password
without which the server won't pass the client.

2. That at authorization the client would ask the unix password of the
user on the server.

2010/8/31 Greg Wooledge <wooledg@eeg.ccf.org>:
> On Tue, Aug 31, 2010 at 10:51:08AM +0400, ???????? ???????????? wrote:
>> I want to set ssh authorization through unix/pam with mandatory public
>> key. I want will make sure that except the password the user has an
>> acknowledgement of legitimacy in the form of a public key. Thus the
>> password should be from unix/pam, not from key.
>>
>> I tried different variants. It turned out with key and without the
>> password, or the password undertook from a key, instead of from
>> unix/pam.
>
> Public key authentication does not involve a password, and it does not
> involve PAM.
>
> If you are attempting to require the use of a passPHRASE on the private
> key, then you need to be aware that the private key is only seen by the
> ssh client, not the server. šThe server has no idea whether the key was
> passPHRASE protected or not.
>
> Server-side passWORDS have nothing at all to do with public key
> authentication, or with the passPHRASES that are used to protect the
> private keys.
>



--
ó Õ×ÁÖÅÎÉÅÍ, éÌØÑ óËÏÒÉË
Yours faithfully, Ilya Skorik

Approximately so.

A problem that people from an enterprise network have access to the
server. And there is Windows in their network. Recently the virus has
stolen passwords at one of managers, has entered on the one of servers
and has download the bad software.

I would like will restrict access in case of simple larceny of
passwords by viruses, but I am not able to do it standard manner.
Because from server side all managers come from one ip addresses. Also
I don't want to setup authorization through a public key. Since it
isn't compatible with ldap authorization on the server. And managers
can come on the server without entering any passwords.

All that I want is a mandatory presence of a public key and standard
authorization with request of the password which is stored on the
server.


2010/8/31 Mark Naker <mnaker@gmail.com>:
> If I understand correctly, you are trying to use a public key setup in ssh
> that is passphrase protected by the destination hosts local password.š If I
> have not understood correctly, feel free to ignore the rest of this email.
>
> This is not possible in an easily configured and direct method.
>
> I have not set up ssh in this way, however, it should be possible to stack
> authentication methods in your PAM configuration such that first the
> publickey would be used, and then the machine would also ask for the local
> passord.š You will need to play around with the sshd_config file quite a
> bit.
>
> You may see a result where users have to enter their key passphrase, and the
> password of the destinataion system with a setup like this.
>
> It is also possible that you may have to write your own PAM module to handle
> authentication in this manner.
>
> Good luck!
>
>
>
> 2010/8/31 éÌØÑ óËÏÒÉË <ilya@skorik.me>
>>
>> We each other haven't understood.
>>
>> I have adjusted authorization on a public key. But only two methods:
>>
>> 1. The server will authorize without the password (if the key formed
>> without the password).
>>
>> 2. The client ask the key password (if the key is protected by the
>> password).
>>
>> It is necessary for me:
>>
>> 1. What the client is mandatory had a public key without the password
>> without which the server won't pass the client.
>>
>> 2. That at authorization the client would ask the unix password of the
>> user on the server.
>>
>> 2010/8/31 Greg Wooledge <wooledg@eeg.ccf.org>:
>> > On Tue, Aug 31, 2010 at 10:51:08AM +0400, ???????? ???????????? wrote:
>> >> I want to set ssh authorization through unix/pam with mandatory public
>> >> key. I want will make sure that except the password the user has an
>> >> acknowledgement of legitimacy in the form of a public key. Thus the
>> >> password should be from unix/pam, not from key.
>> >>
>> >> I tried different variants. It turned out with key and without the
>> >> password, or the password undertook from a key, instead of from
>> >> unix/pam.
>> >
>> > Public key authentication does not involve a password, and it does not
>> > involve PAM.
>> >
>> > If you are attempting to require the use of a passPHRASE on the private
>> > key, then you need to be aware that the private key is only seen by the
>> > ssh client, not the server. šThe server has no idea whether the key was
>> > passPHRASE protected or not.
>> >
>> > Server-side passWORDS have nothing at all to do with public key
>> > authentication, or with the passPHRASES that are used to protect the
>> > private keys.
>> >
>>
>>
>>
>> --
>> ó Õ×ÁÖÅÎÉÅÍ, éÌØÑ óËÏÒÉË
>> Yours faithfully, Ilya Skorik
>
>
>
> --
> :(){ :|:& };:
>



--
ó Õ×ÁÖÅÎÉÅÍ, éÌØÑ óËÏÒÉË
Yours faithfully, Ilya Skorik

ssh is not written to do that.

It authorizes on first successful authentication.

The closest thing you can do is distribute PKCS#11 compatible hardware
tokens and configure the ssh client to use the key from there.

This will implement two factor authentication.
1) the token (the key never leaves the token)
2) password authentication to the token to unlock access to use the key.

You do loose the LDAP auth in doing this.

2010/8/31 éÌØÑ óËÏÒÉË <ilya@skorik.me>:
> Approximately so.
>
> A problem that people from an enterprise network have access to the
> server. And there is Windows in their network. Recently the virus has
> stolen passwords at one of managers, has entered on the one of servers
> and has download the bad software.
>
> I would like will restrict access in case of simple larceny of
> passwords by viruses, but I am not able to do it standard manner.
> Because from server side all managers come from one ip addresses. Also
> I don't want to setup authorization through a public key. Since it
> isn't compatible with ldap authorization on the server. And managers
> can come on the server without entering any passwords.
>
> All that I want is a mandatory presence of a public key and standard
> authorization with request of the password which is stored on the
> server.

--
And, did Galoka think the Ulus were too ugly to save?
š š š š š š š š š š š š š š š š š š š šš -Centauri

On Tue, 31 Aug 2010, Robert Hajime Lanning wrote:

> ssh is not written to do that.
>
> It authorizes on first successful authentication.
>
> The closest thing you can do is distribute PKCS#11 compatible hardware
> tokens and configure the ssh client to use the key from there.
>
> This will implement two factor authentication.
> 1) the token (the key never leaves the token)
> 2) password authentication to the token to unlock access to use the key.

Actually, the answer you're looking for is called "securID", or other
similar products like cryptocards or tokens by Vasco or securecomputing.

Specifically, the "RSA way" is you concatenate the token code with your
password, so your password is foobarNNNNNN, and the radius/pam server
knows to do a "split" on that point, and compare the values separately.

It is also possible to do full on challenge-response authentication, in
the classic "you type the challenge into your token, and the token gives
you a response" method.

You can use this, for example, with OPIE (also known as s/key), which has
the advantage of blocking replay attacks (passwords are discarded on use),
and being usable over unencrypted channels.

And yes, you could work this with LDAP, but it's nontrivial and probably
requires some custom PAM programming to chain the functionality together.

I have not seen a free, off-the-shelf product that does this.

-Dan

--

"SOY BOMB!"

-The Chest of the nameless streaker of the 1998 Grammy Awards' Bob Dylan
Performance.

--------Dan Mahoney--------
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144 AIM: LarpGM
Site: http://www.gushi.org
---------------------------

You cannot do such a thing with ssh, but you can always do something
extra on unix level after login.

For instance :
- use a general account for login with public key and for each pubkey in
authorized_keys2 specify an ssh command
to localhost which is password enabled.
- or start a shell which requires a password.

Hans

>
> We each other haven't understood.
>
> I have adjusted authorization on a public key. But only two methods:
>
> 1. The server will authorize without the password (if the key formed
> without the password).
>
> 2. The client ask the key password (if the key is protected by the password).
>
> It is necessary for me:
>
> 1. What the client is mandatory had a public key without the password
> without which the server won't pass the client.
>
> 2. That at authorization the client would ask the unix password of the
> user on the server.
>

Le 01/09/10 01:35, Robert Hajime Lanning a écrit :
> ssh is not written to do that.
>
> It authorizes on first successful authentication.
>
The SSH2 protocol certainly permits this. It's a partial authentication,
and permits to force the client to use another authentication mean while
telling that the first way was a success.
http://tools.ietf.org/html/rfc4252#section-5.1

I do not know if it's supported by openssh, but it sure is in some
implementations (libssh from http://www.libssh.org does).

Aris

A possible workaround is to use an SSH key which "forces" a command of "sudo /bin/login".
By doing so, one would first authenticate with the SSH key (without password), and then need to authenticate through the "regular" PAM stack (password from LDAP).
I haven't tried the configuration myself, but it's worth a shot.

Best regards,
Filip Fafara


W dniu 01.09.2010 01:35, Robert Hajime Lanning pisze:
> ssh is not written to do that.
>
> It authorizes on first successful authentication.
>
> The closest thing you can do is distribute PKCS#11 compatible hardware
> tokens and configure the ssh client to use the key from there.
>
> This will implement two factor authentication.
> 1) the token (the key never leaves the token)
> 2) password authentication to the token to unlock access to use the key.
>
> You do loose the LDAP auth in doing this.
>
> 2010/8/31 Илья Скорик <ilya@skorik.me>:
>> Approximately so.
>>
>> A problem that people from an enterprise network have access to the
>> server. And there is Windows in their network. Recently the virus has
>> stolen passwords at one of managers, has entered on the one of servers
>> and has download the bad software.
>>
>> I would like will restrict access in case of simple larceny of
>> passwords by viruses, but I am not able to do it standard manner.
>> Because from server side all managers come from one ip addresses. Also
>> I don't want to setup authorization through a public key. Since it
>> isn't compatible with ldap authorization on the server. And managers
>> can come on the server without entering any passwords.
>>
>> All that I want is a mandatory presence of a public key and standard
>> authorization with request of the password which is stored on the
>> server.

You probably should have a look at kerberos and limit your ssh server to
kerberos authentication (GSSAPIAuthentication yes) but disallow pam
(UsePAM no) and others like public key authentication.
With kerberos your client and server have to be known by the kerberos
server and have to have a kerberos key (as far as i know). The kerberos
database can be put into LDAP. Microsofts AD does this, but it is
possible to make this with openldap too.



On 09/01/2010 12:17 AM, éÌØÑ óËÏÒÉË wrote:
> Approximately so.
>
> A problem that people from an enterprise network have access to the
> server. And there is Windows in their network. Recently the virus has
> stolen passwords at one of managers, has entered on the one of servers
> and has download the bad software.
>
> I would like will restrict access in case of simple larceny of
> passwords by viruses, but I am not able to do it standard manner.
> Because from server side all managers come from one ip addresses. Also
> I don't want to setup authorization through a public key. Since it
> isn't compatible with ldap authorization on the server. And managers
> can come on the server without entering any passwords.
>
> All that I want is a mandatory presence of a public key and standard
> authorization with request of the password which is stored on the
> server.
>
>
> 2010/8/31 Mark Naker <mnaker@gmail.com>:
>> If I understand correctly, you are trying to use a public key setup in ssh
>> that is passphrase protected by the destination hosts local password. If I
>> have not understood correctly, feel free to ignore the rest of this email.
>>
>> This is not possible in an easily configured and direct method.
>>
>> I have not set up ssh in this way, however, it should be possible to stack
>> authentication methods in your PAM configuration such that first the
>> publickey would be used, and then the machine would also ask for the local
>> passord. You will need to play around with the sshd_config file quite a
>> bit.
>>
>> You may see a result where users have to enter their key passphrase, and the
>> password of the destinataion system with a setup like this.
>>
>> It is also possible that you may have to write your own PAM module to handle
>> authentication in this manner.
>>
>> Good luck!
>>
>>
>>
>> 2010/8/31 éÌØÑ óËÏÒÉË <ilya@skorik.me>
>>>
>>> We each other haven't understood.
>>>
>>> I have adjusted authorization on a public key. But only two methods:
>>>
>>> 1. The server will authorize without the password (if the key formed
>>> without the password).
>>>
>>> 2. The client ask the key password (if the key is protected by the
>>> password).
>>>
>>> It is necessary for me:
>>>
>>> 1. What the client is mandatory had a public key without the password
>>> without which the server won't pass the client.
>>>
>>> 2. That at authorization the client would ask the unix password of the
>>> user on the server.
>>>
>>> 2010/8/31 Greg Wooledge <wooledg@eeg.ccf.org>:
>>>> On Tue, Aug 31, 2010 at 10:51:08AM +0400, ???????? ???????????? wrote:
>>>>> I want to set ssh authorization through unix/pam with mandatory public
>>>>> key. I want will make sure that except the password the user has an
>>>>> acknowledgement of legitimacy in the form of a public key. Thus the
>>>>> password should be from unix/pam, not from key.
>>>>>
>>>>> I tried different variants. It turned out with key and without the
>>>>> password, or the password undertook from a key, instead of from
>>>>> unix/pam.
>>>>
>>>> Public key authentication does not involve a password, and it does not
>>>> involve PAM.
>>>>
>>>> If you are attempting to require the use of a passPHRASE on the private
>>>> key, then you need to be aware that the private key is only seen by the
>>>> ssh client, not the server. The server has no idea whether the key was
>>>> passPHRASE protected or not.
>>>>
>>>> Server-side passWORDS have nothing at all to do with public key
>>>> authentication, or with the passPHRASES that are used to protect the
>>>> private keys.
>>>>
>>>
>>>
>>>
>>> --
>>> ó Õ×ÁÖÅÎÉÅÍ, éÌØÑ óËÏÒÉË
>>> Yours faithfully, Ilya Skorik
>>
>>
>>
>> --
>> :(){ :|:& };:
>>
>
>
>