MacOS – Restricting SSH access to key-based authentication only

macosssh

So I've successfully authenticated myself with my private key, but now I want to disable passwords all together, so I can only access it with my private key.

I edit /etc/ssh/ssh_config and I add the following:

PasswordAuthentication no
PermitRootLogin no
ChallengeResponseAuthentication no
UsePAM no

at the bottom of the file. I then restart SSH with:

sudo launchctl unload /System/Library/LaunchDaemons/ssh.plist 
sudo launchctl load -w /System/Library/LaunchDaemons/ssh.plist

and I try to authenticate with a device that doesn't know my private key at all. I can log in fine just by logging in with my regular user (username@123.123.123.123).

How do I do this? I'm running El Capitan 10.11.1 on my machine.

Best Answer

You need to change your settings in /etc/ssh/sshd_config, not ssh_config. ssh_config is the global configuration file for the local ssh client software, whereas /etc/ssh/sshd_config is the configuration file for the sshd server.

Related Solutions

MacOS – Mavericks update broke ssh key-based authentication

Turns out it was about the key file name.

authorized_keys2 was the correct one to use for SSH2 keys a loooong time ago when I first configured the key-based authentication. For years, authorized_keys2 file was deprecated but still working. In Mavericks version of opensshd the support has been dropped.

This can be fixed with a simple rename:

cd ~/.ssh; mv authorized_keys2 authorized_keys

Mac – Need help understanding script running at startup? “osascript -e ‘tell app \”ARDAgent\“ to do shell script \”say quack\“’”

It seems your Mac has been compromised (at the time of your writing) in order to mine bitcoins (./bitcoin-qt.app) probably by using ARDAgent exploit or similar. The posted commands are quite advanced, however plenty of them are copy&paste commands which indicates some pseudo-hacker (with actually little knowledge) who is trying to install trojan on your system.

Find the explanation for history commands below:

1: It removing files from Trash. Maybe clearing some evidence after downloading something.
2-12: Accessing Downloads folder with a bit of trouble. Half of these commands are mis-typed, so maybe the person was in hurry or stressed out.
13-14: Finding all files which belong to an unknown user (for unknown reason).
15-20: Struggling to access your passwords in KeyChains, but most of the commands are mis-typed. This indicates very little knowledge how to use the basic shell commands. It seems he tries to access folders such as /Library/LaunchAgents, /Library/Automator, /Library/Keychains, but fails.
21: There is no command sha.
22-23: Struggling to see your processes.
24-29: Struggling to check all the system users, however present shell prompt in 25-27 indicates that these commands were copy and pasted from some hack tutorial.
34-39: Checking network configuration.
41: Disabling auto updates for Google apps.
40, 45: Log-in to remote host.
47: Checking your non-Apple kernel extensions.
48-49: Checking your non-Apple loaded jobs. Repeating the same command without sudo could indicate that the user didn't have root access.
51: Checking startup items.
57: Disabling remote desktop agent. Why?
71-72: How he managed to install htop using apt-get on OS X? I don't know.
73-164: Checking processes, what's listening on port 80 and the history of last logins.
165-225: Checking your users and files again.
228: Indicates the person is from Windows background, as the parameter /i is invalid.
226-237: Repeating the same things over and over again.
238-480: Clearing DNS caches.
241-259: Running Bitcoin client.
263-264: Pasting code into wrong window. It should be actually:
```
osascript -e 'tell app "ARDAgent" to do shell script "say quack"'
```
Which basically on successful run of ARDAgent would run command say quack which basically say loudly "quack". This suppose to test if ARDAgent is vulnerable to the attacks, but testing by using Speech Synthesis it's the worse what hacker can do, because the user will hear that and figure it out that something is wrong.
265: Testing if check_afp is vulnerable by having SUID flag.

Your action were correct by disabling SUID for ARDAgent. When you run Disk Utility and Repair Permission, it will automatically restore the right permissions (including ARDAgent), unless it has been modified. The other thing it to keep your system up-to-date and monitor logs and history more frequently.

Best Answer

Related Solutions

MacOS – Mavericks update broke ssh key-based authentication

Mac – Need help understanding script running at startup? “osascript -e ‘tell app \”ARDAgent\“ to do shell script \”say quack\“’”

Related Question