stty:tcgetattr: A specified file does not support the ioctl system call

[Vishal Ranjan]

Hi,

I am trying to implement SSH between two systems say ukblx151 & ukapx047 with ID say khzs228, i follow the following process:

Step-1) $ ssh-keygen -t rsa -f rsa
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in rsa.
Your public key has been saved in rsa.pub.
The key fingerprint is:
5c:cb:fb:ec:87:a2:0e:92:a4:bd:e7:8f:99:1b:5c:50 khzs228@ukblx151

Step-2) $ cat rsa.pub | ssh khzs228@ukapx047 `cat - >> /home/khzs228/.ssh/authorized_keys`
Pseudo-terminal will not be allocated because stdin is not a terminal.
khzs228@ukapx047's password:
stty: tcgetattr: A specified file does not support the ioctl system call.


I get the above error (i.e. stty:tcgetattr: A specified file does not support the ioctl system call.), can anybody help?

Regards,
Vishal

[Steven Schweda]

If you pipe into "ssh" this way, then for
"ssh", "stdin is not a terminal", it's the
pipe (that is, the output from "cat rsa.pub").

Because the "ssh" stuff is not ready for use
without a password, "ssh" tries to ask for
the password ("khzs228@ukapx047's
password:"). When it asks for a password, it
probably tries to disable the terminal echo,
so that the person standing behind you can't
read it over your shoulder. It can't disable
the terminal echo, because "stdin is not a
terminal", which is probably why "stty"
fails.

Use a different method to copy the key file
to the other system. (Perhaps "rcp"?)

[Matti_Kurkela]

Most versions of SSH are smart enough to ask the password without terminal echo even if its standard input and output is redirected.

The error is probably coming from the login scripts on ukapx047: if /etc/profile or ~/.profile (or equivalent, if you're using a different shell) is running stty, it should first check that the session actually is running on a tty/pty.

In other words: instead of

stty

the login scripts should contain something like:

if tty -s; then
stty
fi

Even HP's default /etc/profile and /etc/skel/.profile have this "flaw", at least in 11.11 and older.

MK

[Vishal Ranjan]

Dear MK,

Can you please explain a bit in details?
That will be a great help.
I would like to tell you the reason why i wanted all this: Actually there is a directory '/interfaces' on ukblx151, i need to replicate this directory on ukapx047 (which is the DisasterRecovery system for ukblx151). Earlier i thought of iplementing RDIST tool but its giveing 'problems with file permissions', then someone suggested me to use SSH, and i end up in these problems with SSH.
Kindly advice.

Regards,
Vishal

[Steven Schweda]

> Most versions of SSH are smart enough [...]

Good point. The actual problem might be the
use of the wrong quotation mark: "`" instead
of "'". I get (different but) similar
complaints if I copy/paste instead of typing
the command in myself (with apostrophes).

With apostrophes:

td176> cat err.c | ssh td176 'cat - >> fred'
Password:
td176>

With back-ticks:

td176> cat err.c | ssh td176 `cat - >> fred`
Pseudo-terminal will not be allocated because stdin is not a terminal.
Password:
ttytype: couldn't open /dev/tty for reading
(c)Copyright 1983-2003 Hewlett-Packard Development Company, L.P.
[...]
stty: : Not a typewriter
logout
stty: : Not a typewriter
td176>

[Vishal Ranjan]

Hi MK/Steven/All,

I tried the suggestion given my Steven (i.e. use "'" instead of "`" in cat err.c | ssh td176 'cat - >> fred') & i am very happy to tell you guys that ir worked & the problem to stty:tcgetattr didnt appear, but the issue now is when i push the public key into the destination server (ukapx047) it asks for the users (khzs228) password, on giving the password it proceeds. But when i give the command ssh khzs228@destination.server it again asks for password & this i dont want, it should'nt ask for password.
Any ideas?

[Steven Schweda]

For clues, look at the output from:
ssh -v khzs228@destination.server

A forum search for:
hp-ux "ssh -v"
should find many examples of similar
problems.

[Matti_Kurkela]

There are several possible reasons why you still get the password prompt:

-----------------
I notice you generate the SSH key in a non-default location (you specify the -f option to the ssh-keygen command). This means ssh will not use this key automatically: you must use the -i option in subsequent ssh commands to actually use the non-default key.

Or you could move the keyfiles to the default location on ukblx151: the default RSA private key should be located on your $HOME/.ssh/id_rsa and the corresponding public key at $HOME/.ssh/id_rsa.pub.

If the default key files exist, ssh will automatically try to use them.

---------------------

The /home/khzs228/.ssh/authorized_keys file and the directory /home/khzs228/.ssh should be protected so that nobody other than the user khzs228 can write to them.

Other users can be allowed to read these files (public key cryptography means they contain no real secrets), but usually there is no need for them to do that, so I'd usually set the permissions for these files as strict as possible.

A strict set of permissions would be like this:
$ ll -d /home/khzs228/.ssh /home/khzs228/.ssh/authorized_keys
drwx------ <...> /home/khzs228/.ssh
-rw------- <...> /home/khzs228/.ssh/authorized_keys

One way to set the correct permissions would be:
chmod 700 /home/khzs228/.ssh
chmod 600 /home/khzs228/.ssh/authorized_keys

If the permissions are not tight enough, SSH will not trust the authorized_keys file and will require the user to enter the password.

Your problem with rdist might actually be similar: rdist uses rsh, which requires that the permissions of the /home/khzs228/.rhosts file must be "chmod 600" or "chmod 400".

The user's home directory should not be writable by anyone other than the user. Some versions of rsh and ssh will require this too.

The most relaxed useable permissions for the home directory would be:
drwxr-xr-x <...> /home/khzs228

The most strict useful permissions would of course be:
drwx------ <...> /home/khzs228

------------------

And of course, the administrator of the ukapx047 might have disabled the use of SSH keys as an authentication method. Look into /opt/ssh/etc/sshd_config file (it might be located in a different directory if you're not using HP-packaged SSH) to check.
The important setting is:

PubkeyAuthentication yes

MK