|
|
| (20 intermediate revisions by 7 users not shown) |
| Line 5: |
Line 5: |
| | The user's password gives access to server login, file storage, email accounts and the like. | | The user's password gives access to server login, file storage, email accounts and the like. |
| | If a user's password is lost the administrator can reset to a new value, but not retrieve the old one. | | If a user's password is lost the administrator can reset to a new value, but not retrieve the old one. |
| − | Users can reset their passwords at www.domain.xxx/user-password
| + | Passwords must be sufficiently complex, with the rules controlled by the server administrator. |
| − | Passwords must be sufficiently complex; rules controlled by the server administrator. | |
| | | | |
| − | ===VPN Access===
| + | Users can reset their passwords at <b>www.yourserver.net/user-password</b> |
| − | To configure VPN access the administrator must configure PPTP.
| |
| | | | |
| − | First you must enable PPTP connections globally in the "Remote access" panel. Enter the number of concurrent PPTP connections that will be established. To disable all PPTP connections enter "0" (default).
| + | For windows clients, If the server is the domain PDC the user can reset his password after issuing a Ctrl+Alt+Del, Note that windows error messages may not explain clearly enough that the user password isn't [[SME_Server:Documentation:Administration_Manual:Chapter9#Changing_User_Passwords|sufficiently complex]]. |
| | | | |
| − | [[Image:RemoteAccessVPN.png]]
| + | ====Admin/root passwords==== |
| | + | Unlike user passwords, the admin/root passwords can not be set via <b>www.yourserver.net/user-password</b>, nor can they be set on a windows client via Ctrl+Alt+Del. Admin/root passwords must be set via the server manager or via the console commands ''passwd'', either on the console directly or via SSH. |
| | | | |
| − | Then you must enable VPN access for each user that will be allowed to connect via VPN to your SME Server. Use the "User" panel to configure each user that requires VPN access.
| + | ===VPN Access=== |
| | + | {{WIP box}} |
| | + | {{warning box|PPTP is UNSAFE and has been DEPRECATED. This section is in the process of being rewritten. Use VPN (qv) instead of PPTP}} |
| | + | <!--To configure VPN access the administrator must |
| | + | [[:SME_Server:Documentation:Administration_Manual:Chapter11#PPTP_.28VPN.29 | configure PPTP.]] |
| | | | |
| − | [[Image:UserAccessVPN.png]]
| + | * First Admin must enable PPTP connections globally in the "Remote access" panel. Enter the number of concurrent PPTP connections that will be established. To disable all PPTP connections enter "0" (default). |
| | | | |
| − | Now configure your VPN client. In Win XP, see Networking in Control Panel.
| + | * Then Admin must enable VPN access for each user that will be allowed to connect via VPN to your SME Server. Use the "Users" panel to configure each user that requires VPN access. |
| | | | |
| − | Establish the connection from your XP by double clicking the VPN icon for your connection & entering a valid SME user/password combination.
| + | To configure your VPN client, in Win XP, go to Networking in Control Panel. (New Connection Wizard) |
| | | | |
| − | It is suggested/advised you to use the same login name on your Windows PC as you use on sme, it's easier (& seamless) to deal with permissions for ibays etc that way.
| + | * Establish the connection from XP by double clicking the VPN icon for your connection & entering a valid SME user/password combination. Your connection to the Internet needs to be established first before you initiate the PPTP connection |
| | | | |
| − | Then map a drive etc as required like
| + | * It is suggested/advised you to use the same login name on your Windows PC as you use on sme, it's easier (& seamless) to deal with permissions for ibays etc that way. |
| − | net use M: //192.168.1.1/ibayname
| |
| | | | |
| − | {{DrawBoxNote|content= When setting up VPN make sure your subnet is not the same as your VPN, for example your location "home" has a subnet of 192.168.1.1 and your "office" is 192.168.1.1 will not allow you to VPN, you will either need to change your "home" subnet to be different or set up your server to be a unique subnet.}} | + | * When you then open up your Network Neighborhood window, you should see your server workgroup listed there. Alternatively, map a drive as required like: |
| | + | net use M: \\192.168.1.1\ibayname --> |
| | + | |
| | + | {{Note box|When setting up VPN make sure your subnet is not the same as your VPN, for example your location "home" has a subnet of 192.168.1.0 and your "office" is 192.168.1.0 will not allow you to VPN, you will either need to change your "home" subnet to be different or set up your server to be a unique subnet.}} |
| | | | |
| | ===Shell Access=== | | ===Shell Access=== |
| | + | * '''Password access''' |
| | + | If your admin allows it you can connect with just a username and password. |
| | | | |
| − | ====Connection Methods====
| + | * '''SSH Keys access''' |
| − | There are two methods of connecting to the server's shell
| |
| − | | |
| − | '''Console'''
| |
| − | This one is easy, simply use the keyboard and monitor that is connected to the box.
| |
| − | Hitting Alt+F2, Alt+F3 etc etc will switch to another session allowing you to have multiple logons at the same console, e.g. you may have "tail -f" running on a logfile on one screen while making some changes in another. This is similar to Windows XP's "Switch User" functionality, although *Nix has had the capability for years.
| |
| − | Hitting Shift & PgUp / PgDn allows you to scroll back through the last few pages of text that was output to your screen.
| |
| − | Finally, hitting CTRL+ALT+DEL will perform a controlled shutdown and restart of the system.
| |
| − | | |
| − | '''SSH''' | |
| − | This is the preferred method of connecting to SME, as you can connect from any machine with an SSH Client.
| |
| − | SSH is similar in function to Telnet, with the main difference being that it is heavily encrypted. It has many other very useful features, such as tunnelling, which are outside the scope of this section of the manual.
| |
| − | | |
| − | | |
| − | | |
| − | ====Enabling SSH====
| |
| − | | |
| − | To enable SSH access you need to log onto the server-manager and go to //Security -> Remote Access//.
| |
| − | | |
| − | There are three SSH Options Here:
| |
| − | | |
| − | '''Secure Shell Access'''
| |
| − | By default, SSH access is set to //No Access//, you need to change this to either //Allow Access Only from Local Networks// or //Allow Public Access (Entire Internet)//
| |
| − | | |
| − | //Allow Access Only from Local Networks//
| |
| − | You will ONLY be able to SSH to the server from the Local LAN subnet. So if you have set the Local IP on the server to 192.168.0.1/24 then you will only be able to connect from a machine on the same LAN, with an IP in the same subnet (192.168.0.2-192.168.0.254)
| |
| − | If you have more than LAN, which are accessed via Routers or Layer3 Switches that you want to be able to SSH to the SME server, then you will need to enter these in //Security -> Local Networks//
| |
| − | | |
| − | //Allow Public Access (Entire Internet)//
| |
| − | You will be able to SSH to the SME box from ANYWHERE. Please take note of this fact. The SME server will allow logons from ANY IP address, be it coming from the inside OR outside networks. This can potentially create a security risk, especially if you use a weak password such as a number, or dictionary word. I will cover one or two methods of increasing security if you (like me) need to be able to SSH to the SME over the internet from you-know-not-where.
| |
| − | | |
| − | | |
| − | '''Allow administrative command line access over secure shell'''
| |
| − | This basically enables or disables your ability to logon as "root" via SSH. If this is set to "No" then the root login will always get "Access Denied".
| |
| − | | |
| − | | |
| − | '''Allow secure shell access using standard passwords'''
| |
| − | This allows or denies access using passwords. If this is set to no, then you will only be able to connect if you are using a Public/Private Key pair (More later)
| |
| − | | |
| − | | |
| − | It is not recommended to have both the above options set to yes, when you have access open to the entire internet.
| |
| − | | |
| − | | |
| − | ====Logging On====
| |
| − | | |
| − | In both the above cases (SSH and Console access), there are, by default only two users that you can log on as:
| |
| − | | |
| − | '''admin'''will give you access to the "Server Console" from here you can make changes to the configuration of the server, test internet access, reboot / shutdown, set up RAID and access the Server-Manager (Using a text-based browser)
| |
| − | | |
| − | '''root''' will log you on to the console as the Super-User. BEWARE. As Root, you have full access to everything. If you don't know what you are doing, you could inadvertently delete the entire contents of the hard drive or otherwise break the server. Unless you are VERY sure of what you are doing you should always get a good backup of your system before starting to change anything.
| |
| − | | |
| − | Both the Admin and Root users share the same password.
| |
| − | If you change the Admin uisers password from the server-manager, then you are also changing the Root Password
| |
| − | | |
| − | | |
| − | ====Securing SSH With Public / Private Keys====
| |
| − | | |
| | If you need to get SSH access to your server from outside the LAN (e.g. you want to get to your work server from home) then the advised method is to use Public / Private Keys. | | If you need to get SSH access to your server from outside the LAN (e.g. you want to get to your work server from home) then the advised method is to use Public / Private Keys. |
| | | | |
| − | The Private Key is a file that sits on your client PC, and is sent by the SSH Client.
| + | During Logon, the server runs a check to see if your Private Key corresponds to its stored Public key for the user that you are trying to log on as. If they don't match then the server simply drops the TCP session. |
| − | The Public Key sits on the SME server.
| |
| − | | |
| − | During Logon, the server runs a mathamagical check to see if your Private Key corresponds to its stored Public key for the user that you are trying to log on as. | |
| − | If they don't match then the server simply drops the TCP session. There is no oportunity for a cracker to try brute forcing your root password. | |
| − | | |
| − | It really is remarkably easy to create & use a Public / Private key pair.
| |
| − | Below are instructions on how to create the Public / Private key pair for "Root".
| |
| − | Stuff you type is in !!RED!!
| |
| − | | |
| − | '''Step One - Create the Keys'''
| |
| − | Log onto the server as root and cd to ~/.ssh
| |
| − | !!cd ~/.ssh!!
| |
| − | enter the following command:
| |
| − | !!ssh-keygen -t dsa!!
| |
| − | When asked if you want a passphrase, this is up to you. If you set one, then you will still be asked for a password after the key exchange. This is an extra level of security, just incase your private key falls into unwelcome hands. I Recommend that you set a strong password.
| |
| − | Hit Enter when asked where to save the keys to.
| |
| − | | |
| − | You will now have two new files in the current Directory: id_dsa & id_dsa.pub
| |
| − | | |
| − | '''Step Two - Activate the Public Key'''
| |
| − | Enter the following command to add the Public key to the list of allowed keys for root:
| |
| − | !!cat id_dsa.pub >> authorized_keys!!
| |
| − | | |
| − | '''Step Three - Get the Private Key'''
| |
| − | Now all we need to do is get the Private Key onto your client.
| |
| − | (The Following instructions assume your ClientPC is Running Windows, and you are using Putty as your SSH Client)
| |
| − | If you are connected using ssh, then you can simply !!cat id_dsa!! then copy & paste the output into a notepad file.
| |
| − | Failing that, you can use SCP to get the file off, or move the file into an iBay and copy it out using SMB.
| |
| − | | |
| − | '''Step Four - Convert the Private Key'''
| |
| − | Once you have the file on your windows machine, you need to convert it from OpenSSH Format to PPK (Putty Private Key) format.
| |
| − | To do this you need PuttyGen. This is part of the Windows installation of Putty, but if you just downloaded the Putty.exe executable then you will need to visit ((http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html)) and download the PuttyGen executable.
| |
| − | Run PuttyGen, select Conversions -> Import Key & open your OpenSSH PrivateKey.
| |
| − | If you set a PassPhrase, you will be asked for it now.
| |
| − | Once the Key is Imported, Click "Save Private Key" and save your new ppk file somewhere safe.
| |
| − | | |
| − | '''Step Five - Use the Key & Test'''
| |
| − | Now when you use Putty, you just have to tell it to use the Private Key
| |
| − | Put your Server IP address / FQDN in the main screen as normal, then go to //Connection -> SSH -> Auth// from the menu, and browse for the PPK file you created earlier.
| |
| − | If you want, you can go back to Session, and save these settings.
| |
| | | | |
| − | Hit Login, and if your Keypair is working, you will see the following:
| + | Setup your keys with the information at [[:SSH_Public-Private_Keys]] |
| − | Using username "root".
| |
| − | Authenticating with public key "imported-openssh-key"
| |
| − | Passphrase for key "imported-openssh-key":
| |
| | | | |
| − | '''Step Six - Lock it down'''
| + | When you have SSH Keys working, the server Admin can disable logging in using passwords. |
| − | As long as the above worked, then you now need to disable logging in using passwords.
| |
| − | Go to the Server-manager, and switch Off //Allow secure shell access using standard passwords//
| |
| | | | |
| | + | * Improve user remote shell cosmetics |
| | + | Create a .bash_profile file for the user in ~ |
| | | | |
| − | And Now you are all Done!
| + | # include .bashrc if it exists |
| | + | if [ -f ~/.bashrc ]; then |
| | + | source ~/.bashrc |
| | + | fi |
Chapter 1 - Access
Passwords
The user's password gives access to server login, file storage, email accounts and the like.
If a user's password is lost the administrator can reset to a new value, but not retrieve the old one.
Passwords must be sufficiently complex, with the rules controlled by the server administrator.
Users can reset their passwords at www.yourserver.net/user-password
For windows clients, If the server is the domain PDC the user can reset his password after issuing a Ctrl+Alt+Del, Note that windows error messages may not explain clearly enough that the user password isn't sufficiently complex.
Admin/root passwords
Unlike user passwords, the admin/root passwords can not be set via www.yourserver.net/user-password, nor can they be set on a windows client via Ctrl+Alt+Del. Admin/root passwords must be set via the server manager or via the console commands passwd, either on the console directly or via SSH.
VPN Access
|
Work in Progress:
|
|
|
This page is a Work in Progress. The contents off this page may be in flux, please have a look at this page history the to see list of changes.
|
|
|
Warning:
|
|
|
PPTP is UNSAFE and has been DEPRECATED. This section is in the process of being rewritten. Use VPN (qv) instead of PPTP
|
|
Note:
|
|
|
When setting up VPN make sure your subnet is not the same as your VPN, for example your location "home" has a subnet of 192.168.1.0 and your "office" is 192.168.1.0 will not allow you to VPN, you will either need to change your "home" subnet to be different or set up your server to be a unique subnet.
|
Shell Access
If your admin allows it you can connect with just a username and password.
If you need to get SSH access to your server from outside the LAN (e.g. you want to get to your work server from home) then the advised method is to use Public / Private Keys.
During Logon, the server runs a check to see if your Private Key corresponds to its stored Public key for the user that you are trying to log on as. If they don't match then the server simply drops the TCP session.
Setup your keys with the information at SSH_Public-Private_Keys
When you have SSH Keys working, the server Admin can disable logging in using passwords.
- Improve user remote shell cosmetics
Create a .bash_profile file for the user in ~
# include .bashrc if it exists
if [ -f ~/.bashrc ]; then
source ~/.bashrc
fi
