sshd handing all authentication to shell
MITCH BLACK
to say I do not want SSHD to authenticate users nor do I want or have the
ability to setup end to end keys. So, I need SSH to hand off all
authentication to my custom shell. The custom shell will do a simple
login/password authentication but since it is using SSH for transport,
password will be encrypted.
Can this be done via configuration or do I have to change the source?
Thanks,
Mitch
MITCH BLACK
my associated shell to handle the login interaction/prompt.
Thanks,
Mitch
"MITCH BLACK" <mm...@verizon.net> wrote in message
news:K72Xd.57385$EL5.23278@trnddc05...
Jacob Nevins
You don't state what SSH server you're planning to use, so I'm going to
argue here from protocol specs. I don't know how much is possible with a
particular implementation.
In SSH-2, I believe that in principle a client should be able to request
"ssh-connection" (which will give you your terminal session) directly,
rather than through the "ssh-userauth" service, and thus get at a
session unauthenticated. However, that's not how it's usually done, and
I'm not sure that common clients support it (I know PuTTY doesn't, for
instance).
You can make userauth trivial, however. I believe clients will generally
try to authenticate with the "none" method before anything else, in
order to get the list of supported authentication methods. (Although I
don't think they're _obliged_ to.) If your SSH server just lets them in
at this point you should be done. (Although I wouldn't be surprised if
one or two clients fall over in surprise :)
With SSH-1, a client has to specify a username, but the server can then
let them in without further authentication. I think most clients will
let you configure this username in advance, so you can more or less
achieve your stated goal of no prompts.
You haven't stated explicitly why you want to arrange things this way.
You may want to consider the following points:
* If you're going to let people at an SSH connection without
authentication, and your implementation supports non-shell requests
such as port forwarding, you might want to make sure that they can't
successfully make such requests until authenticated. This might be
a source of security holes if you're munging an existing server
implementation which drops its guard post-authentication.
* If a client knows that data is authentication data, it can take
special care to hide it, for instance by padding the length of
password packets to hide the password length.
* Authentication data in the SSH protocol is sent all at once, whereas
authentication over the session can be vulnerable to traffic analysis
such as timing analysis to infer which keys are being pressed, if the
client hasn't taken countermeasures.
* If you just need to be able to specify your own prompts and so forth
rather than using (say) standard password semantics,
keyboard-interactive auth (SSH-2) or TIS/CryptoCard (SSH-1) can
provide that for you.
MITCH BLACK
I don't know too much about the protocol. My requirements are to have a
"secure" way to access an embedded device that I am a developer on. Secure
access simply means that passwords not be clear text. We have a ported
version of Debian running which I have ported a version of openssh to. The
reason I need my "shell" to authenticate is becuase it is a custom command
line interface to the embedded device. There is no bash shell running on
the box and no other terminating ports so hacking into the shell isn't that
large a concern to me.
Now to your suggestions...
Would the user authentication peice for user "none" be accomplished using
shosts.equiv or soemthing like that?
Thanks
Mitch
"Jacob Nevins" <jac...@chiark.greenend.org.uk> wrote in message
news:+yh*TR...@news.chiark.greenend.org.uk...
Richard E. Silverman
> Would the user authentication peice for user "none" be accomplished using
> shosts.equiv or soemthing like that?
"none" is not a username here; it's a reserved authentication method name.
SSH clients normally first issue a userauth request for method "none"; the
server fails it, and in the process returns a list of the methods it
supports. If authentication is not required for the specified account,
however, the server can return success for the "none" method and
immediately grant access.
- Richard
MITCH BLACK
I will begin looking for this answer myself, but in the meantime... How do I
configure sshd (openssh on debian) to grant access on "none"?
Thanks!
Mitch
"Richard E. Silverman" <r...@qoxp.net> wrote in message
news:m26502g...@darwin.oankali.net...
MITCH BLACK
alternatively giving unrestricted access to user "x" without a password and
no key? OpenSSH on Debian. Could this be done with shost_equiv or PAM?
"MITCH BLACK" <mm...@verizon.net> wrote in message
news:MghXd.42402$uc.3517@trnddc01...
Richard E. Silverman
MB> Anyone have an answer for this? Granting access for "none"
MB> method? Or alternatively giving unrestricted access to user "x"
MB> without a password and no key? OpenSSH on Debian. Could this be
MB> done with shost_equiv or PAM?
PasswordAuthentication yes
PermitEmptyPasswords yes
... then sshd will return success on "none" for accounts with a
zero-length password.
This really isn't the way it should be implemented; it means you have to
turn on password authentication in general, which this really has nothing
do to with. The empty password is just a flag indicating that no SSH
authentication is needed.
MB> "MITCH BLACK" <mm...@verizon.net> wrote in message
MB> news:MghXd.42402$uc.3517@trnddc01...
>> Thanks, this is helpful.
>>
>> I will begin looking for this answer myself, but in the
>> meantime... How do I configure sshd (openssh on debian) to grant
>> access on "none"?
>>
>> Thanks!
>>
>> Mitch
>>
>>
>> "Richard E. Silverman" <r...@qoxp.net> wrote in message
>> news:m26502g...@darwin.oankali.net...
>>>
>>>> Would the user authentication peice for user "none" be
>>>> accomplished using shosts.equiv or soemthing like that?
>>> "none" is not a username here; it's a reserved authentication
>>> method name. SSH clients normally first issue a userauth request
>>> for method "none"; the server fails it, and in the process returns
>>> a list of the methods it supports. If authentication is not
>>> required for the specified account, however, the server can return
>>> success for the "none" method and immediately grant access.
>>>
>>> - Richard
>>
--
Richard Silverman
r...@qoxp.net
MITCH BLACK
"Richard E. Silverman" <r...@qoxp.net> wrote in message
news:m2fyz2g...@darwin.oankali.net...
Darren Tucker
>>>>>> "MB" == MITCH BLACK <mm...@verizon.net> writes:
>
> MB> Anyone have an answer for this? Granting access for "none"
> MB> method? Or alternatively giving unrestricted access to user "x"
> MB> without a password and no key? OpenSSH on Debian. Could this be
> MB> done with shost_equiv or PAM?
Yes, it could probably be done with PAM (put pam_permit.so at the start
of your sshd PAM stack).
> PasswordAuthentication yes
> PermitEmptyPasswords yes
>
> ... then sshd will return success on "none" for accounts with a
> zero-length password.
If you're going to to this, it's probably a good idea to add:
AllowTcpForwarding no
to prevent someone from using your host for connection laundering.
--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.