Quote:
Originally Posted by Baps
When I am trying to login to a remote server(public ip) through ssh using linux terminel or putty, i can log through root user but unable to login through normal user. Its showing connection refused by remote server.
|
That's bad.
Quote:
Originally Posted by Baps
Iptables and selinux is disabled in remote server.
|
That's bad as well. Both should be enabled but lets deal with the SSH daemon first.
* Enable a backup access solution.
If you feel you won't be able to complete the task without making errors (and who doesn't at times), ensure you can access the system still. Here is an example in case Xinetd is installed and running. Run 'cp /etc/ssh/sshd_config /etc/ssh/sshd_config_xinetd", then create a file "/etc/xinetd.d/ssh-backup" with the following contents:
Code:
# default: on
# description: The ssh-backup service allows you to connect to your system
# using ssh on port 2022 even when the ssh daemon isn't running.
# of course it requires your config to be *sane* ;-p
# * Change the "10.0.0.0/24" range to your IP address or range.
# ** Do test if you get access.
service ssh-backup
{
disable = no
socket_type = stream
protocol = tcp
port = 2022
type = UNLISTED
wait = no
user = root
server = /usr/sbin/sshd
server_args = -i -b 1024 -u0 -4 -f /etc/ssh/sshd_config_xinetd
log_on_failure += USERID
only_from = 10.0.0.0/24
}
Now restart Xinetd and see if you can access the server on port TCP/2022.
* Enable restore on fsck-up.
Each time you work on a configuration file there is a risk of fscking up. With servers you don't have physical access to that'll be kind of a bummer because then you'll need remote access otherwise (any web-based panel) or ask your colo crew to restore things. One easy way to avoid all of that is the
make backups and restore them automagically.
For example if you're working on the SSH daemon configuration file you could:
Code:
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.1
echo 'cp -f /etc/ssh/sshd_config.1 /etc/ssh/sshd_config; service sshd restart'|/usr/bin/at $(date +%H:%M --date="+1 hour")
This example gives you exactly 1 hour to make changes work before restoring the old config. if all worked OK then you just remove the at job:
Code:
# List jobs
atq
# Say the job is number 1, to remove:
atrm 1
* Ensure unprivileged account access to the SSH service on the machine.
You need to make sure you have an unprivileged account on the machine that is allowed to access it over the network. Access the system as root account user. If the user account you try to login with exists and should be allowed access then check the systems logs to find out why login is refused. Else see /etc/pam.d for ssh* configuration with non-standard options. Else if all looks OK, see if the sshd_config already disabled password access and requires an authentication key instead. Else see if creating a new user works.
If unsure just post *exact* error messages, configuration file contents.
* Ensure unprivileged account access to root on the machine.
Because you need to maintain the machine you need root account access. Most of the time you'll be performing single tasks. For that installing Sudo is a good choice.
Search the
LQ Linux Answers for a HOWTO or read for instance directions at
http://www.linuxhomenetworking.com/w...Users_and_Sudo
If unsure post your /etc/sudoers configuration file before enabling it.
* Ensure root can't access SSH on the machine.
Search the
LQ Linux Answers for a HOWTO or read for instance directions at
http://www.puschitz.com/SecuringLinux.shtml#SecuringSSH.
* Ensure the firewall flters traffic.
Even inside a LAN having a firewall is advisable. Not only does it help with access control and routing traffic but can also serve as a diagnostic and auditing tool and addressing Single Point of Failure.
Search the
LQ Linux Answers for a HOWTO or read for instance directions at
http://www.linuxhomenetworking.com/w...Using_iptables
If unsure post your firewall script or configuration file before executing it.
This should get you started I hope. If unsure just read *then* post questions. SE Linux, more service protection (especially SSH) can be addressed later on in a new thread. And if you used the Xinetd backup SSHd please don't forget to sync the final configuration changes or else you'll still have a loophole.
