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?
--
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 =----
Les réponses au message de Robert (noone@noplace.nowhere)
> 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.
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).
-- Q: What do monsters eat? A: Things. Q: What do monsters drink? A: Coke. (Because Things go better with Coke.)
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.
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 =----
>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 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
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 >
Vulnerabilite.com ne peut être tenu responsable des propos tenus dans le Newsgroup comp.os.linux.security
The #1 Newsgroup Service in the World! 120,000+ Newsgroups
Message de Tim Southerwood (ts@dionic.net) (13 Aout 2007)
Les lecteurs de ce livre lui attribuent une note moyenne de 5/5.<
/font>