SUBJECT: Restrictions on incoming &NAME to machines in the Lab ( &NAME and &NAME ) Executive Summary : &NAME access to nearly all &NAME machines in the Lab will soon cease to permit ' ssh &NAME ' and ' password based ' . This only effects people logging into &NAME Lab machines from outside the Lab . If you cannot connect , please try connecting to &WEBSITE , and seek help from &EMAIL &NAME &NAME &NAME Currently most machines in the Lab allow access using ssh protocols &NAME and &NAME , using password or publickey based authentication . V1 and password access are security concerns ( protocol problems and keyboard sniffers respectively ) , so &WEBSITE and &WEBSITE already has the restrictions ) . ssh-relay2 will not allow ssh &NAME connections , but will allow password based authentication . As such , if you try to login and there is a problem , try ssh-relay [ &NUM ] to check whether it is related to the changes . You should be able to use the ssh or slogin command to connect from the relay machines to your desired machine . Feel free to use the relay machines as a transition aid , but note that they will not allow such access indefinitely , so ensure that your ssh client can use publickey based &NAME access . If your remote ssh client had been using ssh &NAME to connect to Lab machines in the past , the machine may only have the ssh &NAME public key of the Lab machine , so when using ssh V2 it may complain that the key is unknown . If so , look for the host 's fingerprint on the web page &WEBSITE ssh-relay3 is &NUM &NUM : &NAME : ad : &NAME : &NUM : &NAME : c7 : &NAME : df : fd : &NUM : &NAME : &NAME : &NUM : &NUM : a2 . Better still would be to jot down the fingerprint in advance . With the fingerprint , try connecting to the host again directly , and when asked whether to continue , check the fingerprint , and continue if it is correct . Otherwise , contact sys-admin . If your client does n't support ssh &NAME or publickey , try upgrading to a later version . &NAME users can use &NAME , and &NAME users can use PuTTY . Other packages which are layered on ssh ( scp , cvs , rsync , pscp , &NAME , etc ) will be similarly effected . If you do n't have a public key , you will need to generate &NUM and arrange that the private part is available on the client ( outside the Lab ) machine , and that the public part is registered in ~ /.ssh / authorized_keys in your Lab filespace . See &WEBSITE key , register it for incoming calls , and converting it to a suitable form for the Windows ssh agent pageant ' . Use a good pass phrase to encrypt the key , and do * NOT * use any existing password . Anyone setting things up in advance can test that things are working by &WEBSITE which already has the restrictions in force .