Service Desk Knowledgebase: Remote Access: Difference between revisions

From Computer Laboratory System Administration
Jump to navigationJump to search
Line 199: Line 199:
[http://www.lookup.cam.ac.uk/person/pb22 Piete Brooks] (13/03/15)
[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 '''<font color="orange">{how long please ???}</font>''' until they can make another ssh connection.
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==
==Categorising Keywords==
* ''A categorization or service type''
* ''A categorization or service type''

Revision as of 10:12, 22 December 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 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 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:
"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

SSH authorized_keys problem from IPv6 address

Martyn Johnson & Piete Brooks RT#96294 RT#97079 (2015)

Look in that host's log file by going to the named host and using sudo grep CRSid /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

Graham Titmus & 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.

  1. get them to show their University Card at UIS Reception
  2. grant them ssh access from the UIS CL VPN address range (by adding *.vpn.cl.cam.ac.uk) and them to use the VPN
  3. 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 CRSid /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/CRSid/.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

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 a few minutes before they try to make a ssh connection again.

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=3346"