Unable to ssh (locked out) after upgrade from 10.1 to 10.3

I don't see how those changes will make a difference unless if trying to login as root?

It's hard to guess without seeing your whole sshd_config file before you made the changes.
 
SirDice said:
The default sshd_config allows anyone with a valid user account to login using passwords. I don't understand why those changes were necessary to allow you to login.
Click to expand...

SirDice Hmm. When I remove a user's name from the AllowUsers list, they no longer have access. I just confirmed this again. There are only 3 lines uncommented in my /etc/ssh/sshd_config, the two I mentioned above and
Code: 
Subsystem sftp /usr/libexec/sftp-server
Perhaps a different file was modified during the upgrade, not /etc/ssh/sshd_config. Are you saying the default sshd_config that I had should have been sufficient? Fyi, I am using passwordless ssh-keys for now (don't worry, I will add a password to my ssh-key) :) -- if such information is relevant for diagnostics.
 
There is no need to add password to your ssh-key. It's already far more secure than logins using a password. I don't use passwords with my ssh-key since nobody else have access to my computer. However, its up to you how you want to set it.
 
Remington said:
There is no need to add password to your ssh-key. It's already far more secure than logins using a password. I don't use passwords with my ssh-key since nobody else have access to my computer. However, its up to you how you want to set it.
Click to expand...

No, please. On a standard system your secret keyfile is readable by any process run under your user account and you'll put that secret key under an enormous risk if your key file is not protected by a PIN code (well password but technically it functions as a PIN code). Any programming error in an application that allows a remote attacker to read arbitrary files from your home directory will be able to steal your secret key.

This is the very reason why web browsers have moved to sandboxed extensions. The extensions are run in a "fake" environment where only the necessary part of the environment are present and sensitive parts of the users home directory are not available.
 
kpa said:
No, please. On a standard system your secret keyfile is readable by any process run under your user account and you'll put that secret key under an enormous risk if your key file is not protected by a PIN code (well password but technically it functions as a PIN code). Any programming error in an application that allows a remote attacker to read arbitrary files from your home directory will be able to steal your secret key.

This is the very reason why web browsers have moved to sandboxed extensions. The extensions are run in a "fake" environment where only the necessary part of the environment are present and sensitive parts of the users home directory are not available.
Click to expand...

I'm aware of this. I'm using Mac and its far less likely will be hacked or infected as compared to Windows. Also, if you set AllowUsers you@192.168.0.0/16 in sshd_config and that will only allow SSH connections from that remote IP address. Configuring firewall is another way of restricting SSH connections from specific IP range and I use non-standard port for SSH too.

I don't disagree that using password with ssh-key is good security but unnecessary if your computer is well protected. I trust Mac more than Windows. ;)
 
SirDice and Remington, you are correct that AllowUsers is not required. I was confused because when that command is used, it grants permission to only the users listed. Although when it is removed completely, all users have access (I thought no uses would have access). So now the only thing I have actually added to the entire file since being locked out is PasswordAuthentication yes. Or is this also somehow not required? If so then I'm a little confused as to why I was ever "locked out"...
 
molofishy said:
So now the only thing I have actually added to the entire file since being locked out is PasswordAuthentication yes. Or is this also somehow not required?
Click to expand...
It shouldn't be needed actually. All my systems run the default sshd_config and I can login using any valid user. Both with 'regular' passwords and by using using keys.
 
SirDice said:
It shouldn't be needed actually. All my systems run the default sshd_config and I can login using any valid user. Both with 'regular' passwords and by using using keys.
Click to expand...

Interesting. Thanks a lot for you help. I think I'm too nervous to try it though. I don't want to get locked out again. ;) Do you know how I would disable regular passwords and only allow keys?
 
To allow only keys you need to set PasswordAuthentication and ChallengeResponseAuthentication to no. Which provides an answer to the first question too, PasswordAuthentication is set to yes by default, setting it explicitly in the config doesn't actually change it.
 
SirDice said:
To allow only keys you need to set PasswordAuthentication and ChallengeResponseAuthentication to no. Which provides an answer to the first question too, PasswordAuthentication is set to yes by default, setting it explicitly in the config doesn't actually change it.
Click to expand...

SirDice, cool, but I assume I need to make sure I have already scp'd my public sshkey to authorized_keys on the server? If not, I'm locked out after I make those two changed you suggest.
 
You can do this:

1) Login using your regular password (never log off).
2) Edit sshd_config and set PasswordAuthentication and ChallengeResponseAuthentication to no and save changes.
3) Reload SSH daemon by doing this: service sshd reload
4) Make another login using your ssh key.

When sshd reloads it won't kick or kill your current connection.
 
If you are doing this remotely, the safest way is to fire up a second sshd daemon manually with a separate config file using a different port and try to login via that. If it fails, restart with lots of debug (-d) turned on and find out why. Fix and repeat.
Once you have verified the configuration works, move the test-config to the production-config, then restart the sshd daemon. That way you never have to lose your working sshd until you are confident you can switch
 
I did not find the cause. My latest hypothesis is that the machine did not reboot properly. Try rebooting a couple times or get someone else to.
 
You must log in or register to reply here.
Back
Top