Let’s say one creates a key with maybe:
ssh-keygen -t ed25519
And you login to some ssh server with that key like:
ssh -i ~/desktop/whatever-ed25519-key root@ip
Could you store that on a nitrokey and make it like some smart ssh solution instead of keeping a file on the computer, is that possible? How? Thanks!
First of all, do not access a remote system as user root, never ever - that’s really the worst idea!
You cannot move already existing SSH keys to an external cryptodevice.
Keys created on a cryptodevice are stored in its “innermost protected core” and can be exported if required. Personally, I would also advise against this.
I prefer the secure way. Keys are generated in the Nitrokey and only remain there. I then export the public key and distribute it to the target systems. With the help of the Nitrokey, I can then access the target systems from my various computers and therefore do not need to transport and exchange SSH private keys back and forth on insecure devices! In doing so, I also use the key material to access the Vault information in my Ansible environment, among other things.
O.K. how do I do that?
Nitrokey and SSH in German => Nitrokey 3C NFC und Nitrokey 3A mini in der Praxis unter Linux Mint 21.2 (Victoria) [Linux - Wissensdatenbank]
Nitrokey, PGP and Ansible Vault in German language => Ansible - erweitertes Konfigurationsbeispiel 7: Ansible Vault [Linux - Wissensdatenbank]
If German is not your native language, a translation service of your choice on the internet will surely help you!
Why?
Interesting… Yeah smart to generate the keys on the nitrokey. But do you have multiple nitrokeys with the same key then, if you loose one, and your only private key? I can read that another day and translate it…
Hi, for a way to arrange this, please check the following two nitrokey docs:
On completion you have a backup of your GPG keys, including one for authentication, and exported them to the nitrokey.
To use said authentication key for ssh.
HTH
Thanks! Interesting! Yeah i guess i should have learnt this a long time ago now… I started with windows, not unix, that was my mistake… Unix is the most sweet os i ever used. I have learnt some now… a little bit… cool. Thanks!
Welcome, glad if it helps. To my understanding the regular gnugpg4win(dows) also includes a powershell interface. So, the nitrokey documentation hopefully enables windows-only users to perform it too - in case a command (like “gpg keytocard”) or option is not available in the GUI.
The community guidelines mention a feature called “Reply as a Linked Topic”. I tried hard to find it, but failed, so I dare asking here, if you could please elaborate a bit why accessing a remote system as root is so such a bad idea?
Also, any hints how to execute/trigger “Reply as a Linked Topic” are highly appreciated.
Hi, I don’t know how to trigger “reply as a linked topic” but arguably your question follows-up the OP topic anyway.
In my view you can split the reasons into two groups - for the server and client. Let me give a couple examples each:
First, in the context of the OP’s question as answered by @Django, someone gaining access to the client’s keys in the regular ~/.ssh/ folder may immediately gain root access to the remote server. Naturally, it depends on local config circumstances, however it is obvious you lower the risk by authenticating as a regular user to the remote system and requiring an additional authentication (not relying on said ssh key) to gain admin (least privilege principle). Clearly, you may have to consider the server compromised if a third-party got hands on the ssh-key folder, but it may be a matter of still being able to access the server to cycle keys at least. By the way, such practice also means that you can indeed simply setup a recovery account with an ssh key to store offline and use that as when you happen to lose the (single) nitrokey where you generated the regular ‘work-day’ key on.
You can lead this additional authentication over to the server, where other reasons come into play. First, it is regular opsec practice not to use root anyway, because servers are usually multi-user/admin and you need to manage that.
Second, for the authentication it is common on server setups that applicable system config for password/key rotation don’t apply for the root account (so that you don’t lock yourself out). This in turn means it is more difficult to manage password policies for the root account than for regular users. It is, though, easy to forbid remote root login via the ssh-daemon configuration.
Also, it is much easier to deter mal-intent hack attempts (e.g. by automated bots) by outright rejecting authentication requests for the root account of a ssh-server, than to disguise it does indeed accept root login via ssh. Obviously, there are other counter-measures (rate-limiting login attempts, disabling legacy crypto protocols[1], etc), but these may be useful in any case for the bunch of bots which go on trying to guess login credentials of regular users.
So, you see there are different reasons not to use the root account for remote access. Depending on circumstances some may be more important than others, but there are few to the contrary other than “convenience”.
SSH Keys should not be the problem. Either they are password protected nowadays or - especially amongst Nitrokey users - stored on a token.
Most systems are also configured for passwordless sudo. So login as regular user is not really protecting much, once an attacker logs in.
From my professional experience, not allowing root logins serves two purposes:
