Tag Info

Hot answers tagged

4

My work-colleague pointed me to the same direction as /u/meuh did, using a slightly different approach. Match Address "172.24.*.33" PermitRootLogin yes Match Address "192.168.1.18,192.168.1.20" PermitRootLogin yes


3

If a server is completely consumed cpu-wise, it won't have the cycles to service your ssh request. If it's completely consumed memory-wise, it won't be able to fork a new sshd process for you. I find there's quite often instances when ssh doesn't work, and it's due to resource over-utilization. That said, repeatedly taking the sledgehammer approach of ...


3

Normally sshd does allow either public key authentication, password authentication and the others you have enabled. From your output you can see that GSSAPI is tried first, but that did not succeed. Next the public keys are offered but they were not accepted and finally the password authentication asks you for a password. If you enter a wrong password (or ...


2

This is really just a comment that is too long for comments. The short answer to your question is: Yes. Resource over-utilization can kill each and every functionality that the server has. Every process requires memory. When the memory runs out, sad times. Long answer If you can't recover the machine while it is struggling, finding the root cause will ...


2

Depending on your version of ssh, you might be able to set a match condition around your AllowUsers. man sshd_config lists the allowed commands under Match. If AllowUsers is in there, you might try the following.Make sure it is at the end of the file. Match User root AllowUsers root@ a.b.c.d root@q.r.s.t Eg, not in OpenSSH_6.0p1 Debian, but ok in ...


1

recovery is similar to a lost root password (and might be easiest). connect to the console of your VM, using virtual box. 2.a. if you can log from there, log as user, then sudo root, then edit sshd (and firewall rules) and reboot. 2.b. if you can't log, neither root/nor user, reboot hosts, upon boot, select kernel (using arrows), edit (using e), then ...


1

You have to reorder the iptables rules. You can't connect to your sshd because the rules are checked in line for line. And you already told iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset = reject ALL tcp traffic. Even you later tell him to accept connections to port 5000 it doesn't matter - you already rejected those connections. So when you ...


1

ssh-agent -k then the passphrase was entered again and solved problem


1

I was answering similar question on Superuser.com, but after the responses I am not longer sure if it is right. In short, I believe that it is currently not possible and even openssh-7.0 is out, but these bugs were not fixed so we will have to urge upstream. Also there is alternative answer with positive feedback, but I guess this is the way how you are ...


1

/me wished he could comment sshd needs to (typically, but though you didn't specifiy the exact use case(s) etc.) allocate a pty per login, however, in your case, ssh "echo hi; sleep 100s" does NOT allocate a pty, so no need for the kernel.pty.max setting... unless you want thousands of users loggedin*... to test that, you'll need to add the -t option to ...



Only top voted, non community-wiki answers of a minimum length are eligible