Hello. I have a little VPS. I want to be able to SSH (with my ssh keys) into the non-root user. Right now I can only get into root. I have another user atrune. I have no way of logging into the server as this user though. atrune@ip is always denies even though the user exists on the server. I want to use a seperate ssh key from the root login to get into this server.
1 Like
Collect the connection log from client and server.
See also: Using a key-based authentication
1 Like
Thank you. I now know how to create ssh keys. My problem is that I can only use they keys to get into the root account. How can I add keys for the non-root user? authorized_keys seems to only work for the root account.
Eventually I want to be able to disable the root login to be more secure, but before I can do that I need to be sure I have another way of logging into the server.
ssh -i my_private_key new_acc_user_name@server_ip -v
OpenSSH_8.0p1, OpenSSL 1.1.1d FIPS 10 Sep 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/05-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: configuration requests final Match pass
debug1: re-parsing configuration
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/05-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: Connecting to server_ip [server_ip] port 22.
debug1: Connection established.
debug1: identity file my_private_key type 0
debug1: identity file my_private_key-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.0
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.0
debug1: match: OpenSSH_8.0 pat OpenSSH* compat 0x04000000
debug1: Authenticating to server_ip:22 as 'new_acc_user_name'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: aes256-gcm@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: aes256-gcm@openssh.com MAC: <implicit> compression: none
debug1: kex: curve25519-sha256 need=32 dh_need=32
debug1: kex: curve25519-sha256 need=32 dh_need=32
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:TltP9ZOBuxERczy0SLW5dhLabfXTGqN2pJztPhATv+8
debug1: Host 'server_ip' is known and matches the ECDSA host key.
debug1: Found key in /home/jason_bjorn/.ssh/known_hosts:6
debug1: rekey out after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 4294967296 blocks
debug1: Will attempt key: my_private_key RSA SHA256:bla_bla_hidden explicit
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available (default cache: KCM:)
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available (default cache: KCM:)
debug1: Next authentication method: publickey
debug1: Offering public key: my_private_key RSA SHA256:bla_bla_hidden explicit
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: No more authentication methods to try.
new_acc_user_name@server_ip: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
1 Like
Check file permissions on the server:
sudo -i -u USER_NAME
ls -l -d -Z ~ ~/.. ~/.ssh ~/.ssh/authorized_keys
[root@fedora-4gb-nbg1-1 ~]# sudo -i -u jlar
Nice! I was able to switch to my other account that way.
[root@fedora-4gb-nbg1-1 ~]# ls -l -d -Z ~ ~/.. ~/.ssh ~/.ssh/authorized_keys
dr-xr-x---. 7 root root system_u:object_r:admin_home_t:s0 4096 Oct 9 02:51 /root
dr-xr-xr-x. 18 root root system_u:object_r:root_t:s0 4096 Oct 8 00:29 /root/..
drwx------. 2 root root system_u:object_r:ssh_home_t:s0 4096 Oct 8 08:28 /root/.ssh
-rw-------. 1 root root system_u:object_r:ssh_home_t:s0 2299 Oct 8 08:33 /root/.ssh/authorized_keys
[root@fedora-4gb-nbg1-1 ~]# sudo -i -u jlar
[jlar@fedora-4gb-nbg1-1 ~]$ ls -l -d -Z ~ ~/.. ~/.ssh ~/.ssh/authorized_keys
[jlar@fedora-4gb-nbg1-1 .ssh]$ ls -l -d -Z ~ ~/.. ~/.ssh ~/.ssh/authorized_keys
drwx------. 3 jlar jlar unconfined_u:object_r:user_home_dir_t:s0 4096 Oct 9 05:47 /home/jlar
drwxr-xr-x. 3 root root system_u:object_r:home_root_t:s0 4096 Oct 9 05:57 /home/jlar/..
drwxr-xr-x. 2 root root unconfined_u:object_r:ssh_home_t:s0 4096 Oct 9 06:04 /home/jlar/.ssh
-rw-------. 1 root root unconfined_u:object_r:ssh_home_t:s0 576 Oct 9 06:08 /home/jlar/.ssh/authorized_keys
I had to create the folder /home/jlar/.ssh and the file authorized_keys inside of that folder as they did not exists originally. I then added my public key to the authorized_keys file. I then restarted the ssh process with sudo systemctl restart sshd.
Still I cannot login to the server with user jlar only root. Once I am logged in as root I can switch to jlar But I want to be able to login as jlar so I can get rid of root login already.
Also for the link you posted earlier in step 5 https://docs.fedoraproject.org/en-US/Fedora/21/html/System_Administrators_Guide/s2-ssh-configuration-keypairs.html
How can I send ssh keys to a server without the server authenticating my desktop pc? If that was the case anyone could add themselves as authorized users.
The .ssh directory in the jlar’s home directory is owned by root. It should be owned by the user itself, as well as the authotized_keys file. Such issue should be reported in the logs of the server.
So, as root:
chown jlar:jlar /home/jlar/.ssh
chown jlar:jlar /home/jlar/.ssh/authorized_keys
Out of curiosity, I didn’t understand, are you able to ssh to the server using password authentication with the jlar user?
2 Likes
@alextrune, for a little background, usually ssh is configured by default to allow login for any user existing on the server – root and ordinary users both. For this to work, user should have a valid user account on the server with password assigned and – i think – correct shell set.
As initially there’s no ssh keys on the server, you first login using password, then you can add ssh keys for each user you need – either manually or by using ssh-copy-id. After confirming you can login using ssh keys, it’s advisable to disable password login, and disable root login too – as you’ve stated you’re going to do.
You’re right, you cannot. You should be able to authenticate/login using password to use ssh-copy-id.
In addition to what @alciregi said, you want to make your .ssh directory accessible only to your jlar user. I’m not sure if it’s mandatory or good practice only:
chmod 700 ~/.ssh
If you’re unable to login to your server as user jlar using password – you’re either doing something wrong, or server has some strange configuration to forbid user logins, or something else is going wrong. I’d suggest first debugging password login, and only then proceed to ssh keys login.
Please post output of
ssh -vo PreferredAuthentications=password jlar@your_server_ip
Also please check and post the logs from you server as @vgaetera suggested in his first reply. Please post here output of
sudo journalctl -b | grep sshd
If your server doesn’t use systemd/journalctl, then we’ll check logs in the /var/log folder.
1 Like
chown jlar:jlar /home/jlar/.ssh
chown jlar:jlar /home/jlar/.ssh/authorized_keys
This worked, I can login to my server as jlar. It didn’t even ask me for the account password, just the ssh key and password for that key was enough it seems.
Also is chmod 700 ~/.ssh the same as the two command above?
ssh -vo PreferredAuthentications=password jlar@server_ip
OpenSSH_8.0p1, OpenSSL 1.1.1d FIPS 10 Sep 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/05-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: configuration requests final Match pass
debug1: re-parsing configuration
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/05-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: Connecting to server_ip [server_ip] port 22.
debug1: Connection established.
debug1: identity file /home/a_trune/.ssh/id_rsa type -1
debug1: identity file /home/a_trune/.ssh/id_rsa-cert type -1
debug1: identity file /home/a_trune/.ssh/id_dsa type -1
debug1: identity file /home/a_trune/.ssh/id_dsa-cert type -1
debug1: identity file /home/a_trune/.ssh/id_ecdsa type -1
debug1: identity file /home/a_trune/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/a_trune/.ssh/id_ed25519 type -1
debug1: identity file /home/a_trune/.ssh/id_ed25519-cert type -1
debug1: identity file /home/a_trune/.ssh/id_xmss type -1
debug1: identity file /home/a_trune/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.0
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.0
debug1: match: OpenSSH_8.0 pat OpenSSH* compat 0x04000000
debug1: Authenticating to server_ip:22 as 'jlar'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: aes256-gcm@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: aes256-gcm@openssh.com MAC: <implicit> compression: none
debug1: kex: curve25519-sha256 need=32 dh_need=32
debug1: kex: curve25519-sha256 need=32 dh_need=32
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:TltP9ZOBuxERczy0SLW5dhLabfXTGqN2pJztPhATv+8
debug1: Host 'server_ip' is known and matches the ECDSA host key.
debug1: Found key in /home/a_trune/.ssh/known_hosts:6
debug1: rekey out after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 4294967296 blocks
debug1: Will attempt key: /home/a_trune/.ssh/id_rsa
debug1: Will attempt key: /home/a_trune/.ssh/id_dsa
debug1: Will attempt key: /home/a_trune/.ssh/id_ecdsa
debug1: Will attempt key: /home/a_trune/.ssh/id_ed25519
debug1: Will attempt key: /home/a_trune/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: No more authentication methods to try.
jlar@server_ip: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
the output from sudo journalctl -b | grep sshd is way to long. I gotta figure out how I can copy it to my desktop and then remove the ip so I can post it here.
Nope, chown changes ownership of the files/folders (you’ve made user jlar owner of the .ssh and a file in it). chmod on the other hand changes access rights to file/folder (without changing owner).
From the output of ssh -vo PreferredAuthentications=password jlar@server_ip it looks to me like password ssh login (at least for jlar) is already disabled on your server. Although I’m not a major ssh specialist, I can be wrong.
We don’t need it all (I think). You can paste only entries that correspond to your failed connection attempts. I.e. note the present time, then run
ssh -o PreferredAuthentications=password
on your local computer, then select the lines from sudo journalctl -b | grep sshd with time later than what you’ve noted. They should be a few.
I think it’s also useful to check your sshd_config on your server. You can use this command to select only non-commented lines (I’ve checked it!) – and post the result here.
sudo cat /etc/ssh/sshd_config | sed -e 's/#.*//' -e 's/[ ^I]*$//' -e '/^$/ d' | less
Th output shouldn’t contain any secrets and is safe to post here.
I accidentally ran ssh -o PreferredAuthentications=password on my server. How can I undo it?
sudo cat /etc/ssh/sshd_config | sed -e 's/#.*//' -e 's/[ ^I]*$//' -e '/^$/ d' | less
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
SyslogFacility AUTHPRIV
PermitRootLogin yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no
ChallengeResponseAuthentication no
GSSAPIAuthentication yes
GSSAPICleanupCredentials no
UsePAM yes
X11Forwarding yes
PrintMotd no
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS
Subsystem sftp /usr/libexec/openssh/sftp-server
How should I disable root login but still have sudo work so I can install stuff?
Change this:
I found some guides online and did these to forbid root login
# Disallow root login over ssh
PermitRootLogin no
Will the code below only forbid logging into he server with a root password? If I only had this I could still loging via ssh key, right?
# Disallow password authentication
PasswordAuthentication no
To make the user a sudo user I ended up doing this, which worrks. I assume you method is the same but shorter.
make someone sudo user
in file /etc/sudoers
jlar ALL=(ALL) ALLYou don’t have anything to undo, Alex. ssh is the command to connect to other host by ssh, you didn’t provide any host to connect to – the command had nothing to do – and did nothing ))
You had this string in your sshd_config file:
PasswordAuthentication no
This string disables password authentication for ssh – for all users including root. That’s why you couldn’t connect to you server with other users without keys or use ssh-copy-id.
You’re mixing stuff here a bit: when you disable root ssh login – you’re just preventing anyone (yourself included) from connecting via ssh as root . This doesn’t affect local root account (or other user accounts) in any way, it doesn’t affect sudo, etc. This also doesn’t affect anything for anyone who can successfully log in – either locally or via non-root ssh connection.
I.e. this setting will just refuse to accept ssh login for root user – and nothing else.
It will forbid connecting with ssh using passwords for all user account, not only root. Yes, you still can connect with ssh using keys. And this setting prevents only logins using ssh – not local ones, not via some other means – as I’ve already said above.
1 Like
1 Like
Hi @angela5 and welcome to Ask Fedora!
It’s considered more secure to configure non-root SSH login (using SSH keys, not passwords!) and disable root login afterwards. That’s what @alextrune aimed to accomplish – and did accomplish.
You’ve mentioned droplet – is it at Digital Ocean or some other provider?
@nightromantic 
It is the third post that seems a bit or totally unrelated to the topic…
It’s not clear to me also… did @angela5 want to post some question? Or did they just want to share their experience?
The reason I’ve asked about Digital Ocean is this: I remember reading quite good and new-user-friendly how-tos on initial server setup on their knowledge base. One of the things they cover is exactly the topic of this thread (adding new user with ssh keys login). I think I’ll post the links here, they can be useful for someone with the same question.
This one talks about Centos7 and is the most close/relevant to Fedora:
It explicitly talks about disabling ssh root login, which is good. It doesn’t mention disabling password auth in ssh – which is bad in my opinion. Also it links to another article with more details about SSH keys, their generation and setup. And this one does contain recommendation to disable ssh password logins:
The steps covered in these articles are relevant independent of the distribution you’re using (though they can be done a bit differently on other distributions). Also there are distribution-specific versions of these two articles in DO’s knowledge base.
One more thing. After looking through the articles after @angela5’s post, I’ve discovered the possible reason of our initial confusion with @alextrune’s case. As @angela5 stated and as covered in some of the articles in DO’s knowledge base – if user provides an ssh key when creating a new droplet, then ssh password authentication is disabled on such a virtual server from the very beginning.
Seems likely that’s why @alextrune couldn’t connect as new user using password or use ssh-copy-id and had to copy his SSH keys for a new user manually.
It’s spam, and I’ve reported every single one as such when I saw them. I don’t know if it’s some AI thing or just somebody doing it by hand, but note it’s always barely on-topic, yet not actually answering anything, and always ends in a link that’s obviously junk.
2 Likes
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.