networking via cross cable

I have two PC's running RedHat 7.2 Linux. Let's call them minsk and pinsk.
Both have ethernet cards and I have connected them with a cross cable and
set up eth0 on both. I was able to run ping successfully on each PC to detect
the other.

Unfortunately, I can't ftp, scp, telnet, ssh, finger, etc. between them. That
is probably my own fault since, when I installed RedHat 7.2, I told the
installation software to set the network security at the highest level.
I routinely use pinsk on the internet, so I don't want to change its
security level but I never connect minsk to the internet, so I have no
problem changing the security levels and facilities on minsk to accomodate
logins and transfers from pinsk. The cross cable from minsk and pinsk
will only be plugged in when I'm not using pinsk to connect to the
internet, so I think that is reasonably safe.

I don't know how to modify the security on minsk to allow this and
I don't know how to actually set up these services. I have two books:
(1) RedHat Linux 9 Unleashed (2) Craig Hunt's book Linux Network Servers.
I've found (1) particularly helpful but so far I don't feel that either book
says enough about how to do this for me to figure it out. One other problem
I have with them is that (1) assumes an earlier version of Linux (RH6)
and (2) is based on a later version (RH9), whereas I'm running RH7. For
example, (1) tells me to examine a file named inetd.conf which doesn't
exist on my system.

What do I have to do to enable:
(a) ftp from pinsk to minsk?
(b) scp requests from pinsk to minsk?
(c) rlogin or ssh or telnet from pinsk to minsk?

Should I just reinstall RedHat 7.2 from scratch on minsk and this time
tell it to set network security at a low or medium level? And if I do,
is that enough for (a), (b) and (c) to work? Alternatively, I vaguely
recall that when RedHat installs from the CDROM, it asks what kind of
installation it will be. I always tell it to make it a workstation,
but I think telling it to make it a network server is also an option.
--
Ignorantly,
Allan Adler <(E-Mail Removed)>
* Disclaimer: I am a guest and *not* a member of the MIT CSAIL. My actions and
* comments do not reflect in any way on MIT. Also, I am nowhere near Boston.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

In comp.os.linux.networking Allan Adler <(E-Mail Removed)> suggested:

> I have two PC's running RedHat 7.2 Linux. Let's call them minsk and pinsk.
> Both have ethernet cards and I have connected them with a cross cable and
> set up eth0 on both. I was able to run ping successfully on each PC to detect
> the other.

> Unfortunately, I can't ftp, scp, telnet, ssh, finger, etc. between them. That
[..]

> What do I have to do to enable:
> (a) ftp from pinsk to minsk?
> (b) scp requests from pinsk to minsk?
> (c) rlogin or ssh or telnet from pinsk to minsk?

> Should I just reinstall RedHat 7.2 from scratch on minsk and this time
> tell it to set network security at a low or medium level? And if I do,

There's no need to reinstall anything, you can start "lokkit" as
root from some xterm and fill in your trusted device below
'Customize' to get things working. I'd use ssh/scp for anything,
telnet/ftp are not needed and you don't need to unplug the other
box, if configured probably, iptables will take care.

Good luck

[..]

BTW
RH 7.2 is already outdated, you should watch out for a recent
distro.
--
Michael Heiming (GPG-Key ID: 0xEDD27B94)
mail: echo (E-Mail Removed) | perl -pe 'y/a-z/n-za-m/'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFAuY5JAkPEju3Se5QRAuoGAJ40T1nlaF8I+fnY+KHQne Q0euFhKQCfaFJH
9liYCw0z/sS0p0Ts5B0Buik=
=ZMPX
-----END PGP SIGNATURE-----

Michael Heiming wrote:

>There's no need to reinstall anything, you can start "lokkit" as
>root from some xterm and fill in your trusted device below
>'Customize' to get things working. I'd use ssh/scp for anything,
>telnet/ftp are not needed and you don't need to unplug the other
>box, if configured probably, iptables will take care.

I ran lokkit on minsk and set it up with medium security and to accept ssh.
Although the two machines can ping each other and traceroute shows they
can find each other, ssh from pinsk to minsk doesn't work. It complains
that it doesn't trust the port. I rebooted minsk to see if that was the
problem, but that didn't help. I ran lokkit again and it ran with
no apparent recollection of my last session, i.e. it had high security
as the default and nothing allowed from outside. So, I did the work again
of setting security to medium and allowing outside ssh. It didn't help.

One way to check the work would be if there were some file to look at
or some program to run which would say whether minsk is set to accept
outside ssh.

After looking at the ssh man page in search of some daemon maybe named
sshd, I also tried, not knowing what I was doing, adding pinsk to minsk's
/etc/hosts.allow file, but I don't know what format pinsk should be entered
in. Since the comments in the file mention tcpd, I looked at the man page for
tcpd and then tried to run it, in case it was necessary to start it. This
caused some audible thrashing, so I stopped it with ctrl-C; maybe it was
already running, assuming that is what is supposed to run. I don't know any
way to detect it.

Anyway, I can ping in either direction between minsk and pinsk, but
I can't use ssh from pinsk to minsk. How do I accomplish this?
For those who didn't read the original posting, this is about
connecting two PC's running RedHat 7.2 with ethernet cards and getting
them to talk to each other over a cross cable.
--
Ignorantly,
Allan Adler <(E-Mail Removed)>
* Disclaimer: I am a guest and *not* a member of the MIT CSAIL. My actions and
* comments do not reflect in any way on MIT. Also, I am nowhere near Boston.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

In comp.os.linux.networking Allan Adler <(E-Mail Removed)> suggested:

> Michael Heiming wrote:

>>There's no need to reinstall anything, you can start "lokkit" as
>>root from some xterm and fill in your trusted device below
[..]

> I ran lokkit on minsk and set it up with medium security and to accept ssh.
> Although the two machines can ping each other and traceroute shows they
> can find each other, ssh from pinsk to minsk doesn't work. It complains
> that it doesn't trust the port. I rebooted minsk to see if that was the
> problem, but that didn't help. I ran lokkit again and it ran with
> no apparent recollection of my last session, i.e. it had high security
> as the default and nothing allowed from outside. So, I did the work again
> of setting security to medium and allowing outside ssh. It didn't help.

If you have done your changes and they are working, issue:

service iptables save
chkconfig iptables on

> One way to check the work would be if there were some file to look at
> or some program to run which would say whether minsk is set to accept
> outside ssh.

Now, that's a mess, try on the systems 'ssh localhost' at first,
to see if it's running at all, if not start it (as root):

/etc/init.d/sshd start
Keep sshd running after reboot:
chkconfig sshd on

To check which service will be started in which runlevel, try:

chkconfig --list

> After looking at the ssh man page in search of some daemon maybe named
> sshd, I also tried, not knowing what I was doing, adding pinsk to minsk's
> /etc/hosts.allow file, but I don't know what format pinsk should be entered

If sshd is compiled with tcp_wrapper support add to
/etc/hosts.allow

ALL: 192.168.3.3

Exchange 192.168.3.3 with the IP of the other machine.

> in. Since the comments in the file mention tcpd, I looked at the man page for
> tcpd and then tried to run it, in case it was necessary to start it. This

No, you don't run it, it will be used from services running from
(x)inetd if configured to do so.

Hope that helps?

If there are still problems, try:

ssh -vvv 192.168.3.3

Exchange 192.168.3.3 with the IP of the other machine.

Post the output if you still have problems.

--
Michael Heiming (GPG-Key ID: 0xEDD27B94)
mail: echo (E-Mail Removed) | perl -pe 'y/a-z/n-za-m/'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFAuha0AkPEju3Se5QRAve+AKDLG2mM5G72b6YdptVM77 clx2ru+QCdFCmm
jV2RVJNfjvidcF6Ppb7AxRA=
=c6qB
-----END PGP SIGNATURE-----

Thanks, I'll try these suggestions. One problem is that although I thought
there might be something named sshd, I didn't actually find one. The
command "locate sshd" turned up nothing except some documentation.
Before trying to get anything running, I executed "ssh -v localhost"
on minsk and found that I'm running openssh2.5.2p2 on that machine.
That being the case, how should the instruction

> Now, that's a mess, try on the systems 'ssh localhost' at first,
> to see if it's running at all, if not start it (as root):
>
> /etc/init.d/sshd start
> Keep sshd running after reboot:
> chkconfig sshd on

be modified?
--
Ignorantly,
Allan Adler <(E-Mail Removed)>
* Disclaimer: I am a guest and *not* a member of the MIT CSAIL. My actions and
* comments do not reflect in any way on MIT. Also, I am nowhere near Boston.

I ran lokkit, then got minsk and pinsk to ping each other and then,
following Michael Heiming's suggestion, executed on minsk:

> service iptables save
> chkconfig iptables on

Also, just in case, I modified /etc/hosts.allow according to the suggestion
(mutatis mutandis):

>/etc/hosts.allow
>
>ALL: 192.168.3.3
>
>Exchange 192.168.3.3 with the IP of the other machine.

Then I tried to ssh from pinsk to minsk.

>If there are still problems, try:
>ssh -vvv 192.168.3.3
>Exchange 192.168.3.3 with the IP of the other machine.

-v and -v -v -v produce the same amount of output in this case.

>Post the output if you still have problems.

[allan@localhost allan]$ ssh -v -v -v minsk
OpenSSH_2.5.2p2, SSH protocols 1.5/2.0, OpenSSL 0x0090600f
debug1: Seeding random number generator
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: getuid 500 geteuid 0 anon 1
debug1: Connecting to minsk [10.0.0.3] port 22.
debug1: connect: Connection refused
debug1: Trying again...
debug1: Connecting to minsk [10.0.0.3] port 22.
debug1: connect: Connection refused
debug1: Trying again...
debug1: Connecting to minsk [10.0.0.3] port 22.
debug1: connect: Connection refused
debug1: Trying again...
debug1: Connecting to minsk [10.0.0.3] port 22.
debug1: connect: Connection refused
Secure connection to minsk refused.

Just for the record, let me mention how I configured eth0 on the two machines.
On minsk, which is 10.0.0.3 according to /etc/hosts on both machines, I
configured eth0 with:
/sbin/ifconfig eth0 up (although I think it goes up at boot time on minsk)
/sbin/ifconfig eth0 10.0.0.3
/sbin/route add default gw 10.0.0.3
On pinsk, which is 10.0.0.1 according to /etc/hosts on both machines, I
configured eth0 with:
/sbin/ifconfig eth0 up
/sbin/ifconfig eth0 10.0.0.1
/sbin/route add default gw 10.0.0.1

With this arrangement, they can ping each other, as in
ping -c 3 minsk
--
Ignorantly,
Allan Adler <(E-Mail Removed)>
* Disclaimer: I am a guest and *not* a member of the MIT CSAIL. My actions and
* comments do not reflect in any way on MIT. Also, I am nowhere near Boston.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

In comp.os.linux.networking Allan Adler <(E-Mail Removed)> suggested:

[..]

>>If there are still problems, try:
>>ssh -vvv 192.168.3.3
>>Exchange 192.168.3.3 with the IP of the other machine.

>>Post the output if you still have problems.

> [allan@localhost allan]$ ssh -v -v -v minsk
> OpenSSH_2.5.2p2, SSH protocols 1.5/2.0, OpenSSL 0x0090600f
> debug1: Seeding random number generator
> debug1: Rhosts Authentication disabled, originating port will not be trusted.
> debug1: ssh_connect: getuid 500 geteuid 0 anon 1
> debug1: Connecting to minsk [10.0.0.3] port 22.
> debug1: connect: Connection refused

We still don't know if sshd is running at all on the server,
looks like it isn't.

Try:
ps aux |grep sshd
netstat -an | grep :22

From your other post, got the feeling sshd isn't installed at
all?
Try:
rpm -qa | grep ssh

You perhaps only have the client package installed.

And (as root):
which sshd

[..]

> With this arrangement, they can ping each other, as in
> ping -c 3 minsk

Fine, but did the 'ssh -v localhost' do anything different from
the above "Connection refused"?

--
Michael Heiming (GPG-Key ID: 0xEDD27B94)
mail: echo (E-Mail Removed) | perl -pe 'y/a-z/n-za-m/'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFAuu0JAkPEju3Se5QRApH3AJ4hylyKdMd5KyLEv8MJDL pBxMW+ngCdEQFf
WT2NZBvCgZevye4xoKf+dPo=
=iiRF
-----END PGP SIGNATURE-----

Michael Heiming <michael+(E-Mail Removed)> writes:

> We still don't know if sshd is running at all on the server,
> looks like it isn't.

I'm pretty sure it isn't. The command 'locate sshd' shows that there is
no file on the entire system containing the string sshd except for the
two files:
/usr/share/doc/pam_krb5-1.31/krb5afs-pam.d/sshd
/usr/share/doc/pam_krb5-1.31/pam.d/sshd

I compared them and they differ slightly. I won't post the diff unless it
seems relevant. However, this suggests that pam configuration might have
something to do with this. There is no /etc/pam.conf and the directory
/etc/pam.d contains nothing that seems related to ssh. There is a script
file named "other" which seems to be set to reject anything that is not
covered by one of the other script files in /etc/pam.d, which makes sense.

Anyway, maybe the problem is that pam.d ought to have a script file
named sshd. The files
/usr/share/doc/pam_krb5-1.31/krb5afs-pam.d/sshd
/usr/share/doc/pam_krb5-1.31/pam.d/sshd
look a lot like the script files in the directory /etc/pam.d. That
suggests that this is "documentation" in the sense that it gives you files
you can use and modify for scripts in /etc/pam.d. To test that idea, I
compared the corresponding "doc" files for passwd with the ones in
/etc/pam.d and they are in fact very similar in format but quite different
in their detailed pointers to pam libraries in /lib/security and options.
Still, the similarity does seem to offer some clues, e.g. I might simply
copy one of the above sshd scripts to /etc/pam.d. Generally speaking, I
don't think I should experiment with computer security, but since I don't
intend ever to connect minsk to the internet directly, nor to pinsk while
pinsk is connected to the internet, it seems safe to try this. However, it
would be much better to know how this kind of information is really supposed
to be used.

> Try:
> ps aux |grep sshd
> netstat -an | grep :22

I'll try this after I get offline and can connect minsk and pinsk.

> From your other post, got the feeling sshd isn't installed at
> all?
> Try:
> rpm -qa | grep ssh

openssh-2.5.2p2-5
openssh-askpass-2.5.2p2-5
openssh-clients-2.5.2p2-5
openssh-askpass-gnome-2.5.2p2-5


> You perhaps only have the client package installed.
>
> And (as root):
> which sshd

Since there is no file containing the string "sshd", which sshd
also turns up nothing.

> Fine, but did the 'ssh -v localhost' do anything different from
> the above "Connection refused"?

No. It is also the same as what I get doing it on pinsk while connected
to the internet (shown below) except that on minsk, which is connected to
nothing at the moment, getuid 500 is replaced by getuid 0:

[allan@localhost allan]$ ssh -v localhost
OpenSSH_2.5.2p2, SSH protocols 1.5/2.0, OpenSSL 0x0090600f
debug1: Seeding random number generator
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: getuid 500 geteuid 0 anon 1
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: connect: Connection refused
[4 more iterations of the two preceding lines deleted]
Secure connection to localhost refused.
--
Ignorantly,
Allan Adler <(E-Mail Removed)>
* Disclaimer: I am a guest and *not* a member of the MIT CSAIL. My actions and
* comments do not reflect in any way on MIT. Also, I am nowhere near Boston.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

In comp.os.linux.networking Allan Adler <(E-Mail Removed)> suggested:
> Michael Heiming <michael+(E-Mail Removed)> writes:

[..]

>> Try:
>> ps aux |grep sshd
>> netstat -an | grep :22

> I'll try this after I get offline and can connect minsk and pinsk.

>> From your other post, got the feeling sshd isn't installed at
>> all?
>> Try:
>> rpm -qa | grep ssh

> openssh-2.5.2p2-5
> openssh-askpass-2.5.2p2-5
> openssh-clients-2.5.2p2-5
> openssh-askpass-gnome-2.5.2p2-5

Looks like we might have found the problem, despite a pretty old
ssh version you need to upgrade you seem to miss the server
package. The same command from my box:

$ rpm -qa | grep ssh
openssh-3.8.1p1-1
openssh-server-3.8.1p1-1
openssh-clients-3.8.1p1-1
openssh-askpass-3.8.1p1-1


>> You perhaps only have the client package installed.

Looks like, upgrade your ssh package and while your at it,
install the server package, follow the already posted
instructions how to start it.

--
Michael Heiming (GPG-Key ID: 0xEDD27B94)
mail: echo (E-Mail Removed) | perl -pe 'y/a-z/n-za-m/'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFAu61eAkPEju3Se5QRArtJAKC4yUKYLqZ3PzLi0GxBaE K/pkgCmgCgjojN
TtFOf52p++ZPHxE4xgRDEr8=
=XJfU
-----END PGP SIGNATURE-----

Michael Heiming <michael+(E-Mail Removed)> writes:

> Looks like we might have found the problem, despite a pretty old
> ssh version you need to upgrade you seem to miss the server
> package. The same command from my box:
>
> $ rpm -qa | grep ssh
> openssh-3.8.1p1-1
> openssh-server-3.8.1p1-1
> openssh-clients-3.8.1p1-1
> openssh-askpass-3.8.1p1-1

> Looks like, upgrade your ssh package and while your at it,
> install the server package, follow the already posted
> instructions how to start it.

Thanks very much for all your help. I was planning to upgrade to RedHat 9
anyway, so I'll do that first and see if that gives me the server. If not,
I'll download it.
--
Ignorantly,
Allan Adler <(E-Mail Removed)>
* Disclaimer: I am a guest and *not* a member of the MIT CSAIL. My actions and
* comments do not reflect in any way on MIT. Also, I am nowhere near Boston.