Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

My Fedora system is connected to the internet through a proxy server and we have IPs assigned to every system connected via LAN - mine has 192.168.0.103 (by the way, what is this kind of IP called? the technical term? Anybody). I was trying to setup smartsvn and found that SSH was stopped which is why it was not working. You may check my previous question SmartSVN - Unable to create new repository profile.

sshd was stopped on my system. Trying ssh root@192.168.0.103 was saying Connection refused. Then the fllowing things happened - I don't remember the exact sequence in which they happened -

  • I did service sshd start and then I got password prompt on trying to ssh.
  • I entered the correct password of root user but it kept denying saying - Permission denied, please try again..
  • I probably restarted sshd and it stopped asking for password on doing ssh root@192.168.0.103 and kept showing ssh_exchange_identification: Connection closed by remote host instead.

I checked this solution ssh_exchange_identification: Connection closed by remote host and found that -

  • my IP was present in /etc/hosts.deny - sshd: 192.168.0.103
  • There were failed login attempts in /var/log/secure.

So I deleted these things from both these files. After that, ssh root@192.168.0.103 prompted for password again but again the same problem. Entering correct password says - Permission denied, please try again.

In that file it is written

> This file describes the names of the
> hosts which are
> #     *not* allowed to use the local INET services, as decided
> #     by the '/usr/sbin/tcpd' server.

But that file cannot be viewed in text. Seems like some more setting needs to be corrected where it is set to disallow this IP for SSH connection. What do I need to fix?

I tried ssh connection from other systems connected via LAN. Permission denied to them too. I logged out and logged in after doing those file changes, restarted sshd and confirmed that those two files do not contain any such thing now.

But still not working. What am I missing. Any pointers?

Thanks,
Sandeepan

share|improve this question

3 Answers 3

up vote 3 down vote accepted

Loging into a system as root is generally considered to be a bad thing. You will probably find that the that sshd is denying root logins. Check /etc/ssh/sshd_config for the line

PermitRootLogin no

Changing no to yes and restarting sshd would allow root to log in. This is however a bad idea. You should connect as a normal user and use sudo or su to perform administrative tasks.

The IP address you have is an address from one of the private address blocks.

share|improve this answer
    
Ok thanks for the tips. For those who are interested to know why exactly "Logging into a system as root is generally considered to be a bad thing", check out serverfault.com/questions/41841/… –  Sandeepan Nath Jan 24 '11 at 12:44

Most linux systems will not permit root to connect to ssh. look for the line

PermitRootLogin no

in file /etc/ssh/sshd_config

I'd opt to use a less privileged user if you can.

share|improve this answer
    
+1 for first correct answer. It worked. –  Sandeepan Nath Jan 24 '11 at 12:42
  • Try to connect as normal user with your password. Does that work?
  • Check for line that contains "PermitRootLogin" in /etc/ssh/sshd_config. This parameter permits/denies user root to log in via ssh. If set to "no", change it to "yes" and restart ssh server. And try to login again.

You do not have to delete lines in /var/log/*. These files contains logs of previous actions, not state informations.

IP addresses 192.168.*.*, 10.*.*.*, 172.16.0.0 – 172.31.255.255 are called "private addresses" defined in RFC1918 to be used in private networks.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.