Difference between revisions of "SME Server:Documentation:User Manual:Chapter1"

From SME Server
Jump to navigationJump to search
(→‎Shell Access: info for users only)
 
(11 intermediate revisions by 5 users not shown)
Line 9: Line 9:
 
Users can reset their passwords at <b>www.yourserver.net/user-password</b>
 
Users can reset their passwords at <b>www.yourserver.net/user-password</b>
  
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.
+
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]].
 +
 
 +
====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.
  
 
===VPN Access===
 
===VPN Access===
To configure VPN access the administrator must  
+
{{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.]]
 
[[:SME_Server:Documentation:Administration_Manual:Chapter11#PPTP_.28VPN.29 | configure PPTP.]]
  
Line 26: Line 31:
  
 
* When you then open up your Network Neighborhood window, you should see your server workgroup listed there. Alternatively, map a drive as required like:
 
* 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
+
  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.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.}}
+
{{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'''
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 tunneling, which are outside the scope of this section of the manual.
 
 
 
Before a user can have shell access Admin must:
 
* enable ssh access at server-manager -> Security -> Remote Access
 
* then grant each user shell access:
 
chsh -s /bin/bash jim
 
 
 
 
 
====SSH With Passwords====
 
 
If your admin allows it you can connect with just a username and password.
 
If your admin allows it you can connect with just a username and password.
  
====Securing SSH With Public / Private Keys====
+
* '''SSH Keys access'''
 
 
 
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. <br>
+
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 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 opportunity for a cracker to try brute forcing your root password.
 
 
 
Below are instructions on how to create the Public / Private key pair using windows and putty.
 
 
 
* Create the Keys
 
Log onto the server, cd to ~/.ssh and enter the following command:
 
cd ~/.ssh
 
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
 
 
 
* 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
 
 
 
* Get the Private Key
 
Now all we need to do is get the Private Key onto your 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.
 
 
 
* 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 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.
 
 
 
* 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":
 
  
 +
When you have SSH Keys working, the server Admin can disable logging in using passwords.
  
* As long as the above worked, the server Admin can now disable logging in using passwords.
+
* Improve user remote shell cosmetics
Go to the Server-manager, and switch Off 'Allow secure shell access using standard passwords'
+
Create a .bash_profile file for the user in ~
  
Further information at http://wiki.contribs.org/SSH_Public-Private_Keys
+
# include .bashrc if it exists
 +
if [ -f ~/.bashrc ]; then
 +
    source ~/.bashrc
 +
fi

Latest revision as of 19:05, 30 June 2021


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

Warning.png 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.png Warning:
PPTP is UNSAFE and has been DEPRECATED. This section is in the process of being rewritten. Use VPN (qv) instead of PPTP



Important.png 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

  • Password access

If your admin allows it you can connect with just a username and password.

  • SSH Keys access

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