Re: Dropbear calling my own command-line parser than /bin/sh
Hi, I don't think you can avoid it - the best you can do is to put something@192.168.14.1 in the host field so it'll send a username without prompting. The SSH protocol requires a username in all authentication requests, so PuTTY assumes it's going to be necessary. Cheers, Matt On Wed, Sep 26, 2012 at 09:51:55AM +0800, chinna obireddy wrote: Hey Matt, I was able to make it work for any username login return authentication success. But the problem is that Putty(Windows) asks for user name, though any username will do actually. I don't want the ssh client ask the user to enter username at all. How could I achieve that ?? SSH client: Login as: press enter -- shouldn't prompt at all username:xxx(CLI auth) password:xxx(CLI auth) Reddy On Tue, Sep 25, 2012 at 8:49 PM, Matt Johnston m...@ucc.asn.au wrote: Hi, Take a look at https://secure.ucc.asn.au/hg/dropbear/rev/0edf08895a33 - it sends success for the first auth request. Matt On Tue, Sep 25, 2012 at 04:39:26PM +0800, chinna obireddy wrote: Dear All, As per the thread http://thread.gmane.org/gmane.network.ssh.dropbear/68/focus=75 I was successfully made changes to launch CLI application with dropbear ssh. But Putty(SSH client) is still asking for Login name, though this is not going to be used It looks weird for user asking user name twice. Since the CLI application has it's own authentication method. Suggest me how can I completely ignore Authentication packets in the server side. --Reddy.
Dropbear calling my own command-line parser than /bin/sh
Dear All, As per the thread http://thread.gmane.org/gmane.network.ssh.dropbear/68/focus=75 I was successfully made changes to launch CLI application with dropbear ssh. But Putty(SSH client) is still asking for Login name, though this is not going to be used It looks weird for user asking user name twice. Since the CLI application has it's own authentication method. Suggest me how can I completely ignore Authentication packets in the server side. --Reddy.
Re: Dropbear calling my own command-line parser than /bin/sh
Hey Matt, I was able to make it work for any username login return authentication success. But the problem is that Putty(Windows) asks for user name, though any username will do actually. I don't want the ssh client ask the user to enter username at all. How could I achieve that ?? SSH client: Login as: press enter -- shouldn't prompt at all username:xxx(CLI auth) password:xxx(CLI auth) Reddy On Tue, Sep 25, 2012 at 8:49 PM, Matt Johnston m...@ucc.asn.au wrote: Hi, Take a look at https://secure.ucc.asn.au/hg/dropbear/rev/0edf08895a33 - it sends success for the first auth request. Matt On Tue, Sep 25, 2012 at 04:39:26PM +0800, chinna obireddy wrote: Dear All, As per the thread http://thread.gmane.org/gmane.network.ssh.dropbear/68/focus=75 I was successfully made changes to launch CLI application with dropbear ssh. But Putty(SSH client) is still asking for Login name, though this is not going to be used It looks weird for user asking user name twice. Since the CLI application has it's own authentication method. Suggest me how can I completely ignore Authentication packets in the server side. --Reddy.
Re: Dropbear calling my own command-line parser than /bin/sh.
On Tue, Jul 18, 2006 at 02:00:49PM +0800, Matt Johnston wrote: On Mon, Jul 17, 2006 at 09:53:52PM -0700, Prasad wrote: So now i want to totally skip the regular username and password in the SSH and directly call my commandline interpreter (which has a password autentication by itself). How do i achieve that? Is there any security flaws in this kinda design. I think it should be secure, as long as you make sure that you're ignoring requests for different commands from the user (which will get passed as arguments to your interpreter), and your interpreter itself is secure. Another thought, you should probably disable any forwarding. TCP forwarding certainly could present a hazard (tunnel through the device to get around firewalls), and agent or X11 forwarding might have unforseen issues too. You might also be vulnerable to denial-of-service type issues, as someone could open numerous connections, each spawning an interpreter. One solution to that is to limit the total number of connections - see the thread http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2006q2/000388.html or your inetd implementation if you're using that. Matt
Re: Dropbear calling my own command-line parser than /bin/sh.
On Fri, Jul 14, 2006 at 06:13:44PM -0700, Prasad wrote: Hi all, How do i make dropbear call my own utility/command-line parser which has its own way of checking the username and password and does some other work. Have a look at svr_auth_password() in svr-authpasswd.c for how the existing password checking works. You could make it run a hardcoded system() call (beware of allowing arbitrary input), and then check the return value of the program? Note that if the user doesn't exist in /etc/passwd, then you'll have to manually fill out the entries in the ses.authstate.pw structure. Look out for the code in svr-auth.c that checks that a shell is valid - you may want to disable that. How do i integrate that with the dropbear-ssh (in this way i can get my code to get run using SSH and not the default /bin/sh). If you're using /etc/passwd still, just change the shell there (and /etc/shells). Otherwise, change the shell that is filled out in the ses.authstate.pw structure during auth. The shell to execute is taken from ses.authstate.pw-pw_shell in svr-chansession.c. The shell is run as sh -c 'command line arguments', so you might want to change that (or just have your own shell ignore arguments). Matt
