View source for Service Desk Knowledgebase: Remote Access

[[Category:Service Desk Knowledgebase]]
<br>
This is the Remote Access content page of the CL Wiki Service Desk Knowledgebase. Its purpose is to provide information to the Service Desk team on how to handle problems and requests about this CL service. If you are involved with the provision of this CL service please feel free to add to the knowledge about that it. 

If CL staff need to '''''tell the Service Desk team''''' about problems with this service please email<br /> '''[mailto:sys-admin-aside@cl.cam.ac.uk  sys-admin-aside@cl.cam.ac.uk]'''.

Return to the Service Desk Knowledgebase [[Service Desk Knowledgebase | '''SERVICE PORTFOLIO''']] 

==Key Service Description & URLs==
* [http://www.cl.cam.ac.uk/local/sys/access/ Access to Computer Lab Systems]
* [https://www.cl.cam.ac.uk/local/sys/microsoft/terminal-servers/ CL Terminal Servers]
* [http://www.cl.cam.ac.uk/news/category/sys-admin/ Computer Laboratory News] (Twitter use '''@UC_CL_SysAdm''')

==CL Customer Documentation==
* '''[http://www-dyns.cl.cam.ac.uk/cgi/raven/boot-mc.cgi boot-mc]''' page gives access to remote start facilities for workstations using Wake-on-Lan (WoL), iAMT SOAP or WSMAN, IPMI, Xen, etc (wait 3-4 minutes for it to appear online).  See also [https://wiki.cam.ac.uk/cl-sys-admin/Service_Desk_Knowledgebase:_Linux#Waking_Up_a_Lab_Computer_which_has_BMC Waking Up a Lab Computer which has BMC].

==Further CL Sys-Admin Resources==
* http://www.wiki.cl.cam.ac.uk/clwiki/SysInfo/TgtServer ''- Ticket Granting Tickets ('''TGT''') Server''<br />[NOTE: A '''TGT''' is what you get back after you authenticate against a Kerberos authentication server (in the CL's case Active Directory). If you have a TGT you can then get Tickets which are between different principals such as you and a ssh service running on a particular machine.]
* https://dbwebserver.ad.cl.cam.ac.uk/SCG/Equipment/Inventory.aspx - ''Inventory''
* https://dbwebserver.ad.cl.cam.ac.uk/SCG/DHCP/DHCP.aspx - ''DHCP''
* https://dbwebserver.ad.cl.cam.ac.uk/SCG/Networks/Networks.aspx - ''VLANs''

* '''How To:''' [https://wiki.cam.ac.uk/cl-sys-admin/Service_Desk_Knowledgebase:_Windows#Enable_remote_login_to_Windows Enable remote access to '''Windows''']

===basic ssh issues===
The first checks to make when someone cannot connect is to ask them to send you diagnostic output.  If they are using Linux or a Mac then 
 ssh -v user@host
i.e. add a '''-v''' flag to the command will give you a trace of the connection process.
If they are using Windows then you need to temporarily add logging to the connection.  To do this start putty, select a configuration and '''Load''' it.  In the left pane click on '''Session''' then '''Logging'''.
In the logging options choose '''SSH Packets''', then below '''Always overwrite it'''.  Get them to ensure they know where the log file will be saved.  Then they can either save the settings back to a new configuration such as '''host-debug''' or simple start the connection.
After the connection fails they should email the saved log for you to inspect.  Here is a partial log split into sections to help show you what to look for:-

 OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
 debug1: Reading configuration data /etc/ssh_config
 debug1: /etc/ssh_config line 20: Applying options for *
 debug1: /etc/ssh_config line 102: Applying options for *
 debug1: Connecting to laira.cl.cam.ac.uk [2001:630:212:2a9:216:3eff:fee8:180d] port 22.
 debug1: Connection established.

this shows where the connection is going.  In this case it was using '''IPv6'''.  If it is then make sure any '''from="...."''' entry will match IPv6 addresses (the wildcard is * or *:*).  To check if this is the problem you can ask the user to use the '''-4''' flag under Linux or for Windows using Putty go to Connection/SSH/Tunnels and change Destination from Auto to use '''IPv4'''.

 .......
 debug1: Server host key: RSA b2:0a:17:ce:e3:98:c1:a7:cb:92:e2:f8:10:bf:2a:cc
 debug1: Host 'laira.cl.cam.ac.uk' is known and matches the RSA host key.
 debug1: Found key in /Users/graham/.ssh/known_hosts:1
 debug1: ssh_rsa_verify: signature correct

this shows that the remote machine is recognised and you are not trying to authenticate yourself either by Kerberos or using ssh keys.

 .......
 debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
 debug1: Next authentication method: publickey
 debug1: Trying private key: /Users/graham/.ssh/id_rsa
 debug1: Trying private key: /Users/graham/.ssh/id_dsa
 debug1: No more authentication methods to try.

shows that none of the keys matched.  If you get here then the '''from''' field is probably too restrictive. See [[Service_Desk_Knowledgebase:_Remote_Access#Can.27t_SSH_into_SLogin_Service_because_not_using_a_permitted_computer | Can't SSH into SLogin Service because not using a permitted computer]]

===slogin-serv===
http://www.cl.cam.ac.uk/news/2015/02/slogin-server-upgrade/ ''"PuTTY users should ensure that they are using PuTTY 0.64 or later."'' go to http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html & download:<br /> "A Windows installer for everything except PuTTYtel<br />Installer: 	'''putty-0.64-installer.exe'''"

===setting up ssh keys===
When a user creates new ssh key pairs they will not immediately be useful for external access.  The key needs to be collected onto the slogin servers form the users home filespace.  The best thing to do is to run the collection process  
 cl-onserver --fixsshcache
Users should also be advised to check the correctness of their authorized_keys file using '''/usr/groups/admin/cmds/check-ssh-auth.pl'''.  Helpdesk can usefully check the file of a particular user
 /usr/groups/admin/cmds/check-ssh-auth.pl --user <<crsid>>

===CL VPN via the UIS service===
All staff and students with CL accounts can use the new VPN which is run by the UIS and provides pass-through access to the CL network giving an address in '''128.232.109.0/24'''.  To setup the service follow the instructions appropriate for your operating system on the UIS website http://www.ucs.cam.ac.uk/vpn but instead of '''vpn.uis.cam.ac.uk''' connect to '''vpn.cl.cam.ac.uk'''.  
Access to the service is controlled via the [http://www.lookup.cam.ac.uk/group/cl-network-access lookup group cl-network-access].

To track down a user or other issues use [https://vpn-admin.uis.cam.ac.uk/inst/CL/troubleshooting/ the UIS management pages]

==Underpinning Services==
* [http://www.ucs.cam.ac.uk/vpn VPN] - ''UIS VPN Service''

==Customer-base for this Service==
* All staff and students of the Computer Laboratory

==Costs==
* Free to all current staff and students of the Computer Laboratory

==SLA==
* N/A

==Service Desk Call Handling Procedure==
''Escalation points and key contacts to be defined...''

* [http://helpdesk.csx.cam.ac.uk/ RT] tickets can be escalated by changing the '''Queue''' to '''backoffice''' with the '''Owner''' set to '''Nobody''' and the '''Status''' as '''new'''.  Tell the requestor:<br /> ''I am passing this request over to the experts who, I'm sure, will be in contact shortly.''

* [https://rt.cl.cam.ac.uk RT] tickets can be escalated to the ??? by changing the '''Queue''' to '''???''' with the '''Owner''' set to '''Nobody''' and the '''Status''' set to '''new'''.  Tell the requestor:<br /> ''I am passing this request over to the ??? team who, I'm sure, will be in contact shortly.''

* [https://rt.cl.cam.ac.uk RT] tickets can be escalated to [http://www.lookup.cam.ac.uk/person/crsid/CRSid Firstname Lastname] by changing the '''Owner''' to '''???'''  with the '''Status''' set to '''new'''.  Tell the requestor:<br /> ''I am passing this request over to ???  who, I'm sure, will be in contact shortly.''

== Contacts ==

'''Primary'''
* [mailto:???@cl.cam.ac.uk ???@cl.cam.ac.uk] (Goes to ???)
* [mailto:???@lists.cam.ac.uk ???@lists.cam.ac.uk] (Goes to ???)
* Tel: ???

'''Other'''
* [http://www.lookup.cam.ac.uk/person/crsid/CRSid Firstname Lastname]

==Availability==

* 24x7

==Hints, Tips & Known Issues==

===SSH authorized_keys problem from IPv6 address===
[http://www.lookup.cam.ac.uk/person/maj1 Martyn Johnson] & [http://www.lookup.cam.ac.uk/person/pb22 Piete Brooks] [https://rt.cl.cam.ac.uk/Ticket/Display.html?id=96294 RT#96294] [https://rt.cl.cam.ac.uk/Ticket/Display.html?id=97079 RT#97079] (2015)

Look in that host's log file by going to the named host and using '''sudo grep <font color="red">CRSid</font> /var/log/auth.log''' and you will probably see something like: 

  Sep 30 13:31:02 sandy sshd[8206]: Authentication tried for vrw10 with correct key but not from a permitted host
 (host='''2620:0:1000:fd1f:685d:be39:2bed:4e03''' , ip='''2620:0:1000:fd1f:685d:be39:2bed:4e03''')

An IPv6 address like '''2620:0:1000:fd1f:685d:be39:2bed:4e03''' doesn't get looked up into a host name and so it doesn't match a '''from="*.*"''' pattern in the SSH key file '''~/.ssh/authorized_keys''' because there is no dot character in it! So the answer is as follows:


We formerly recommended the use of the wildcard '''from="*.*"''' as a pattern which would match any hostname and any IP address. Unfortunately it was later realised that it does not match an IPv6 address which does not reverse map. We have therefore changed our policy and now consider '''from="*"''' to be an acceptable wildcard when "any host" is required.'

So the answer is to use '''from="*"''' in the '''~/.ssh/authorized_keys''' file for access from anywhere for both IPv6 & IPv4.  Further documentation can be found at http://www.cl.cam.ac.uk/local/sys/ssh/#multiple_user_key_pairs


[HELPDESK-ONLY NOTE: Martyn additionally commented RT#97079:  ''"Adding "::/0" to an existing "*.*" seems a retrograde step. It will end  up having essentially the same effect as a simple '''from="*"''', at least until something completely new comes along. Whilst it isn't wrong, I don't think it is something to recommend."'']

===Can't SSH into SLogin Service because not using a permitted computer===
[http://www.lookup.cam.ac.uk/person/gt19 Graham Titmus] & [http://www.lookup.cam.ac.uk/person/pb22 Piete Brooks] (23/06/15)

'''*DRAFT*'''
----
'''If the user can access from another machine and knows the full hostname, or domain name if host addresses are dynamic, of the machine which they are trying to access from:'''

They can login and edit the '''from=''' lines in their '''~/.ssh/authorized_keys''' file to include that hostname or even a range of machines (e.g. '''from="*.cam.ac.uk"''' becomes '''from="*.cam.ac.uk,*.kent.ac.uk,2001:630:212:2ab::/64"''') they want to access allow from.
----
'''If the user can login from another machine but doesn't know the full hostname of the machine they want to allow access from:'''

Get them to *temporarily* permit access from anywhere (e.g. '''from="*.cam.ac.uk"''' becomes '''from="*.cam.ac.uk,*"''').  They will get a warning email, but it will work so they can login, and then use '''last -a | head''' 
to see their machine's calling name, or if not fully reverse registered, address.  They can then edit the '''from=''' lines in their '''~/.ssh/authorized_keys''' file to include that hostname or even a range of machines and remove the anywhere ''',*''' (e.g. '''from="*.cam.ac.uk,*"''' becomes '''from="*.cam.ac.uk,*.kent.ac.uk"''')
----
'''If they are away from Cambridge and can't login at all:'''

Note that many users will be able to do it themselves (see above) once they know what to do if they can login from a machine that is already covered by their from list (which typically includes *.cal.cam.ac.uk and even *.cam.ac.uk).  If not they will need to prove who they are as follows so that you can make the edit.

# get them to show their University Card at UIS Reception
# grant them ssh access from the UIS CL VPN address range (by adding *.vpn.cl.cam.ac.uk) and them to use the VPN
# get them to acknowledge an email sent to their @cl or @cam address


Get the user to call a named host (e.g. 'sandy.cl.cam.ac.uk' rather than 'slogin-serv', which can be one of two hosts) and tell you when when it was tried.  ''They won't be allowed to login BUT their calling address will be noted in the logs.''  Look in that host's log file and see what the calling address/name was (it should be 'called with registered key, but not from permitted host')

Look in that host's log file by going to the named host and using '''sudo grep <font color="red">CRSid</font> /var/log/auth.log''' and you will probably see something like:
  '''Authentication tried for CRSid with correct key but not from a permitted host (host=edu1234.kent.ac.uk, ip=129.12.127.99).'''

Edit the '''from=''' lines in their '''/home/<font color="red">CRSid</font>/.ssh/authorized_keys''' file to include that hostname or even a range of machines (e.g. '''from="*.cam.ac.uk"''' becomes '''from="*.cam.ac.uk,*.kent.ac.uk"''')

If it gives the IP address as both host and ip, the address does not fully reverse map. In such cases use the address (129.12.127.99), a CIDR range (129.12.127.0/24), or a string wildcard (129.12.127.*).
----

===Remote access to Windows workstations===
[http://www.lookup.cam.ac.uk/person/gt19 Graham Titmus] (17/04/15)

To grant the ability to use RDP to a workstation you need to move it into an appropriate OU.

Most machine will be in one of a small number of top level OUs in the AD.  Each of those OUs contains a nested OU labelled something like '''RDP Self Manage'''.  Just move the machine into the contained OU to make the machine available form outside the Lab.

* Login to one of the AD server (i.e. adsrv01.ad.cl.cam.ac.uk)
* Open AD Users and Computers
* Right click on domain and select '''find'''
* Choose '''Computers''' form the '''Find''' menu, then enter the machine name and click '''Find now'''
* In the bottom pane right click on the computer and select properties then Objct to find where the Computer is currently.
* Move it to the contained OU labelled '''RDP Self Manage'''

===Remote Access to MPhil ACS machines===
[http://www.lookup.cam.ac.uk/person/pb22 Piete Brooks] (1/04/15)

Remote SSH access to the MPhil '''ACS machines''' is not directly to individual machines (e.g. acs-00) but instead to server ACS machines the first of which is called '''svr-acs-00'''.

===SSH into slogin-serv.cl.cam.ac.uk from the NMS Service Desk===
[http://www.lookup.cam.ac.uk/person/vrw10 Vince Woodley] (20/03/15)

If you take a copy of your '''CL.ppk''' file to the New Museums Site Service Desk you can download, install and run '''PuTTY v0.64''' & '''Paegent''' from http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html and use the '''CL.ppk''' file to access '''<font color="red">CRSid</font>@slogin-serv.cl.cam.ac.uk''' from your accounts on our Windows PCs there.

==="No matching mac found" for ssh to slogin service===
[http://www.lookup.cam.ac.uk/person/pb22 Piete Brooks] (16/03/15)

Following '''[http://www.cl.cam.ac.uk/news/2015/02/slogin-server-upgrade/ changes to the slogin service]''' around end of February and the start of March 2015, anyone unable seeing messages such as: 

  no matching mac found: client hmac-md5,
  hmac-sha1,umac-64@openssh.com,hmac-ripem d160,
  hmac-ripemd160@openssh.com,hmac-sha1-96,
  hmac-md5-96 server hmac-sha2-512-etm@openssh.com,
  hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@ openssh.com,
  umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256
  
should '''upgrade to a more recent ssh client''' (which may require upgrade of OS). If one is not available try connecting to '''slogin-oldssh.cl.cam.ac.uk''' instead but ''this service will be terminated at some point...''

===SSH from Outside the Computer Lab to a CL Linux Box Timing Out===
[http://www.lookup.cam.ac.uk/person/pb22 Piete Brooks] (13/03/15)

Computer Lab Linux boxes are configured such that if there are '''more than ssh 3 connections within 90 seconds''' from a computer '''outside of the Computer Lab network''' then the machine will automatically start '''dropping ssh packets''' because there may be a ssh brute force attack going on.  The outside computer will see this as the '''connection timing out'''.  Users will need to wait a few minutes before they try to make a ssh connection again.

==Categorising Keywords==
* ''A categorization or service type''