Service Desk Knowledgebase: Remote Access
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
sys-admin-aside@cl.cam.ac.uk.
Return to the Service Desk Knowledgebase SERVICE PORTFOLIO
Key Service Description & URLs
- Access to Computer Lab Systems
- CL Terminal Servers
- Computer Laboratory News (Twitter use @UC_CL_SysAdm)
CL Customer Documentation
- Wake-on-Lan (WoL) page gives access to remote start facilities for workstations (wait 3-4 minutes for it to appear online). See also 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
- 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: Enable remote access to Windows
basic ssh issues
The first chels 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 came from. 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 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
shows that the two 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.
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:
"A Windows installer for everything except PuTTYtel
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 lookup group cl-network-access.
Underpinning Services
- 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...
- 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:
I am passing this request over to the experts who, I'm sure, will be in contact shortly.
- 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:
I am passing this request over to the ??? team who, I'm sure, will be in contact shortly.
- RT tickets can be escalated to Firstname Lastname by changing the Owner to ??? with the Status set to new. Tell the requestor:
I am passing this request over to ??? who, I'm sure, will be in contact shortly.
Contacts
Primary
- ???@cl.cam.ac.uk (Goes to ???)
- ???@lists.cam.ac.uk (Goes to ???)
- Tel: ???
Other
Availability
- 24x7
Hints, Tips & Known Issues
Remote access to Windows workstations
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
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
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 CRSid@slogin-serv.cl.cam.ac.uk from your accounts on our Windows PCs there.
"No matching mac found" for ssh to slogin service
Piete Brooks (16/03/15)
Following 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
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 {how long please ???} until they can make another ssh connection.
Categorising Keywords
- A categorization or service type