We've recently set up a new Linux box which is on the same local network as the rest of our machines. We want to allow only the machines on the local network to be able to SSH into the new machine, and I was going to do this by creating ssh keys and disabling password authentication.
What I've done is run ssh-keygen -t rsa -b 4096 on the new machine, copy the contents of the public key and put this in the ~/.ssh/authorized_keys file on one of the machines previously set up.
I've then gone into /etc/ssh/sshd_config on the new machine and have this:
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
Those are the only changes I made to this file, and when I try to SSH from the old machine, I get "Permission denied(publickey,gssapi-keyex,gssapi-with-mic)"
If I enable PasswordAuthentication and try to ssh I can log in by entering the user's password, but that's not the goal.
Thanks in advance,
Daniel
If the user you are trying to log in as is root, the directive
PermitRootLogin no
is denying access, regardless the authentication method.
To allow root to log in using keys only, you should set this directive to prohibit-password
Related
I have 2 machines:
Windows machine with WSL installed, that serves as a client.
Ubuntu machine, with a test-user user, that serves as a server.
Both computer are on the same network.
On the Ubuntu computer, what I did:
I used ssh-keygen to generate two keys, I copied the id_rsa file to the WSL.
Make sure the ssh service is up, with systemctl status ssh.
On the WSL, what I did:
Copied the id_rsa file as key.
Changed the permission of the key file with chmod 600 key.
Connect to the server machine :
ssh -i key test-user#XXX.XXX.XXX.XXX
This works well, but it also ask me the password of the user.
hamuto#DESKTOP-HLSFHPR:~$ ssh -i key test-user#XXX.XXX.XXX.XXX
test-user#XXX.XXX.XXX.XXX's password:
The problem with this thing is, that with Github Actions, I can't enter the password.
So I changed the file /etc/ssh/sshd_config in the server:
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no <-- I've changed that to no, and uncomment the line
#PermitEmptyPasswords no
When I retry to connect with ssh:
hamuto#DESKTOP-HLSFHPR:~$ ssh -i key test-user#XXX.XXX.XXX.XXX
test-user#XXX.XXX.XXX.XXX: Permission denied (publickey).
Why is that?
After days of research, I found the solution:
First thing first, I needed to understand that you only need one pair of key, generated on the Ubuntu server.
In the server, you have to copy the id_rsa.pub in the ~/.ssh/authorized_keys.
Set the permission correctly:
chown -R username:username /home/username/.ssh
chmod 700 /home/username/.ssh
chmod 600 /home/username/.ssh/authorized_keys
Change the value of PubkeyAuthentication in the file /etc/ssh/sshd_config to yes and uncomment it.
Copy the private id_rsa key, to the client. Set the permission to 600.
You can connect to the server:
ssh -i ~/.ssh/id_rsa test-user#XXX.XXX.XX.XX
Now it works.
I want to change the location where the Authorized SSH keys are saved. Therefore, I changed the location of the authorized keys file in /etc/ssh/sshd_config to
AuthorizedKeysFile /etc/ssh/authorized_keys/%u/authorized_keys
The ssh service was restarted with sudo systemctl restart ssh and the owner and group of the /etc/ssh/authorized_keys/user directory is the right user/group.
The server is accessible for the already included ssh keys in /etc/ssh/authorized_keys/user/authorized_keys, but adding a new ssh key from some other device to the server with ssh-copy-id -i ~/.ssh/id_rsa user#server saves the key in the default directory ~/.ssh/authorized_keys.
Grateful for any advice or help!
For anybody coming by this later, ssh-copy-id is on the client, and the sshd_config is on the server. It cannot know where to write to. It assumes the default location.
Furthermore, you don't want every user able to write into /etc/ssh/authorized_keys anyway. If you've specifically set ownership to the user for /etc/ssh/authorized_keys/user then there's no obvious benefit vs having it in the default location. The advantage of doing what you've suggested is for centralized management of keys, an advantage you only have if the users are NOT permitted to write to it.
this is what I need to realize:
keybased passwordless authentication for user root
passwordbased authentication for any other user than root
Server I need to have access to is running Debian 9 (stretch).
On my client I have I have created a keypair like this: ssh-keygen
This created the following files ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub.
Now I copied the content of ~/.ssh/id_rsa.pub into /root/.ssh/authorized_keys on the server and modified the keyfile with permission 600.
Then I modified the /etc/ssh/sshd_config on server by setting the following values:
PermitRootLogin without-password
PubkeyAuthentication yes
Now I restarted ssh service on server and tried the connection by ssh root#sub.domain.tld.
It still ends in password prompt for user root.
The outcome of ssh -vvv root#sub.domain.tld you can find here (Ubuntu Pastebin).
What did I miss to modify?
Kind regards
//neph
You should follow this tutorial, there's a lot of outdated ones. It worked for me on Ubuntu 19.04.
All you have to do is:
apt-get install libpam-google-authenticator.
Users who want to continue using ssh must each run the command google-authenticator. This tool interatively helps you to create the file ~/.google_authenticator, which contains a shared secret and emergency passcodes. It's a terminal application, but it does still display a QR code for quick loading of the shared secret into your two factor device (in my case, this is the Google Authenticator app on my Android smartphone).
Edit /etc/ssh/sshd_config. Set:
ChallengeResponseAuthentication yes
PasswordAuthentication no
AuthenticationMethods publickey,keyboard-interactive
In case you have changed them in the past, you should also check the following two settings (these are both defaults on Ubuntu):
UsePAM yes
PubkeyAuthentication yes
Run sudo service ssh reload to pick up your changes to /etc/ssh/sshd_config.
Edit /etc/pam.d/sshd and replace the line:
#include common-auth
with:
auth required pam_google_authenticator.so
That's it! Now ssh logins will require a key, and after your key is verified will additionally require proof that you hold your second factor device.
I'm using rsync to backup our server to another running an rsync daemon on our LAN using the command
rsync -av /volume1/ Public/ root#192.168.2.20:/shares/Backup/Public/
It's working great except that it requires a manual password entry, so I'd like to automate it with a key pair. Running ssh-keygen I get the below where I hit return 3 times
ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
ssh-copy-id script isn't on our system, so I used the line below to copy the password file to the backup destination server. I checked and it copied correctly
> cat /root/.ssh/id_rsa.pub | ssh root#192.168.2.20 "cat >> /root/.ssh/authorized_keys"
As a test, I ssh to the destination server to ensure there's no longer a password prompt, but I'm still getting one?
DiskStation> ssh 192.168.2.20
root#192.168.2.20's password:
I'm not strong in unix, so am likely missing something obvious. Suggestions please?
___ Edit ____
Followed up with adding the following settings to sshd_config but still no luck:
RSAAuthentication yes
PubkeyAuthentication yes
Not sure if it matters, but the machine hosting the public key as a WD Sharespace which is a Debian Lenny build.
The correct procedure for passwordless SSH is as follows:
Begin by executing the ssh-keygen command to generate a key
ssh-keygen
Once you have the key, then you can copy it to the remote server. Use this command which makes it easier
ssh-copy-id user#host
The command assumes that you are using port 22 for ssh, if not use, with xxxx being the port number
ssh-copy-id "user#host -p xxxx"
See here for a detailed description of this command
In your case, when you are editing
/etc/ssh/sshd_config
Make sure you modify PasswordAuthentication from
PasswordAuthentication yes
to
PasswordAuthentication no
then restart sshd with
service sshd restart
Make sure the key is in your chain. ssh-add ~path/to/private/key otherwise you need to do ssh -i /path/to/key . Then make sure you're using ssh root#whatever. Then make sure the file is written to the remote node properly. Try copying and pasting rather than your cat and pipe. And lastly, try restarting ssh on the remote and perform those steps again (to permit the permitrootlogin to be active).
By the way, the fact that you are trying to avoid entering passwords and then you added a passphrase for the key, makes this entire process pointless.
Question as title.
Why is this, I have used the ssh command:
ssh -i mykey.pem root#xxx-xxx-xx-xx-xxx.compute-1.amazonaws.com
But i get that error, find nothing on google. What am I doing wrong?
You log in as ec2-user as Klaus suggested:
ssh -i key.pem ec2-user#host
... and then you use sudo to run commands. E.g., to edit the /etc/hosts file which is owned by root and requires root privileges: sudo nano /etc/hosts.
Or you run sudo su to become the root user.
By default root user is not allowed to login but you can use ec2-user as indicated by others.
Once you login with ec2-user you switch to root and change the SSH configuration.
To become the root user you run:
sudo su -
Edit the SSH daemon configuration file /etc/ssh/sshd_config, e.g. by using vi, and replace the PermitRootLogin entry with the following:
PermitRootLogin without-password
Reload the SSH daemon configuration by running:
/etc/init.d/sshd reload
The message Please login as the ec2-user user rather than root user. is displayed because a command is executed when you login with the private key. To remove that command edit ~/.ssh/authorized_keys file and remove the command option. The line should start with the key type (Eg. ssh-rsa).
(*) Do at your own risk. I recommend you to leave always a console open just in case you're not able to login after you make the configuration changes.
For reference you can read the man pages:
man sshd_config
man sshd
I have encountered a similar problem when setting up a hadoop cluster on Amazon ec2.
My head node needs to have root ssh access to each worker/slave nodes. I aliased the connects by adding each slave node's IP address, private address, and alias name to the /etc/hosts/ file. (I get that data by running the command echo -e "`hostname -i`\t`hostname -f`\talias-name" where alias-name is what I call each node (head or n1 for example). Then I put that output for each node in every node's /etc/hosts file.
The problem I have been encountering is that when I type ssh n1 while in my head node to ssh into my first slave node, I get that same error message: Please login as the use "ec2-user" rather than the user "root".
So after doing some research, I figured out how to fix it.
First:
ssh into your server. non-root (ec2-user) access is fine here.
Then su - your way into root. Now vi /etc/ssh/sshd_config and
un-comment the line PermitRootLogin yes.
Exit vi editor.
Now restart ssh daemon by typing service sshd stop then service
sshd start.
Second:
Now, here is the part I had to dig for,
run vi /root/.ssh/authorized_keys
Comment out everything up to ssh-rsa. Just put a # at the beginning
of the file's content, before no-port-forwarding... and hit enter on ssh-rsa to move it to
the next line (this way you dont have to delete anything in case you
want to backtrack).
exit vi editor
Now you should be able to login to root without that error message popping up.
Also, if you are using aliases for a cluster setup; Repeat the same steps on each node. First ssh in using ec2-user then follow the steps.
After adding the IP address, private address, and alias name info to your /etc/hosts file you should be able to ssh into each node's root using the alias name for example ssh n1.
The tutorial I followed is here: https://www.youtube.com/watch?v=xrxQXfE7t9A
But it didnt discuss the problem with root login.
Hope that helps! It worked for me.
*Keep in mind that I havnt taken any security into concern. This is simply a practice/dev setup.
I think it's just asking you to login with another username. Do you happen to have a user called ec2-user? If so, try this instead:
ssh -i mykey.pem ec2-user#xxx-xxx-xx-xx-xxx.compute-1.amazonaws.com
I have faced the same problem when I tried to access my EC2 instance as 'root' through Windows PuTTY client, this is how I solved problem.
Access and edit SSH configuration file, to allow root login and password authentication.
Login as ec2-user (by default it is allowed)
Enter below command to open ssh config
sudo vi /etc/ssh/sshd_config
Edit SSH configuration file as below using vi, how to use vi editor
PermitRootLogin yes (remove # at begging if it present)
PasswordAuthentication yes
Restart SSH
sudo /etc/init.d/sshd restart
Change/set root password
sudo passwd root
type new password and re-enter it (at least 8 characters)
Exit current session and close PuTTY
exit
Try again login as root and type previously set password.
Solved!
Try compare root key file and user key file)
diff /root/.ssh/authorized_keys /home/user/.ssh/authorized_keys
...and see
For anyone like me that created a new user, copied root's .ssh dir to the new user, set ownership and STILL got this error - look at the new user's ~/.ssh/authorized_keys file. It has SSH params specified that force the prompt. Delete everything from that line up to the ssh-rsa and you'll be good to go.
Or - copy /home/ec2-user/.ssh to the new user homedir instead of /root/.ssh
Edit /etc/ssh/sshd_config, and make sure this is set:
PasswordAuthentication yes
Then reload SSH:
systemctl reload sshd.service
You can now log in as users other than ec2-user.
ssh -i mykey.pem root#xxx-xxx-xx-xx-xxx.compute-1.amazonaws.com
just replace above command to this
ssh -i mykey.pem ubuntu#xxx-xxx-xx-xx-xxx.compute-1.amazonaws.com
its working in my case
For those who are looking for a single, simple line:
sudo ssh -i ./mykey.pem ec2-user#ec2-x-xx-xxx-xxx.us-east-2.compute.amazonaws.com
Note that, you can get the line after the # from the Public IPv4 DNS section in your instance summary page.