We have a number of Sun boxes running Solaris 8 and 9 and we need them to login to a Server running Red Hat 5. Have edited the /etc/hosts file to include the Red Hat hostname and ip address and when I enter the hostname it acts as if it is connecting to it, but then the cursor turns into a watch face and then kicks back to the login screen. Am I missing something minor or major??? Should also state that I can connect no problem to the server using hummingbird from PCs...

What's running on the Linux box? ssh? rsh? telnet?

Check the /etc/initd.conf file on the Linux side and see what's enabled.

Highly recommend that you connect with ssh (and the suite of "s" utilities) if that's possible.

Thanks for your reply.

openssh, rsh and telnet are all running.

I presume u mean the /etc/xinetd.conf file as it's Red Hat Linux, please see contents of it below...

#
# This is the master xinetd configuration file. Settings in the
# default section will be inherited by all service configurations
# unless explicitly overridden in the service configuration. See
# xinetd.conf in the man pages for a more detailed explanation of
# these attributes.

defaults
{
# The next two items are intended to be a quick access place to
# temporarily enable or disable services.
#
# enabled =
# disabled =

# Define general logging characteristics.
log_type = SYSLOG daemon info
log_on_failure = HOST
log_on_success = PID HOST DURATION EXIT

# Define access restriction defaults
#
# no_access =
# only_from =
# max_load = 0
cps = 50 10
instances = 50
per_source = 10

# Address and networking defaults
#
# bind =
# mdns = yes
v6only = no

# setup environmental attributes
#
# passenv =
groups = yes
umask = 002

# Generally, banners are not used. This sets up their global defaults
#
# banner =
# banner_fail =
# banner_success =
}

includedir /etc/xinetd.d


There are rsh and telnet files in the /etc/xinetd.d/ directory but no ssh or openssh files. The rsh file consists of...

# default: on
# description: The rshd server is the server for the rcmd(3) routine and, \
# consequently, for the rsh(1) program. The server provides \
# remote execution facilities with authentication based on \
# privileged port numbers from trusted hosts.
service shell
{
disable = no
socket_type = stream
wait = no
user = root
log_on_success += USERID
log_on_failure += USERID
server = /usr/sbin/in.rshd
}

Those look fine -- see if you've got sshd running (on both Linux and Solaris) and, if not, get into your /etc/rc.x or /etc/init.d directories and find the start-up script (probably one of the "S99" files on Solaris) and make sure it starts on boot. You want sshd running on both to make life easier.

Once that's going, open an xterm on Solaris (not a dterm, Linux doesn't know what a dterm is) and enter
where "username" is the login name of a non-root user on the Linux box and "servername" is the name your intranet knows (from /etc/hosts.

You'll be asked questions, answer yes, just hit the carriage return for the passphrase questions (for now). You should get connected and, if you don't, you have to iron out whatever problems might exist before you can go any further -- usually, it's that sshd is not running (check /etc/services on both boxes and make sure that ssh is not commented out, for example).

Your /etc/services file should have entries like these for ssh:
Once you've got a connection, you can proceed to generate public and private keys (with ssh-keygen), edit a config file that will allow connections with X-11 forwarding and the like (come back).

Thanks again.

Can login no problem from a terminal on the solaris box using ssh.

The /etc/services file only has a tcp entry for ssh on the solaris side, i.e. no sshell or x11-ssh entries from your example above. On the server side there is no x11-ssh 6010/udp entry.

Have generated public and private keys with ssh-keygen. There is no config file in /.ssh/ and the ssh_config file in /etc/ssh/ has everything commented out. Still can't login though from the remote desktop login

So you can get to Solaris but not to Linux? Or vice-versa? Ugh! Have you got all the host names and addresses in /etc/hosts, sshd running, have you tried stopping ssh and restarting it (using the "S99" or "rc" file in the init directory)? If you edited /etc/services did you either reboot the machine or stop and restart services?

Best I can tell you is to look at the documentation for the box (Solaris can be different than Linux in some installations) and see if there's something you may have missed; e.g., when you ran ssh-keygen on Solaris, where did it say it was putting the files?

Once you've got both sides working; you can make your life easier if you take a look at Eleven SSH Tricks (http://www.linuxjournal.com/article/6602), an excellent article from Linux Journal, August, 2003. It's an easy-to-follow guide to getting SSH more... usable, let's say.

One easy one is what to do with those keys you generated.

When you ran ssh-keygen, you got two files in the .ssh directory: id_dsa and id_dsa.pub (or _rsa or whatever, all the same thing). Let's say that you did this on a machine named alpha and you want to communicate with a machine named beta.
What all that does is copy the public key from alpha to beta (and vice versa) so you can simply connect from one to the other without a password; "connect" means ssh, scp, sftp and so on. You can do this on every machine that you want to trust; just copy the .pub file to a file named the machine name (so you can keep 'em straight), copy that file to the other machine(s) .ssh directory and append it to the authorized_keys file.

You probably do not need to mess with the SSH configuration file in /etc (if it works, you're good to go, don't mess with it). But, it's convenient to have, oh, a little more convenient way of connecting and have services available. You make a config file in the .ssh directory (this is described in the article link above).

Let's say you're on alpha and want to connect to beta. Let's say that your user name on alpha is "fred" and your user name on beta is "freddy." Oh, yeah, you want X-11 services, too.

Make a config file in .ssh on alpha:
You can add as many entries to this as you like (and, maybe, some additional options) and as long as you've done the magic public key in authorized_key, you simply ssh servername and viola!

Hope this helps some.