Robert coughed up some electrons that declared:

> Hi everyone,
>
> Is there a way to have SSH Auth with a key and then still require a
> user name and password to gain access to a system?
>
>

Hi

The usual way is to have a passphrase on the key. You still need a username
to specify the account anyway, you have the key, and this way you get a
passphrase. Not the same passphrase that the rest of the system uses mind.

Otherwise, what you may be after is a way to get sshd to require a key *and*
call the PAM stack for authentication. Not sure if that's possible.

Cheers

Tim

Tim Southerwood wrote:
> Robert coughed up some electrons that declared:
>
>> Hi everyone,
>>
>> Is there a way to have SSH Auth with a key and then still require a
>> user name and password to gain access to a system?
>>
>>
>
> Hi
>
> The usual way is to have a passphrase on the key. You still need a username
> to specify the account anyway, you have the key, and this way you get a
> passphrase. Not the same passphrase that the rest of the system uses mind.

Well... a passphrase is simply a local unlocking of the local client
private key so that an adequate challenge response can be made. Not quite
the same thing (possibly) as what the OP was looking for (?).

>
> Otherwise, what you may be after is a way to get sshd to require a key *and*
> call the PAM stack for authentication. Not sure if that's possible.
>

On most Linux distros, sshd is pam enabled. So yes, you can authenticate
to multiple sources using different passwords before it will allow you
in. Just have to add extra required auths.

Chris Cox coughed up some electrons that declared:

> Tim Southerwood wrote:
>> Robert coughed up some electrons that declared:
>>
>>> Hi everyone,
>>>
>>> Is there a way to have SSH Auth with a key and then still require a
>>> user name and password to gain access to a system?
>>>
>>>
>>
>> Hi
>>
>> The usual way is to have a passphrase on the key. You still need a
>> username to specify the account anyway, you have the key, and this way
>> you get a passphrase. Not the same passphrase that the rest of the system
>> uses mind.
>
> Well... a passphrase is simply a local unlocking of the local client
> private key so that an adequate challenge response can be made. Not quite
> the same thing (possibly) as what the OP was looking for (?).

Yes, I assumed that.

>>
>> Otherwise, what you may be after is a way to get sshd to require a key
>> *and* call the PAM stack for authentication. Not sure if that's possible.
>>
>
> On most Linux distros, sshd is pam enabled. So yes, you can authenticate
> to multiple sources using different passwords before it will allow you
> in. Just have to add extra required auths.

But PAM doesn't understand SSH DSA auth - that would be handled directly by
sshd without calling the pam-auth stack. That's why I wondered if it were
even possible. On my systems, if a valid DSA key is supplied, sshd allows
the login. pam-auth is called only if no valid key is supplied.

If it is possible to force sshd to call both, I'd like to know how.

Cheers

Tim

Tim Southerwood wrote:
....
>
> But PAM doesn't understand SSH DSA auth - that would be handled directly by
> sshd without calling the pam-auth stack. That's why I wondered if it were
> even possible. On my systems, if a valid DSA key is supplied, sshd allows
> the login. pam-auth is called only if no valid key is supplied.
>
> If it is possible to force sshd to call both, I'd like to know how.

A conundrum.

You can disable ssh authentication and just rely on pam, but since
you are wanting an extra password step AFTER ssh key authentication, I'm
not sure if it's possible. It might be possible by replacing
/bin/login with your own special version and by tell SSH to UseLogin.
But I've never done this except to allow for session snooping...

On Mon, 13 Aug 2007 18:02:36 -0500, Chris Cox wrote:

>> The usual way is to have a passphrase on the key. You still need a username
>> to specify the account anyway, you have the key, and this way you get a
>> passphrase. Not the same passphrase that the rest of the system uses mind.
>
> Well... a passphrase is simply a local unlocking of the local client
> private key so that an adequate challenge response can be made. Not quite
> the same thing (possibly) as what the OP was looking for (?).

What I'm looking for is to have the system connect with a valid key and
after the connection is made require the user to log in as one would
usually log in with user name and password.

Passphrase might be nice but I would rather the control be on the server
then the local system. There are several reason why I would like it this
way.

1. Should the client forget his passphrase a new key would have to be
generated and both systems would have to be updated. For a remote client
that could take time.

2. By using a key first this would stop the script kiddies for gaining
access and still have control over who is logging in.

Yes I know about changing the port but that is not what I'm looking to do.
I want to use the KISS logic (Keep It Simple Stupid) and not move from the
defaults ports. Makes troubleshooting a lot easier.


--

Regards
Robert

Smile... it increases your face value!


----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

On Mon, 13 Aug 2007 06:04:57 +0000, Bill Marcum wrote:

> On Sun, 12 Aug 2007 21:12:02 -0400, Robert
> wrote:
>>
>>
>> Hi everyone,
>>
>> Is there a way to have SSH Auth with a key and then still require a
>> user name and password to gain access to a system?
>>
>>
> Use ssh-keygen to generate a key with a passphrase? (haven't actually
> tried it).

Not the path I want to travel. See my pother post about this.


--

Regards
Robert

Smile... it increases your face value!


----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

Robert writes:

>On Mon, 13 Aug 2007 06:04:57 +0000, Bill Marcum wrote:

>> On Sun, 12 Aug 2007 21:12:02 -0400, Robert
>> wrote:
>>>
>>>
>>> Hi everyone,
>>>
>>> Is there a way to have SSH Auth with a key and then still require a
>>> user name and password to gain access to a system?
>>>
>>>
>> Use ssh-keygen to generate a key with a passphrase? (haven't actually
>> tried it).

That works in the wrong direction. passphrase key is on the client not the
host being logged into. Or if it is on the host, then someone on the host
has to enter the passphrase.

You could presumably also put in a pam requirement that a password be used.
Ie, ssh will open a login, but pam then demands a password.



>Not the path I want to travel. See my pother post about this.


>--

>Regards
>Robert

>Smile... it increases your face value!


>----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
>http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
>----= East and West-Coast Server Farms - Total Privacy via Encryption =----

In article , Robert wrote:
> On Mon, 13 Aug 2007 18:02:36 -0500, Chris Cox wrote:
>
>>> The usual way is to have a passphrase on the key. You still need a username
>>> to specify the account anyway, you have the key, and this way you get a
>>> passphrase. Not the same passphrase that the rest of the system uses mind.
>>
>> Well... a passphrase is simply a local unlocking of the local client
>> private key so that an adequate challenge response can be made. Not quite
>> the same thing (possibly) as what the OP was looking for (?).
>
> What I'm looking for is to have the system connect with a valid key and
> after the connection is made require the user to log in as one would
> usually log in with user name and password.

Suppose you ran an sshd in a chroot jail, listening to some
port on a routable address. This sshd only allows login by RSA key.
It doesn't allow port forwarding or X11.
Suppose the only executable in that jail is a telnet client.

("Telnet! Zounds, man, nobody uses telnet!" Well, it's hard for users
to convince the telnet server to run anything for them but login. And who's
gonna eavesdrop on the password here?)

Suppose you have a telnet server, not in jail, but only
listening to 127.0.0.1. This server invokes login
which authenticates via PAM.

So from the outside you ssh into the bare jail, and from there
you have to telnet into the real machine.

Your users will get annoyed with all this paranoia. You'll
need a firewall rule so they can't start their own telnet/ssh/bindshell
servers on high ports.

Look at Telnet's -8 and -E options. Maybe there is a second binary
in the jail, that exec()'s telnet with fixed options.
Maybe that's not necessary.


Cameron

Cameron L. Spitzer wrote:
> Suppose you ran an sshd in a chroot jail, listening to some
> port on a routable address. This sshd only allows login by RSA key.
> It doesn't allow port forwarding or X11.
> Suppose the only executable in that jail is a telnet client.



> ("Telnet! Zounds, man, nobody uses telnet!" Well, it's hard for users
> to convince the telnet server to run anything for them but login. And
> who's gonna eavesdrop on the password here?)
And what's the matter in using two ssh servers?

> Suppose you have a telnet server, not in jail, but only
> listening to 127.0.0.1. This server invokes login
> which authenticates via PAM.
>
> So from the outside you ssh into the bare jail, and from there
> you have to telnet into the real machine.
>
> Your users will get annoyed with all this paranoia. You'll
> need a firewall rule so they can't start their own telnet/ssh/bindshell
> servers on high ports.

What about not allowing normal users to exec sshd/telnetd/...

> Look at Telnet's -8 and -E options. Maybe there is a second binary
> in the jail, that exec()'s telnet with fixed options.
> Maybe that's not necessary.
Even with no other binary in the jail, that way is more paranoic (For the
ones who haven't read telnet's manpage, -E prevents from using escape key.)

Really Paranoic :-). But what will be the difference between that and using
two ssh servers?

# Here goes the changed options from the standard config file
# For the sshd_config.internal
Port 23
ListenAddress 127.0.0.1
LoginGraceTime 20
PermitRootLogin no
RSAAuthentication yes
PubkeyAuthentication yes
PasswordAuthentication no
X11Forwarding no
Banner /etc/issue.internal

# For the sshd_config.inet
LoginGraceTime 20
PermitRootLogin no
RSAAuthentication no
PubkeyAuthentication no
PasswordAuthentication yes
X11Forwarding no

So you have the ssh external server jailed, and the second ssh server only
allows local conections, so you connect by ssh authenticating with rsa to
the external server and from there you enter the user and pass to log in
Is anything wrong with that?

I Don't rely on telnet servers but seems interesntig too.

Would it be too paranoic to use this with a firewall rule that only allows
logins from a host and allowing only two logins per time? I've got my pc
with a ssh server, and I want only ME can access to it, and something like
no-ip or similar would be interesting, I mean, you've got to enter the
no-ip password, connect, enter the RSA password, have the rsa file, and
enter the password on the telnet or ssh second server. :-P

> Cameron

--

--David Francos --
Contact:
Jabber: Thexayon@jabber.com
E-mail:Yo.orco@gmail.com, thexayon@gmail.com (GTalk)

In article , XayOn wrote:
> Cameron L. Spitzer wrote:
>> Suppose you ran an sshd in a chroot jail, listening to some
>> port on a routable address. This sshd only allows login by RSA key.
>> It doesn't allow port forwarding or X11.
>> Suppose the only executable in that jail is a telnet client.
>
>> Suppose you have a telnet server, not in jail, but only
>> listening to 127.0.0.1. This server invokes login
>> which authenticates via PAM.

>> Your users will get annoyed with all this paranoia. You'll
>> need a firewall rule so they can't start their own telnet/ssh/bindshell
>> servers on high ports.
>
> What about not allowing normal users to exec sshd/telnetd/...

That's hard. They can copy in their own sshd and rename it.
So I'd have to not let them exec anything.
But as far as I know they can't listen on a port below 1024
nor create a set-uid binary owned by root.



> Really Paranoic :-). But what will be the difference between that and using
> two ssh servers?

Performance. Do I really need to encrypt a stream through
the loopback interface? Since you've disabled Pubkey and RSA, below,
I don't see a functional difference. Except ^] vs ~.



> # For the sshd_config.internal
> Port 23
> ListenAddress 127.0.0.1
> LoginGraceTime 20
> PermitRootLogin no
> RSAAuthentication yes
> PubkeyAuthentication yes
> PasswordAuthentication no
> X11Forwarding no
> Banner /etc/issue.internal
>
> # For the sshd_config.inet
> LoginGraceTime 20
> PermitRootLogin no
> RSAAuthentication no
> PubkeyAuthentication no
> PasswordAuthentication yes
> X11Forwarding no
>
Cameron
>