13

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

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

Workstation:
- 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.

UPD
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...
psmears
  • 330
  • 1
  • 6
Sergey Serov
  • 397
  • 3
  • 7
  • 14
  • 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 '15 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. – Sergey Serov Jun 27 '15 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 http://www.tecmint.com/5-best-practices-to-secure-and-protect-ssh-server/ you could play with limiting yourself to stronger crypto such as https://stribika.github.io/2015/01/04/secure-secure-shell.html – chicks Jun 27 '15 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! ;-) – Craig Tullis Jun 28 '15 at 19:56
  • In your case I would have already an initiated ssh private/public pair on my laptop. If it didn't happen, I would make the first ssh login on GPRS and used only later the network of the hotel. – peterh Jun 29 '15 at 05:13
  • @Craig an encouraging comment for this guy doesn't have to be turned into an OS holy war. – chicks Jun 29 '15 at 20:16
  • 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). ;-) – Craig Tullis Jun 29 '15 at 20:53

3 Answers3

26

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.

andol
  • 6,848
  • 28
  • 43
  • Thank You!! So it is secure to connect to server by SSH even through any public wi-fi? – Sergey Serov Jun 27 '15 at 13:58
  • Sorry for paranoia :(( – Sergey Serov Jun 27 '15 at 14:05
  • Assuming the caveats in the answer, yes. – andol Jun 27 '15 at 19:17
  • 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) – Hagen von Eitzen Jun 28 '15 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 '15 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 '15 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 '15 at 19:22
  • @andol True. I was assuming that you wouldn't think about forwarding your agent to a host where you aren't even sure about the host key. I am so careful with where I forward my agent to, that it didn't even occur to me that anybody might forward an agent under such circumstances. – kasperd Jun 28 '15 at 20:44
  • 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 '15 at 22:42
  • aside from the host key, what about a replay attack? – tedder42 Jul 01 '15 at 20:03
11

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!

gxx
  • 5,483
  • 2
  • 21
  • 42
Damiano Verzulli
  • 3,948
  • 1
  • 20
  • 30
5

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.

https://www.howtoforge.com/tutorial/secure-ssh-with-google-authenticator-on-centos-7

Arul Selvan
  • 1,338
  • 12
  • 11