I work in a software company where average number of years of experience is 12+.

There are quite a few servers that are used by developers and QAs. In some QA machines, multiple applications are deployed that are used by various teams.

Now, the point which I think belongs to stone age is that, every single person in the office uses mstsc to access those machines, esp for logs, deployment, restarting the server etc.

They are all windows based machines and open SSH server can easily be installed and at the client end, install open ssh client and access servers to deploy etc and use tools like winscp to access logs etc.

Now, that was simple. But, everyone is so obsessed with mstsc that they do not want to believe that there is an easy way to access those servers. I faced reluctance from 2-4 members.

Sometimes, I feel I am working with stone age persons who are reluctant to change. How can I bring a change in accessing the servers?

  • What did you try so far?
    – Aida Paul
    Mar 27, 2020 at 17:28
  • 3
    Why is this a problem that you think needs to be solved? By you? Don't impose your opinions on others.
    – joeqwerty
    Mar 27, 2020 at 18:23
  • 1
    FWIW: I think SSH "belogns to the stone age". You could just VPN in and access shared folders over the network, using existing tools.
    – Alexander
    Mar 27, 2020 at 19:54

2 Answers 2


Do not proceed. An improperly setup SSH service is a major security risk

You are talking about implementing a remote administration interface onto these systems. Chances are, your system administrators have set up device-based authentication on their RDP service (what you are referring to as 'mstsc'), meaning that the client and server devices authenticate that they are who they say they are, as well as user-based authentication.

If you use a default OpenSSH install, you are creating a security risk by bypassing device authentication that is probably present on the RDP server.

If you do not have access to firewalling and/or do not limit what interfaces your OpenSSH servers listen on, you are creating a security risk by potentially exposing the service beyond the intended userbase.

If you do not securely set up logging, you're introducing a security risk by allowing users to remove accountability by removing log files.

I could go on all day. The point is, there is a lot of reluctance for very good reason. If you have setup any OpenSSH servers without authorisation, remove them now!

RDP works, is reliable, can be configured by Group Policy, and its configurations are well known in the Windows Sysadmin world. Windows SSH, which is the official Windows implementation from Microsoft and is NOT OpenSSH, is new to the Windows ecosystem and its configurations are not well known in that crowd. That's not even getting into OpenSSH, which cannot even be configured via Group Policy.

EDIT: Also, to clarify, winscp is a remote file copying program, not a log viewing one. It copies files to and from systems with SSH servers. There are many, many security related reasons why you probably don't want remote system logs on employee workstations.

  • 2
    Good answer. Also goes back to my point about not doing potentially high-risk upgrades without a compelling reason. As I pointed out in my answer, "what we're doing is Stone Age" is not a valid reason to do this. Mar 27, 2020 at 17:28
  • 2
    @EJoshuaS-ReinstateMonica I would agree. Not to mention that remote administration interfaces are one of the worst things you can haphazardly implement in the quest for something new. Mar 27, 2020 at 17:53
  • I call [citation needed] on the claim that Windows SSH is not OpenSSH.
    – user1686
    Mar 27, 2020 at 17:55
  • 2
    @user1686 Windows SSH is a forked and modified version of OpenSSH, modified and maintained by Microsoft, not the OpenSSH project, for Windows compatibility. docs.microsoft.com/en-us/windows-server/administration/openssh/… Mar 27, 2020 at 18:02
  • Great answer capturing the security risk aspect. The only improvement I suggest is to mention some well known vulnerabilities in open ssh how this also unnecessarily expands the attack surface
    – Anthony
    Mar 29, 2020 at 15:30

Beware of the logical fallacy of chronological snobbery, in which something is assumed to be better merely because it's newer.

"This is Stone Age" is not a valid reason to upgrade, especially if there are existing workflows that are already working.

Upgrades can involve a lot of work and risk, and unless there's clear evidence that what you're suggesting is significantly better people probably won't agree to make the change.

You should have a clear idea of why you think that them using this technology is a problem, or why what you're suggesting is superior. For example, is it more secure? Will it help people work faster? Are there certain features that that would enable that would be helpful for the product?

Let me emphasize again that "we're using an old technology" is not, in and of itself, a valid reason to upgrade. Otherwise, this is what's known as a "solution looking for a problem." While that's quite tempting sometimes, make sure that you're focusing on valid technical and business reasons to make changes.

Edit: It might be easier to convince people to at least give people a choice of which one to use, but I don't think that you'll have much luck convincing people to change without a clear benefit.

  • Yes. There are quite a few benefits of using SSH server. If multiple people use the same server and open tools relevant to their project, then there could be many irrelevant tools opened when another team memeber logs in using mstsc. That would be an unnecessary cluster of tools. May be one person might just want to look at the logs for which winscp should work; s/he doesn't have to do a mstsc.
    – Sara
    Mar 27, 2020 at 17:08
  • @Sara Is that actually happening right now, though? Do other people find that problematic? Mar 27, 2020 at 17:09
  • 1
    @Sara Would using SSH really have prevented that, though? Also, is it really worth changing everyone's tooling and workflow over one person wasting 10 minutes looking at the wrong log? Presumably, the change would take a lot more than 10 man-minutes to implement. Mar 27, 2020 at 17:12
  • 1
    Here is a link to an excellent presentation on why chasing after the shiniest technologies is usually a bad idea: boringtechnology.club
    – Seth R
    Mar 27, 2020 at 17:37
  • 3
    @Sara from your first comment here, it sounds like everyone is logging into this server with the same account. That is the root cause of the problem you describe (wrong apps/logs being opened upon login), not the fact that they're using mstsc. Resolve that problem - everyone logs in with their own credentials, and logs out when their task is complete.
    – alroc
    Mar 27, 2020 at 18:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .