Service Desk Knowledgebase: Remote Access: Difference between revisions

From Computer Laboratory System Administration
Jump to navigationJump to search
Line 29: Line 29:
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'''.
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.
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.
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===
===slogin-serv===

Revision as of 13:28, 23 June 2015


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

CL Customer Documentation

Further CL Sys-Admin Resources

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

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
Retrieved from "https://wiki.cam.ac.uk/wiki/cl-sys-admin/index.php?title=Service_Desk_Knowledgebase:_Remote_Access&oldid=2586"