Pseudo-tty allocation and -T option

[John Horne]

Hello,

I've set up a cron job to use ssh with a remote forced command to delete the
contents of a directory. System A has the cron job and uses a specific key
for system B. No command as such is specified since the key on system B
specifies 'command=/bin/rm -rf ...'. However, I am getting error messages
back from the cron system (or rather from ssh) about it not allocating a tty
since there is no controlling terminal - obviously not since the job is run
through cron:

Pseudo-terminal will not be allocated because stdin is not a terminal.

I have tried using the -T option and specifying no_pty in the
key options on system B, but I still get the error message. The man page for
ssh says:

-T Disable pseudo-tty allocation (protocol version 2 only).

We are only using protocol 2; openssh 2.3.0p1. So is '-T' not working
correctly, am I doing something wrong or is openssh correct in that it will
always print out the message if used via cron? If the latter then how can I
'remove' the message since the output gets mailed back to the user (in this
case the postmasters). I have thought about using:

ssh .... 2>&1 | egrep -v "^Pseudo-terminal will not be"

which seems to work but seems a bit messy. Using '-q' to ssh makes no
difference either. My understanding from the man page is that -T should
prevent it attempting to allocate a tty.

Thanks for any help,

John.

------------------------------------------------------------------------
John Horne, University of Plymouth, UK Tel: [phone]
E-mail: ***@plymouth.ac.uk
PGP key available from public key servers

[Markus Friedl]

try the patch or
ssh host dummy
instead of
ssh host
-markus

Index: ssh.c
===================================================================
RCS file: /home/markus/cvs/ssh/ssh.c,v
retrieving revision 1.74
diff -u -r1.74 ssh.c
--- ssh.c 2000/11/23 21:03:47 1.74
+++ ssh.c 2000/11/30 07:00:38
@@ -504,15 +504,15 @@
if (buffer_len(&command) == 0)
tty_flag = 1;

+ /* Force no tty*/
+ if (no_tty_flag)
+ tty_flag = 0;
/* Do not allocate a tty if stdin is not a tty. */
if (!isatty(fileno(stdin))) {
if (tty_flag)
fprintf(stderr, "Pseudo-terminal will not be allocated because stdin is not a terminal.\n");
tty_flag = 0;
}
- /* force */
- if (no_tty_flag)
- tty_flag = 0;

/* Get user data. */
pw = getpwuid(original_real_uid);

Post by John Horne
Hello,
I've set up a cron job to use ssh with a remote forced command to delete the
contents of a directory. System A has the cron job and uses a specific key
for system B. No command as such is specified since the key on system B
specifies 'command=/bin/rm -rf ...'. However, I am getting error messages
back from the cron system (or rather from ssh) about it not allocating a tty
since there is no controlling terminal - obviously not since the job is run
Pseudo-terminal will not be allocated because stdin is not a terminal.
I have tried using the -T option and specifying no_pty in the
key options on system B, but I still get the error message. The man page for
-T Disable pseudo-tty allocation (protocol version 2 only).
We are only using protocol 2; openssh 2.3.0p1. So is '-T' not working
correctly, am I doing something wrong or is openssh correct in that it will
always print out the message if used via cron? If the latter then how can I
'remove' the message since the output gets mailed back to the user (in this
ssh .... 2>&1 | egrep -v "^Pseudo-terminal will not be"
which seems to work but seems a bit messy. Using '-q' to ssh makes no
difference either. My understanding from the man page is that -T should
prevent it attempting to allocate a tty.
Thanks for any help,
John.
------------------------------------------------------------------------
John Horne, University of Plymouth, UK Tel: [phone]
PGP key available from public key servers

[Giles Constant]

Failing that, I have a patch (well, I have a hacked version of ssh - i can
make a patch :-)) that has a "-oPassword=foo" option. I haven't got round
to making it clear the cmdline string out of the ps listing yet, but
provided there's noone on your box capable of reading the ps listing it's
safe.

Post by Markus Friedl
try the patch or
ssh host dummy
instead of
ssh host
-markus
Index: ssh.c
===================================================================
RCS file: /home/markus/cvs/ssh/ssh.c,v
retrieving revision 1.74
diff -u -r1.74 ssh.c
--- ssh.c 2000/11/23 21:03:47 1.74
+++ ssh.c 2000/11/30 07:00:38
@@ -504,15 +504,15 @@
if (buffer_len(&command) == 0)
tty_flag = 1;
+ /* Force no tty*/
+ if (no_tty_flag)
+ tty_flag = 0;
/* Do not allocate a tty if stdin is not a tty. */
if (!isatty(fileno(stdin))) {
if (tty_flag)
fprintf(stderr, "Pseudo-terminal will not be allocated because stdin is not a terminal.\n");
tty_flag = 0;
}
- /* force */
- if (no_tty_flag)
- tty_flag = 0;
/* Get user data. */
pw = getpwuid(original_real_uid);

Post by John Horne
Hello,
I've set up a cron job to use ssh with a remote forced command to delete the
contents of a directory. System A has the cron job and uses a specific key
for system B. No command as such is specified since the key on system B
specifies 'command=/bin/rm -rf ...'. However, I am getting error messages
back from the cron system (or rather from ssh) about it not allocating a tty
since there is no controlling terminal - obviously not since the job is run
Pseudo-terminal will not be allocated because stdin is not a terminal.
I have tried using the -T option and specifying no_pty in the
key options on system B, but I still get the error message. The man page for
-T Disable pseudo-tty allocation (protocol version 2 only).
We are only using protocol 2; openssh 2.3.0p1. So is '-T' not working
correctly, am I doing something wrong or is openssh correct in that it will
always print out the message if used via cron? If the latter then how can I
'remove' the message since the output gets mailed back to the user (in this
ssh .... 2>&1 | egrep -v "^Pseudo-terminal will not be"
which seems to work but seems a bit messy. Using '-q' to ssh makes no
difference either. My understanding from the man page is that -T should
prevent it attempting to allocate a tty.
Thanks for any help,
John.
------------------------------------------------------------------------
John Horne, University of Plymouth, UK Tel: [phone]
PGP key available from public key servers

[Markus Friedl]

Post by Giles Constant
Failing that, I have a patch (well, I have a hacked version of ssh - i can
make a patch :-)) that has a "-oPassword=foo" option. I haven't got round
to making it clear the cmdline string out of the ps listing yet, but
provided there's noone on your box capable of reading the ps listing it's
safe.

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.

-markus

[John Horne]

Post by Markus Friedl
try the patch or
ssh host dummy
instead of
ssh host
-markus

The patch works fine - thanks :-)

I must agree with Markus regarding a 'Password' option. I'm using ssh
because I want a secure environment; using plaintext passwords and the like
seems to somewhat contradict this.

John.

------------------------------------------------------------------------
John Horne, University of Plymouth, UK Tel: [phone]
E-mail: ***@plymouth.ac.uk
PGP key available from public key servers

[Giles Constant]

Post by Markus Friedl
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 ***@bar.com: -oCreateAttachFile ./foo
secure it: chmod 700 ./foo
attach[1]: ssh-reattach ./foo
do something: ls (runs as ***@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.

[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

Post by Giles Constant

Post by Markus Friedl
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
secure it: chmod 700 ./foo
attach[1]: ssh-reattach ./foo
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.

[Frank Tobin]

Rob Hagopian, at 15:28 -0500 on Thu, 30 Nov 2000, wrote:

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

This is similar to GnuPG's method of passing in passphrases, which uses a
--passphrase-fd option. This method of interactiong is both highly
useable from both many scripting languages and from shell syntax.