No Passwords for SSH
|
| Author | Content |
|---|---|
| dotmatrix Feb 22, 2017 4:21 PM EDT |
SSH should not be used with passwords. https://wiki.debian.org/SSH#Good_practices_with_SSH_Client I go one step further and disable any and all passwords for accounts that can log in... #passwd --lock username |
| gus3 Feb 22, 2017 4:22 PM EDT |
Then how do you log in? Retina scan? Fingerprint? |
| dotmatrix Feb 22, 2017 4:39 PM EDT |
You login by typing in your passphrase for your private key... Public key authentication means your passphrase does not cross the network. Valid ssh public keys are placed in the ~/.ssh/authorized_keys and that file is protected via permissions of 600. chmod 600 ~/.ssh/authorized_keys You can create a private/public key pair via the ssh-keygen command. Once a key is made, place the public key in the authorized_keys file. And then lock the password. The only way in is to use the private key... or reset the password via local control. If you are using an IaaS, like Linode for example. If you lose your ssh private keys, you can use 'Lish' to gain local control and reset the root password. If you are using an IaaS, like Linode for example... you can limit account login to a single IP address or a few whitelisted IPs. Any login attempt from a non-whitelisted IP will need to be verified via email. So... SSH with public key auth and lock the passwords. Passwords are a bad thing. |
| mbaehrlxer Feb 23, 2017 7:20 AM EDT |
that depends on your expectations. if you loose your private keys, you are locked out permanently. private keys are fine on larger systems where you have multiple admins. because i can always ask another admin to set up my new key. but on my own machines this is much more of a concern. greetings, eMBee. |
| dotmatrix Feb 23, 2017 9:19 AM EDT |
>if you loose your private keys, you are locked out permanently. ... >but on my own machines this is much more of a concern. My above comments regarding ssh keys and locking passwords is for Internet facing machines, like servers. Internal LAN machines work fine with usernames and passwords... just make sure your firewall is working well. I pass my LAN traffic through a couple of routers... not located at 192.168.0.1 either. It's important to note that crypto keys generated in several different applications are all the same thing, just in different formats. A very common habit of frequent ssh users is to purchase a Yubikey. Then generate a PGP key pair using GNUPG. Then generate subkeys. The PGP subkeys can be reformatted as an SSH compatible key. Store the subkeys on the Yubikey, store the main keys at a separate and off-line location. Copy both the main public key and the subkey public keys to the target server's ~/.ssh/authorized_keys file... and then limit the main public key to a single IP address or subnet. So... the final keyed solution consists of a rotating subkey that can log in anywhere, and a main key which is limited to a few known IPs. A reference: https://debian-administration.org/article/685/Restricting_SSH_logins_to_particular_IP_addresses |
| gus3 Feb 23, 2017 12:54 PM EDT |
@dotmatrix, I think you miss the point of my question. You have a file containing authorized keys. When you sit down to the computer, how do you log in to get to that file? What credentials do you use, since account passwords have all been disabled? |
| penguinist Feb 23, 2017 1:40 PM EDT |
gus3: I think he is proposing disabling ssh password login and only support certificate login. Local logins from the keyboard would of course require a password. Right dm? |
| dotmatrix Feb 23, 2017 1:58 PM EDT |
>Local logins from the keyboard would of course require a password. Right dm? No. Disable the password. #passwd --lock user This places an illegal password in the /etc/shadow file. The user will not be able to login with a password either through ssh or locally. Keys only for Internet facing machines. Passwords are a bad idea... even for local logins. If you have a dual key or tri-key policy in place, you should be fine: Key 1: Short term key enabled for all IPs. Key 2: Long term key enabled only from known IP and only for emergency account access if short term key is lost. Key 3: Sys Admin key enabled only from known IP. Why no passwords? 1. If there is a vulnerability in sshd that allows a remote attacker to change public key auth to password auth... the password access will be vulnerable. 2. A local sudo attack is possible if there is a password. 3. Theft of /etc/shadow may reveal passwords. 4. Weak passwords are always a problem. And many other issues... On modern servers, there should be only a few accounts with login access anyway. Unless you're planning on giving regular users shell access and enabling USERDIR in apache for ~user1 webpages... if that's the plan, good luck. |
| dotmatrix Feb 23, 2017 3:16 PM EDT |
@gus3: If you are wondering how ssh public key auth functions, here's a decent uncomplicated summary: http://security.stackexchange.com/questions/23227/how-does-ssh-public-key-authentication-work#23243 |
| mbaehrlxer Feb 23, 2017 5:34 PM EDT |
dotmatrix: i am talking about my own, internet facing hosted servers. if i manage to lock myself out from my server, it's gone. i'd have to pay my ISP to get physical access to the machine. (that kind of support is usually not a free service), or find a way to get an image of the disk that i can manipulate from another machine. or rebuild the server and restore data from a backup. or use ISP services that can reset an ssh key for root without reinstalling (if available) (but if that service is available after installation then that means that the ISP can log in to the machine at any time) about that yubikey: instructions how to use it are here: https://www.esev.com/blog/post/2015-01-pgp-ssh-key-on-yubike... read this to get an idea of the complexity. note that it does not cover the use of the master key as a backup for ssh-login because it suggests a master-key lifetime of one year, which makes it useless for a backup key. either change the lifetime of the master key, or how about simply storing a backup of your ssh key alongside with the master key? quite a complex process. and sadly, the newest yubikey not longer comes with source-code. also, it looks like the key is made from plastic. i would hesitate to put that with my other keys. i have USB-sticks with sturdy metal cases. i believe the yubikey could have been made the same way. now about the management of the master key: IPs on anything but a public server are usually not static. and by the time i need the main key, even static IPs may have changed. i'd have to be always on guard to update the IPs that can be trusted. that makes limiting access to a few IPs problematic. and then where do you store the main key? i can't think of a place that is not under risk of it getting lost or difficult to get at. at home? things get lost at home occasionally. especially things that are not frequently used. sure, an organized person will have their important documents in a safe place where they don't get lost easily. but anything could happen. and keep in mind, even passports or birth certificates can be replaced when they are lost. if the key is lost, or the media it was stored on is damaged, and i only notice when it's to late, then there is nothing i can do. my parents home? (same, plus they are far away) a bank safe? that's expensive. but it looks like that would be the most reliable option. so it's down to a cost trade-off. how much is security worth to me? is there an alternative? long passwords? my login-passwords are more than 20 characters long. i frequently get jaw-drops when people watch me log into my laptop. how about storing multiple ssh-keys in multiple locations? same issues as storing a master key. why multiple keys and not just storing a backup of the private key? well, depending on how the key is lost, you can then disable it without having to disable your other keys. in the end, the hard part here is the complexity of the problem. i have not managed to wrap my head around what all i have to consider and keep in mind while using ssh-keys. it's not that i avoid using them, but i do keep a password-login around for a backup. greetings, eMBee. |
| dotmatrix Feb 23, 2017 6:17 PM EDT |
eMBee: I haven't been keeping track of who seems to be in which country... If you are US based, and you have one or two easily portable servers... you could transfer over to Linode. They have Lish access included by default. Lish gives you a local access port either through their web interface or an ssh interface. I have needed to use it on occasion to reset my root password, install a new key, and then lock all passwords again. BTW: One of my servers has been hit with 1955 ssh brute force attempts since Feb 1st. On this particular server, I drop all packets originating from the following countries: China. Russia. Nearly all Mid-Eastern countries. and several randomly selected IP blocks. So... if a given server is sitting on the open Internet with no mass dropping of packets, I suspect the attempts at low hanging fruit... ssh passwords... are enormous. #lastb -i will let you know. ******************** My advice to someone running an Internet facing server is: -commit to learning how to use ssh public key auth. -only use an IaaS that gives you local access included in the server rental. ******************** I use an OpenPGP smart card. I have never used a Yubikey, because I don't personally like them. GNUPG v2.1 is coming along nicely, and I expect very easy PGP key to SSH interoperability in the default applications sometime within a year or two. At the moment, if you are interested in using PGP keys with SSH... check out MonkeySphere: http://web.monkeysphere.info/ ****************** PGP keys are awesome! Each main key is like a key wallet filled with subkeys. New subkeys can be created on the fly and expired and transferred to an OpenPGP smart card and then used independently from the main key. In any case, SSH use with passwords is insecure. If a given individual understands that and is OK with the risk, then that's that... |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!