User Tools

Site Tools


securing_remote_ssh_access

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revisionBoth sides next revision
securing_remote_ssh_access [2013/01/05 06:06] – [Disable Root Logins] 206.174.106.118securing_remote_ssh_access [2013/01/05 06:07] – [Disable Root Logins] 206.174.106.118
Line 19: Line 19:
   - As root edit ''/etc/ssh/sshd_config'', find and change the ''PermitRootLogin'' option to read ''PermitRootLogin no''. Save, and restart sshd with ''/etc/init.d/sshd restart''.   - As root edit ''/etc/ssh/sshd_config'', find and change the ''PermitRootLogin'' option to read ''PermitRootLogin no''. Save, and restart sshd with ''/etc/init.d/sshd restart''.
   - Now you can either set a password on the IRLP ''repeater'' user or add your own user account. To (re)set the repeater password as root issue the following command ''passwd repeater'' and follow the prompts. You will now use this username and password when using SSH to login.   - Now you can either set a password on the IRLP ''repeater'' user or add your own user account. To (re)set the repeater password as root issue the following command ''passwd repeater'' and follow the prompts. You will now use this username and password when using SSH to login.
-  - If you are doing this change remotely, open another connection and test logging in as repeater or with your own user account, and switching to the root account before you close your current session. Otherwise you could potentially lock your self out of the system until you can gain access to the console to straighten things out.+  - If you are doing this change remotely, open another SSH session and test logging in as repeater or with your own user account, and switching to the root account before you close your current session. Otherwise you could potentially lock your self out of the system until you can gain access to the console to straighten things out.
  
 It is also a good practice to avoid using the root account unless you really need to be the super user to do something, one typo can hose an entire system before you know it's even happened. I managed to wipe most of the file system on a Unix system once, luckily it was on a test system, and with the OS install CD and yesterdays backup tape in hand I had the system restored to its previous state with-in a couple hours. If you have no disaster recovery plan, you can spend hours or even days piecing a system back-together. It is also a good practice to avoid using the root account unless you really need to be the super user to do something, one typo can hose an entire system before you know it's even happened. I managed to wipe most of the file system on a Unix system once, luckily it was on a test system, and with the OS install CD and yesterdays backup tape in hand I had the system restored to its previous state with-in a couple hours. If you have no disaster recovery plan, you can spend hours or even days piecing a system back-together.
securing_remote_ssh_access.txt · Last modified: 2013/01/28 17:55 by 142.103.194.1