Tag Info

New answers tagged

0

On my (standard) Ubuntu environment I got the xterm over ssh failure message "... suid-root program..." (see above), even with all the proper forwarding settings. This behavior went away a soon sshd is configured to use only IPv4, because of an X11 forwarding bug in SSH if IPv6 on the system is disabled. vi /etc/ssh/sshd_config AddressFamily inet service ...


0

Your netmaks are incorrect. If you want to include private networks, you should use : 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 This is probably why you do not match, rather than a ssh bug.


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 ...


0

Run the SSH client with the -vvv option which will give you an output with max verbosity. In this way you'll be able to see if the delay is due to the client or the server, and where exactly it takes place.


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 ...


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 ...


0

Services launched by systemd at boot are ordered by dependencies. To tell systemd to launch the sshd.service unit later, you have to tell it which unit it should wait for before starting the service. Once you have found the unit responsible for the network setup (most probably network.service on CentOS 7), you can create a drop-in configuration file (the ...


1

Environment variable approach Here's one possibility....if you're happy to have PermitUserEnvironment set to true in your sshd_config then you could use a combination of environment variable against the key and some checking in /etc/profile to alert/reject anyone still using password approach. In your $HOME/.ssh/authorized_keys file you'd have something ...


3

On Ubuntu: $ sudo cat /var/log/auth.log|grep ssh|grep Accept On CentOS/RHEL: $ sudo cat /var/log/secure|grep ssh|grep Accept This will show all connections, and how they authenticated [since the log file's last rotation]. If you only want to see password connections, just pipe through another grep: ... grep ssh|grep Accept|grep password And for ...



Top 50 recent answers are included