Very Computer

I want to login remotely from the login text box in the login window.
I want to disable the remote login and force the user to login through
the login text box.  I would like to then capture the user login and
depending on a certain user, i login the user in to a remote box.  All
using CDE.

Quote:> I want to login remotely from the login text box in the login window.
> I want to disable the remote login and force the user to login through
> the login text box.  I would like to then capture the user login and
> depending on a certain user, i login the user in to a remote box.  All
> using CDE.

you can copy /usr/dt/conifg and /usr/dt/appconfig to /etc/dt

you then can edit /etc/dt/config/C/Xresources
to change the behavior of dtlogin.

to disable the remote host menu you can uncomment the line:
!Dtlogin*remote_host_menu*sensitive:      False

by removing the ! in front of it.
Now as far as captureing the user name and password and based on the user
name transparently log that user into another remote display i dont see
an easy way to do this. i cant think of anything that uses only
dtlogin and the standard sun X tools.

I did play around with this though and found a solution.

you need to install ssh on the local machine and the remote machine.
then you need to use ssh-keygen to crate an ssh key for passwordless login to
the remote host by the user you have selected to transparently login to a
remote machine.

the following are the steps you need to take to disable the remote host menu
and force a specific user to log into the remote host and run CDE.

install ssh either openssh or preferably sun's SSH which is installed by
default in Solaris 8 and 9.

make sure that sshd is running on the remote host.

mkdir /etc/dt and  run
cp -r /usr/dt/config /etc/dt/
open up /etc/dt/config/C/Xresources in a text editor and remove the ! in
!Dtlogin*remote_host_menu*sensitive:      False

create a user account on the local machine for the user you want to redirect.
login as that user and run ssh-keygen

just hit enter when prompted for a passphrase.

login to the users account on the remote machine and create the directory .ssh
in his home directory.
copy the $HOME/.ssh/id_rsa.pub file on the local machine to the
$HOME/.ssh/authorized_keys file

next you have to create a xsession script in the users home directory on the
remote machine it should look like this:

#!/bin/ksh
export DISPLAY=$1
/usr/dt/bin/Xsession

make sure this xsession script is executable or it wont work.

on the local machine create a .dtprofile file with the following contents.
SESSIONTYPE=xdm
DTSOURCEPROFILE=true

that will cause the Xsession script to run the .xsession script in the users
home directory instead of attempting to start CDE on the local machine.

the .xsession script needs to be executable and should look like this.
just replace ryoko with the name of the remote host and /opt/home/talon with
the home directory of the user on the remote host.
#!/bin/sh
scp .Xauthority ryoko:
scp .TTauthority ryoko:
ssh ryoko /opt/home/talon/xsession $HOSTNAME:0

this can also be done using rsh but its even less secure than what I've
described.

it may also be possible to encrypt all X traffic by using ssh X11 forwarding
but i havent tested that.

If youve followed the steps above this is what should happen:

1. a user logs in using dtlogin on a sun workstation.
if the user doesnt have a .dtprofile with SESSIONTYPE=xdm  in it and
a .xsession file CDE is started on the local workstation as normal.
if he does have the modified .dtsession and .xsession files it will

copy the .Xauthority and .TTauthority files to the remote host and execute the
xsession script on the remote host which sets DISPLAY to the hostname and
display number of the workstation. and runs Xsession. This will pop up CDE
running on the remote machine onto the workstation display just as if he had
logged in through a remote dtlogin on the remote machine.

Thank you for your help.  I just started reading your response and i
am still digesting it.  I have been playing with rlogin instead from
the user's sessionetc file.  As i was reading this weekend the book X
Window System User's Guide, i also got some ideas that i wanted to
try.  But my boss at this point is thinking that we may be spending
too much time with this issue, which i my own opinion does not deserve
this much work.  Here is the problem we are trying to solve.  Our
current application is a unixware app that is character based. It runs
on one server with a secondary server running as a back up of data.
These two servers run the application on large forest fires. One
server is the primary and runs the app the other is a secondary and
acts as a tape backup of the database at a specified interval.  In the
current system if a a certain user needs to use the secondary system
to access the database they need to cross login to the primary and
have the application run remotely on the secondary.  So if i am on
secondary and i type at the login prompt user1 for example, a script
knowing that this user must go to the primary system will rlogin that
user to the primary system. I personally think that Solaris has that
problem solved for us, because if i login to the remote system from
the login window, it sends me directly to the primary and brings up
the dtterm window where the application runs.  It would be nice not to
force the user to click on two more buttons, but it's not vital.  Your
solution sounds interesting but as i said we may just go the regular
route after all, howeve i am interested in what you did as we may want
to go ahead and provide such flexibility.  Thanks.