LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Networking (http://www.linuxquestions.org/questions/linux-networking-3/)
-   -   Enabling SSH logins and configuring the firewall (http://www.linuxquestions.org/questions/linux-networking-3/enabling-ssh-logins-and-configuring-the-firewall-51930/)

Travis86 03-26-2003 09:08 PM

Enabling SSH logins and configuring the firewall
 
I'm trying to get TightVNC to work but have to enable ssh logins. How do I do this? ssh came with my distro, but I don't know how to work it.

I have a feeling that my firewall is probably blocking the ssh port. It is the default firewall that came with Red Hat, and I don't know how to work that, either. (Even if the firewall isn't a part of this, I'd still like to know how to use it.)

Thanks

twantrd 03-26-2003 10:34 PM

type 'lokkit' and there's an option to disable the firewall. Try that....
Also i believe u dont need to run TightVNC to enable ssh. ssh is like telnet except that it uses encryption. So, just use ssh as if it was telnet.

hope that helps....

-twantrd

Capt_Caveman 03-27-2003 09:34 AM

First turn on ssh using:
chkconfig sshd on

Next add the ssh clients adresses to the /etc/hosts.allow file:
sshd: xxx.xxx.xxx.xxx

Then check to see is ssh is up and listening:
netstat -la | grep ssh
You should see a line that says sshd is listening on port 22
Might need to do netstat -lna to see the port numbers

Now if you specifically told linux to enable incoming ssh connections during the initial installation process, sshd should be working. If you didn't, you will probably have to add a line to iptables to accept incoming ssh connections. Something like:
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
Might need to add:
iptables -A INPUT -p udp --dport 22 -j ACCEPT

Also do yourself a favor and disable root logins via ssh in its configuration file.

As for explaining how iptables works, it's kind of complex to explain the entire way it functions. But essentially your writing a bunch of rules that tell linux how to handle various incoming packets. The rules are organized logically into "chains" (hence the original name ipchains) where each chain describes a general category of connections (INPUT, OUTPUT, FORWARD, etc). As a packet arrives, iptables will go through each individual rule in the chain from the first rule in the chain on, to try and find a rule that matches the packet. If it finds a rule that matches, it will jump to the target (-j ACCEPT, DENY, REJECT, etc) and perform that action on the packet, ignoring the rest of the rules in the chain. If it doesn't match a rule, it will fall through the entire chain until it hits the default policy. There is also the added complexity that the chains are organized into mutliple tables that do various things such as network address translation (nat), packet filtering, etc.

Unfortunately that's a really oversimplified explanation and there is alot more to it than that, so checking out the howto's is definitely advisable:
http://www.netfilter.org
http://www.tldp.org/HOWTO/
There are alot of different flags and options that can be set and not all of them work with each other. To be honest, I think writing iptables is more like an art than a science and can be one of the harder things to do in linux.

Travis86 03-29-2003 08:25 PM

Thanks. I got SSH working, but I've still got to figure out what's the matter with TightVNC. Capt. Caveman's how-to was much easier to understand that my Linux book. I still don't know what that guy was trying to get me to do.

yoowin 06-15-2004 02:30 AM

SSH VS IPCHAINS
 
Dear All:
SSH is using port 22. If both computer A & computer B has the port enabled, keys are generated and exchanged; initial authentication; login from A to B is successful. However, when trying the initial authentication; login from B to A, it says "Secure Connection Refused" after a few times "Connection to A timed out".
Checked all file permissions, OK.

$ ssh <B_hostname> date
$ May 31 2004

However,
& ssh <A_hostname> date
& Secure Connection Refused

Questions:
1) What seems to be blocking A from autheticating B ?
2) Reply receieved while " ssh <B_hostname> date " from A, does that mean that it passed through firewalls & both ports are opened on both A & B?

Below is the ipchains from A:
-A input -s 0/0 -d 0/0 22 -p tcp -y -j ACCEPT

Should we add in:
-A output -s 0/0 -d 0/0 22 -p tcp -y -j ACCEPT

Capt_Caveman 06-15-2004 07:55 AM

It's difficult to say what's blocking the connection. Could you give us the output of the following commands:

netstat -pant
ipchains -L
ssh -vvv hostname (only the last 10 lines or so)

Travis86 06-15-2004 08:24 PM

Ummmm... Thanks for the help, but this thread is well over a year old and I think I solved this problem. It's been so long I can't remember, but I recall I did have TightTNC working for a while, so I guess I must have solved it.

Edit: Oh, I get it. Someone else asked a question. I see. I didn't read this thread very carefully, because I didn't care about it any more.

yoowin 06-16-2004 03:31 AM

Output from netstat -pant:
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 780/sshd

Output from ssh <host_B> date
OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Seeding random number generator
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: restore_uid
debug1: ssh_connect: getuid 0 geteuid 0 anon 1
debug1: Connecting to <host_B> [ip_address] port 22.
debug1: temporarily_use_uid: 0/0 (e=0)
debug1: restore_uid
debug1: temporarily_use_uid: 0/0 (e=0)
debug1: restore_uid
debug1: Connection established.

Output from ssh -v <host_A> date from hots_B:
same as above until this point,
debug1: Connecting to <host_A> [ip_address] port 22.
debug1: Connetion timed out
debug1: Secure connection refused by <host_A>

I could not get ipchains command to work - it returns "command not found"

Capt_Caveman 06-16-2004 07:53 AM

Quote:

Originally posted by Travis86
Ummmm... Thanks for the help, but this thread is well over a year old and I think I solved this problem. It's been so long I can't remember, but I recall I did have TightTNC working for a while, so I guess I must have solved it.
I think your thread got hijacked ;)

Capt_Caveman 06-16-2004 08:09 AM

Output from ssh -v <host_A> date from hots_B:
same as above until this point,
debug1: Connecting to <host_A> [ip_address] port 22.
debug1: Connetion timed out
debug1: Secure connection refused by <host_A>

I could not get ipchains command to work - it returns "command not found"


Looks like the firewall or tcp_wrappers might be the problem.

For tcp_wrappers, check the hosts.allow file and make sure there is an entry for host B.

For the firewall, first make sure you are root and just try running "ipchains" or "/sbin/ipchains"(without quotes) to make sure that ipchains is even installed (ipchains has been deprecated in favor of the newer iptables). If you still get "command not found", try running "iptables" or "/sbin/iptables" instead. Once you get one of those working, then do ipchains -L or iptables -L.

yoowin 06-17-2004 08:02 PM

From Host-A:

/sbin/iptables -L
chain INPUT <policy ACCEPT>
target prot opt source
chain FORWARD <policy ACCEPT>
target prot opt source
chain OUTPUT <policy ACCEPT>
target prot opt source

Looked at the man page ..not sure what to make up of of it.

I have checked the tcp-wrapper . /etc/hosts.allow on host B has got the entry of host A and vice versa.

yoowin 06-21-2004 09:21 PM

Output from ssh -v <host_A> date from hots_B:
same as above until this point,
debug1: Connecting to <host_A> [ip_address] port 22.
debug1: Connetion timed out
debug1: Secure connection refused by <host_A>

1) Does the "Connection timed out" come from SSH or Firewall?
2) Based on the out put of /sbin/iptables, doesn't it mean that port 22 is allowed?

Please assist

Capt_Caveman 06-21-2004 11:25 PM

1) Does the "Connection timed out" come from SSH or Firewall?
2) Based on the out put of /sbin/iptables, doesn't it mean that port 22 is allowed?


The iptables output of host A shows that it is completely open and all incoming connections should be allowed through. Given the host A can ssh into host B, I doesn't appear that either firewall has anything to do with the problem.

I can only think of one other thing that may be causing the problem. It appears that you are using key-based authentication rather than password-based. You might have generated an incompatible key or something. It would really help if you gave the out put of ssh -vvv host A (note that there are 3 v's in that command for increased verbosity in the output, rather than using -v which gives you minimal debugging messages). You might also have some luck looking at your system logs on host A to see if you can spot any error messages related to ssh. If that still isn't turing up much, try manually starting the ssh daemon (sshd) in debugging mode. The command will probably look something like /usr/sbin/sshd -ddd (again notice the 3 d's here for increased verbosity of debugging).

yoowin 06-22-2004 12:53 AM

1) Tried ssh -vvv <host_A> hostname
Usage : ssh [option] host [command]
2) Tried ssh -vv <host_A> hostname
Usage : ssh [option] host [command]

For some reasons, these 2 servers only allow 1 verbose flag.

Perhaps I should try the /usr/sbin/sshd -ddd, what shold I be looking for?

Capt_Caveman 06-22-2004 01:07 AM

For some reasons, these 2 servers only allow 1 verbose flag.
Odd. What version of linux are you running?

Perhaps I should try the /usr/sbin/sshd -ddd, what shold I be looking for?
Basically anything regarding ssh, but I would specifically look for problem regarding the key authentication or ssh protocl miss-match/incompatibility.


All times are GMT -5. The time now is 05:38 AM.