systemd is like the service manager for your Centos and other modern Linux distributions (including Debian/Mint/Ubuntu) allows you to enable services, stop them, restart them, check their status and even reboot your system.
The key commands or arguments you will use with systemctl are the following:
list-units [PATTERN...] List loaded units
One simple way to keep your server public but almost impossible to hack via SSH is to disable password authentication over SSH. This means the only way in is via your own private key that only you should have.
Edit your /etc/ssh/sshd.conf file
Set this option
Restart your SSH server.
service sshd restart
First of all I got this error after accidentally messing up my usergroup by using usermod -G user group
When I would login using SSH keys it would fail:
sshd: Authentication refused: bad ownership or modes for directory /home/one
No worries, the fix is simple!
chmod g-w /home/use........
Just a note before you do this you should have a sure, guaranteed way into the system such as local, KVM or preferably publickey making bruteforce SSH absolutely impossible since there is no password to bruteforce and even if someone knew the password they wouldn't be able to login except from the local console (presumably you should make sure no one unauthorized has physical access).
1. Edit /etc/ssh/sshd_config
Find the section like this:........
This can be a case of bad permissions or modes as the error says. Normally one would assume permissions but often a script may change ownership of /root to something else.
This was the case half the time I've encountered this.
So in short make sure ownership is correct
chown -R root.root /root........
It all comes down to a bug essentially where you are running an older kernel that doesn't support the newer Debian templates. The solution is to update your OpenVZ kernel.
Here are some symptoms of the problem/lack of kernel support:
Ubuntu Template 12.04 requires a manual network start:
service networking start
sshd will not start:
PRNG is not seeded
mknod /dev/random c 1 8........
Use netstat with the -anpe option. The e option shows the inodes and I do not know if it will always work or if it was by fluke but I was dealing with dozens of SSH sessions and needed to know which session was related to which forward (the PIDs of the SSH and SSHD did not match etc...)
Notice the "59560675" and "59560762" those are almost identical, if you find two sets that are nearly identical except for the last 3 digits they may match (in my ca........
pxe-32 tftp open timeout
The solution was to enable tftp in xinetd with "chkconfig tftp on".
See the troubleshooting below:
NetworkManager 0:off 1:off 2:off 3:off 4:off 5:off 6:off
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.1.253 [192.168.1.253] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_d........
I had a system running a 128MB live CD image with 2.8 gigs of available RAM and the OOM kernel killer went crazy when using dd for more than 8 minutes and kept killing everything. I've read that this is due to a low-memory issue and paging in the kernel and 32-bit systems with lots of RAM.
I even enabled swapspace on my LiveCD and the issue happened 25 minutes into dd rather than 8 minutes, so what gives?
Also no swap space was ever used!
sshd: Authentication refused: bad ownership or modes for file /root/.ssh/authorized_keys
I made sure the entire .ssh subdir is owned by the user root (this is root's account);
chown -R root.root .ssh
chmod 600 .ssh/authorized_keys
but it still doesn't work and gives me the same message
sshd: Authentication refused: bad ownership or modes for directory /root
chmod 700 /root........
This is a very simple solution, but most guides out there make you login twice (once to scp the key) and once to put the key in authorized_keys. There's no need for that.
If you don't already have a ~/.ssh/id_rsa.pub just type "ssh-keygen -t rsa" and keep hitting enter until it's done :)
Just use this code to easily enable passwordless login with SSHD
key=`cat ~/.ssh/id_rsa.pub`;ssh email@example.com "echo $key >> ~/.ssh/auth........
SSH automatic login without passwordlocal> ssh-keygen -t rsa -f .ssh/id_rsa
-t is the encryption type
-f tells where to store the public/private key pairs. In this case, the .ssh directory on home is being used
A password will be asked; leave this part blank, just pressing <enter>
Now, go the .ssh directory, and you will find two new files: id_dsa and id_dsa.pub. The last one is the public part. Now, copy the public key to the serv........
Updated to Version 3.8 and can't loginSSHD accepts my password but then hangs at "Last login: Wed Sep 13 21:30:02 2006 from"
This occurred during a yum update after upgrading my release, installing the new kernel and rebooting.
I got kicked out of sshd after seeing the following during yum update:
telnet 100 % done 85/476
tux 100 % done 86/476
ntsysv 100 % done 87/476
rpmdb-redhat 94 % done 88/476........
I couldn't understand why on one system it took a few minutes to get the SSH login prompt when connecting to other systems. The other systems all had the UseDNS parameter set to no, which almost always resolves the login prompt delay.
The reason is Ubuntu and perhaps Debian and other distributions /etc/nsswitch.conf file
Edit yours to have the "hosts" line like so (notice that files and dns are the primary resolution choice........
This is really something the SSH Server developers should consider. The cause of this annoyance is because of failed DNS lookups on your IP address, which is especially common for many dedicated/col-located servers and also computers on internal NAT/private networks.
The chances are this is the cause of your SSH Slow/Delayed Login problems.
The easy solution to SSH Login Problems
Add this line to disable r........
User username from 127.0.0.1 not allowed because not listed in AllowUsers
What's going on? The user was created properly, it has been defined as having a shell entry and the entry for /etc/passwd and /etc/shadow is set just fine.
This is a new and very smart/secure feature of SSHD. It is simple and yet effective, but also very annoying if you didn't know about it being implemented and that hand editing of /etc/ssh/sshd_config is required to allow a newly add........