Once some basic remote access has been set up, there will be some benefit to verifying that the remote access is working. There may be some reasons why it is beneficial to perform this verification even before taking the time to further improve the security of remote logins. This section discusses those priorities (and why these priorities are fairly unique to remote access).

The most ideal instructions, for most network services, will have increasing security as the number one goal. The phrase “number one goal” refers not only to importance, but to chronology: to the idea of pursuing that goal, and performing the steps to fully take care of that goal, before performing steps related to other goals (like making a service remotely accessible). The service should not be brought online, and be made usable (by potentially less trusted people) until after security has been maximized. This priority is so that all later work isn't compromised by a security vulnerability. Normally placing security behind convenience is a concept that seems to encourage bad practices that don't feel like advice worthy of being recommended.

When following such principles, switching from a standard password routine to a better authentication method would generally be a higher priority than getting a service to work with a connection with a remote machine. Likewise, increasing security may be a higher priority than providing an easier process to perform a task (like making a text file).

However, there are some reasons why it may be preferred to delay such an increase in security. For a system where security has not yet been improved, the system should still in an environment that is well-controlled. (If this is not the case, the safest approach may be to start over on building a network in a well-controlled manner.) As an example of what is meant by a well-controlled environment, a new computer system should still be offline or connected only to a trusted network. Perhaps the network is segregated by a trusted firewall. The reality should be that having a wide-open security vulnerability is not a huge problem in certain circumstances. Those circumstances are when the vulnerable machine has always been in an environment that is completely protected and trusted, and when that vulnerable machine will continue to be in such a protected and trusted environment until the vulnerability is sealed. (Such a vulnerability can be sealed at a later time, as long as the system doesn't stop being in a protected and trusted environment until after the vulnerability is sealed.) In such a case where the system has always been safe and protected (and the still is), there may not be a need for a huge hurry to complete the increase in security.

Also, there may be fewer concerns that exist for some cases where a system where a breach in security would have minimal impact. For example, in a test, educational, or demonstration environment where the system is going to be sufficiently sanitized (though successful measures like hard drive wiping and, for the extremely paranoid, firmware verification), a compromise may be limited in how substantial the resulting problems would be.

Temporarily skipping the step of hardening secure connections even further (beyond whatever level the connections are currently hardened) may be desirable so some other tasks can be accomplished first. Here are some reasons why it may be desired to delay additional hardening of a remote access service. (Perhaps in part because remote access is a good service to set up very early, these reasons may tend to be fairly unique to remote access.)

Ultimately, at some point remote access should be tested. There may be different opinions on when these tests are performed in comparison to when other steps are taken. For simple, easy reference, it simply makes sense for the directions to be given right after the instructions on getting the remote access working. Deciding exactly when to implement the remote access is a responsibility of a network administrator.

Once a remote connection is made with the desired user, there are two checks that are worthwhile to make. One is whether or not that remote connection method is likely to be easily repeatable (including after the system reboots). Another is wehther or not the user is able to successfully gain the desired level of permissions. (For a network administrator's account, the desired permissions would generally be superuser/Administrator/root permissions.) If so, one may be able to log out of the local console of the machine that is being remoted into. After that is done, if there is a method to remotely view the console, such as VNC, presumably the local console connection may be closed.