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.)
- The remote access might be using a temporary network address. In such a case, there may be some benefit to trying to accomplish some work (such as changing a network address) before taking more time consuming steps (such as improving the security of remote logins). See #lnlcltmp although that info may move.
- In reality, the priorities of hardening remote access first may not be as pleasant to implement, because it may be much nicer to use remote access, and then use a preferred text editor to do things like adding credentials and removing bad credentials. Some methods of securing a connection may involve exchanging data such as a “pre-shared key” (“PSK”), which could involve transmitting a key that is hundreds of characters, perhaps over a thousand characters long.
- There may be a desire to test the remote connection. This can help confirm that the work invested so far has a payoff. Also troubleshooting that may be needed down the road can be more focused, by starting with a focus on later steps, if testing has shown that earlier steps worked. If there are troubles with some other processes, like creating users, it can be nice to know that basic remote access was working before some changes happened, and so reversing those changes will probably still allow remote access to keep working.
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.