Is it really secure to connect to a server using SSH from hotels during a journey?

- CentOS 7
- Authorisation only by RSA key - password auth is denied
- Non-standard port

- Ubuntu 14
- user password
- password to use RSA key (standard method)

Maybe it will be a good idea to keep half of the private RSA key on a USB stick, and automatically (by script) add this half to ~/.ssh/private_key before connecting?

Internet will be through either WIFI in hotels, or cable in a rented apartment.

Sorry for being unclear at first. I mean security in two aspects here:

  1. Security of just the SSH connection through an untrusted network.
  2. Security of a computer with the key necessary for the SSH connection - if it is stolen, how to protect the server...
  • What half RSA-key? The public part of the ssh host key? Half of the private part of your user ssh key?
    – andol
    Jun 27, 2015 at 13:24
  • half of my private RSA key of course :) and automatically by script to add this half to ~/.ssh/private_key before connect to server. Jun 27, 2015 at 13:38
  • You are already more secure than most folks because you are running Linux. Since you are running recent versions you should have new versions of OpenSSH which support stronger crypto. After following tecmint.com/5-best-practices-to-secure-and-protect-ssh-server you could play with limiting yourself to stronger crypto such as stribika.github.io/2015/01/04/secure-secure-shell.html
    – chicks
    Jun 27, 2015 at 14:29
  • 3
    @chicks "more secure than most folks because you are running Linux" is a silly thing to say. SSH is SSH, regardless of whether it is running on Linux, Unix (the Mac) or Windows. And we could point to plenty of extremely serious security flaws in Linux in recent history (Heartbleed, anyone?). Just saying, let's leave the silly OS flame wars on the sidelines where they belong because it distracts from the actual questions and issues. Thanks! ;-) Jun 28, 2015 at 19:56
  • 2
    @chicks I guess that's what I was trying to convey. Lots of security problems in all OS's, and Microsoft has made enormous strides since starting their "trustworthy computing* initiative several years ago. I just think the "you're more secure because Linux" thing diverts the conversation from the actual issue at hand (respectfully). ;-) Jun 29, 2015 at 20:53

3 Answers 3


So, regarding making an ssh connection over an explicitly untrusted connection.

Assuming you already have an ~/.ssh/known_hosts entry from a previous connection, yes you should be able to connect without worrying about whatever the network is safe or not. The same goes if you have some other means of verifying the ssh host key.

If you have never connected to the server before, nor having any other way of verifying the ssh host key, then you might want be more careful regarding the network you use to connect.

  • 8
    Actually, this answer applies to any situation where you want to ssh to a remote server and any part of the path is not under your full control (so practically anything apart from ssh-ing to a freshly installed localhost or over a cross-link cable) Jun 28, 2015 at 13:42
  • 1
    @Hagen: Well, technically you are right. In practice I'd say it's all about where you want to draw the line security wise. I'd argue that it's an huge difference in making a one-time gambit over a local network you mostly control vs. doing the same on a random wifi. Still, I'm all for making that initial gambit less of a risk; using ssh ca certificates, dnssec+sshfp, or something else. Just felt that that was a bit out of scope here.
    – andol
    Jun 28, 2015 at 14:05
  • 6
    It is worth noticing that if the client doesn't know the host key, then a full MITM-attack will be possible if password authentication is used. But if key based authentication is used, the attacker will only be able to impersonate the server. The attacker will not be able to also authenticate to the real server. It is difficult for an attacker to provide a convincing impersonation of the server in that case, so you may be able to notice that something is amiss before it is too late. In short: public key authentication is much safer than password authentication.
    – kasperd
    Jun 28, 2015 at 18:44
  • 2
    @kasperd: Well, if the connecting client has agent forwarding enabled even public key authentication can provide the full MITM experience. But yeah, public key authentication is definitely preferable to regular passwords, any day.
    – andol
    Jun 28, 2015 at 19:22
  • 1
    @kasperd: Well, I can easily imagine someone just discovering agent forwarding, but not fully understanding it, putting something like "Host *\n\tForwardAgent yes" in their ~/.ssh/config. People do all kind of crazy things :-)
    – andol
    Jun 28, 2015 at 22:42

In the second part of your question you seem to be worried about your notebook being stolen and, with it, your private-keys for your password-less SSH login to your servers.

Please note that this can easily be solved (the private keys issue) by storing private keys "encrypted" with a "passphrase": they can be encrypted initially, while generating with the ssh-keygen utility, by providing a passphrase at the end of the generation process or, if you already have them unencripted, using the ssh-keygen utility with -p option. Once the key is encrypted, at every login you're asked to enter the related passphrase and.... if correct, everything will proceed normally.

Also, if you don't want to enter the passphrase every time you launch the ssh client, you can use the ssh-agent: it can keep track, in memory, of unencrypted private keys. You can simply run ssh-add pointing to the file holding the encrypted key and, after asking for the passphrase, the key is added to the set managed by the ssh-agent. Afterwards, every time the SSH client require a passphrase-protected key, the ssh-agent transparently provide the related unencrypted private-key to the ssh client. So, for you, it's not needed to enter it interactively.

Please note that ssh-agent can manage plenty of keys, and obviously you can "tune" your notebook/desktop to launch the ssh-add utility (to populate the ssh-agent set of keys) at login/startup time.

Also, should someone steal your laptop, your private-keys are probably not the only "sensitive" content you're going to give out: please note that with today's Linux desktop distributions it's VERY easy to set-up a notebook relying on "encrypted" file system (the /home as a starter, but the whole / if needed). So, please, consider this also.

All of the above, obviously, does NOT apply if you DON'T rely on YOUR OWN notebook.

P.S.: as for your possibility to store the two halves of the unencrypted private key on different mediums: I strongly advice you not to do this, as maintaining the two pieces of sensitive content in an unencrypted form is much, much worse, than keeping two full copies of the whole content, encrypted!


The first part of your question is already answered by previous response. As per your second part, I would recommend to add a second factor to your ssh login using pam_google_authenticator. It is is fairly easy setup and configure on any distro. In the case where the private key you are carrying around is stolen, they can't login to your server w/ out the TOTP onetime password from google-authenticator.


You must log in to answer this question.

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