Pseudo-tty allocation and -T option

[Rob Hagopian]

FreeBSD has a method of setting a user's password that may be applicable
(from 'man pw'):

 -h fd     This option provides a special interface by which  interac-
           tive scripts can set an account password using pw. Because
           the command line and environment are fundamentally insecure
           mechanisms by which programs can accept information, pw
           will only allow setting of account and group passwords via
           a file descriptor (usually a pipe between an interactive
           script and the program).  sh, bash, ksh and perl all pos-
           sess mechanisms by which this can be done.  Alternatively,
           pw will prompt for the user's password if `-h 0' is given,
           nominating stdin as the file descriptor on which to read
           the password.  Note that this password will be read only
           once and is intended for use by a script rather than for
           interactive use.  If you wish to have new password confir-
           mation along the lines of passwd(1),  this must be imple-
           mented as part of an interactive script that calls pw.

           If a value of `-' is given as the argument fd, then the
           password will be set to `*', rendering the account inacces-
           sible via password-based login.


This can be used from a sh script as:

pw useradd -n prod -u 1002 -c "User Account" -m -h 3 3< prodpass

Just make sure that prodpass is owned by root and has 600 perms...

I'm not a fan of storing passwords like this, but I don't see how it's
much more insecure than having a private RSA/DSA key with no encryption
(as long as this plaintext password is not used anywhere else)...
								-Rob


On Thu, 30 Nov 2000, Giles Constant wrote:

> On Thu, 30 Nov 2000, Markus Friedl wrote:
> 
> > i don't think that a
> > 	Password foo
> > option will ever be included in OpenSSH.
> > 
> > it's a bad practice to have plaintext passwords
> > in files, commandlines or environment variables
> > and i don't want to encourage this in OpenSSH.
> 
> It might be bad practice, but in my case it was unavoidable.  The current
> implementation of sshd on NT won't allow access without providing a domain
> password, and this is unlikely to change, due to the way it works.  When
> scripting something to ssh to NT, there has to be some mechanism for
> providing the password.  Perhaps it could be included as a compile-time
> option?  Having a file with a password in it is no less secure than having
> a blank password for your identity.
> 
> Actually, there is a way around - perhaps ssh could be extended to run
> through some sort of lockable-detachable pipe object, eg :
> 
> connect:              slogin foo at bar.com: -oCreateAttachFile ./foo
> secure it:            chmod 700 ./foo
> attach[1]:            ssh-reattach ./foo
> do something:         ls    (runs as foo at bar.com)
> detach:               ^D
> attach[2]:            ssh-reattach ./foo
> do something else:    echo hello
> detach:               ^D
> close connection: ssh-close-attachment ./foo
> 
> [1] and [2] connect to the attached link, and fire up a remote shell in
> the process.  Detaching will close the shell, but will maintain the link.
> 
> If this could be implemented in a way such that it has a similar
> feature-set to rpc, et all, it would get around my problem and possibly
> many others.
> 
> 
> 
>