Hot answers tagged

7

The problem is the fact that files permissions are too open. Try setting the mode of authorized_keys to 600 and the .ssh directory to 700.


6

Ok, we need some history here, back in the days that the primary way to access a UNIX box was a Terminal and a serial line there were four programs involved in logging in. They were init, getty, login, and a shell. init started getty and kept it running. getty opened a serial port (and maybe did modem specific stuff), and then displayed the login prompt and ...


6

There it is. Group has write access to ~rudra: $ls -alF .ssh/ total 12K drwx------. 2 rudra rudra 4.0K Oct 12 14:16 ./ drwxrwxr-x. 36 rudra rudra 4.0K Oct 12 14:30 ../ -rw-------. 1 rudra rudra 394 Oct 10 12:01 authorized_keys Thus, sshd refuses to trust the files in ~rudra, and does not use ~rudra/.ssh/authorized_keys, even though its permissions are ...


5

The OpenSSH sshd command has an extended test switch which can be used to "Check the validity of the configuration file, output the effective configuration to stdout and then exit." (source sshd man page). So the answer is (as root, or prefixing it with sudo): sshd -T (the settings are not in alphabetical order, one can use sshd -T | sort to quickly look ...


4

Drop bear might work. It does use the SSH protocol, but it doesn't share a code base with OpenSSH, so it probably won't crash in the same circumstances. I'm pretty sure you can configure both OpenSSH and Drop Bear to listen on ports other than TCP 22.


4

You shouldn't believe everything you read on the Internet. :) There is no security problem with enabling TCPKeepAlive. There never was any such problem. The meaning of the warning in the sshd_config(5) manual is that you shouldn't rely on TCPKeepAlive alone, since an attacker can spoof it to fool the server into thinking a connection is still alive when it ...


4

As explained in man ssh: -t         Force pseudo-tty allocation. This can be used to execute arbi‐           trary screen-based programs on a remote machine, which can be           very ...


4

For reasons of paranoia, the .ssh directory and authorized_keys must not be group-writable. I guess the thinking is, the user must be the only one with explicit control over his/her authorization. I believe a work-around for this lies with ACL. The other work around is StrictModes=no setting in sshd's configuration file. But it would be too dangerous to do ...


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


4

rsyslog makes this relatively easy, since you can match aspects of whatever message arrives. Include a snippet like this (in my case I put a *.conf file into /etc/rsyslog.d/): if $programname == 'sshd' then { if $msg contains 'Invalid user' then { # adjust to your needs *.* -/var/log/sshd-fails.log } stop # discard all other messages ...


3

Assuming all your Match blocks are at the end of the sshd_config file. If your blocks are separated by empty lines, e.g.: Match User FOO1 PasswordAuthentication no Match User FOO2 PasswordAuthentication yes Match User FOO ChrootDirectory /srv/www/FOO AllowTCPForwarding no X11Forwarding no ForceCommand internal-sftp then just ...


3

What is possible depends on what the firewall allows. If the firewall allows arbitrary traffic on port 443 Some firewalls take the simple way out and allow anything on port 443. If that's the case, the easiest way to reach your home server is to make it listen to SSH connections on port 443. If your machine is directly connected to the Internet, simply add ...


3

Rather than using Match, if you wish to allow logging in from a single host, the following works for me (in sshd_config): AllowUsers *@192.168.0.4 It only allows users logging in from 192.168.0.4, using any login on the target. You can replace * with a specific login if you wish, and specify multiple patterns separated by spaces; so for example: ...


3

DEL doesn't indicate that that process deleted /dev/zero, but that that process is using /dev/zero and the instance of /dev/zero that was being used has since been deleted. For example, if I have a command (say some-command) that uses /some/file and I do: $ some-command & $ rm /some/file $ touch /some/file Then lsof for /some/file would look like: ...


3

Appending this line to sshd_config helped in my case (PyCharm and Ubuntu 14.04 via Docker): KexAlgorithms=diffie-hellman-group1-sha1


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


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


3

Yes. It is possible using pam_ssh_agent_auth package if your distribution provides. It can allow you to execute sudo based on pam module, which checks possession of ssh key in ssh-agent. Short story long Setup Install pam_ssh_agent_auth package from package manager Modify /etc/sudoers, preferably using visudo and add line Defaults env_keep += ...


3

Your first user submits the rsa key and it's rejected. debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/rudra/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password Your second user succeeds ...


3

Syslog is definitely the way to go on this one. How you write the rules depends on whether you're using rsyslog or syslog-ng but for syslog-ng add the following to the /etc/syslog-ng/syslog-ng.conf file. destination ssh_auth_fail { file("/path/to/file.log"); }; filter f_ssh_auth_fail { message("regex to match desired lines"); }; log { source(src); ...


2

IP Spoofing, is a technique where the attacker uses a forged IP source address with the purpose of concealing the identity of the sender or impersonating another computing system. However, this kind of attack will be nearly "impossible" from the internet because RFC1918 defines the following blocks that will be used only inside LAN environments: The ...


2

General troubleshooting advice for OpenSSH First of all I refer you to this short troubleshooting guide for sshd which I am using as a recipe time and time again. The plot thickens Only difference in this case, I used lxc-console to attach to the guest, logged in and stopped the running sshd and then started my instance on the default port 22. And then I ...


2

Turns out my router was set up to forward some high ports to the internal SSH port - so basically the problem was caused by some ancient configuration leftovers. How stupid.


2

In order to attack a server the attacker must first know its IP address. With IPv6 you will have so many addresses to choose from that it is not feasible to find the correct address by scanning the IP range. This means you can simply assign two different IPv6 addresses to the interface. You let the domain name of your site keep pointing to the same IP ...


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


2

A quick look at the source indicates that auth-passwd.c includes <pwd.h> & auth-shadow.c includes <shadow.h>. Without doing to deep of a dive, it seems that sshd does use the system calls to check the password. There was also code that allowed sshd to required and do a password change for expired passwords.


2

Check if $SSH_CLIENT is empty as well as $DISPLAY. For example: [[ -z $DISPLAY && -z SSH_CLIENT && $XDG_VTNR -eq 1 ]] && exec startx Alternatively, use $SSH_CONNECTION or $SSH_TTY


2

Get a better provider than GoDaddy. BlueHost or Hostgator spring to mind, although I've never used either. Your ps aux output shows that your ssh session is currently using 1.8kib of memory 1.8 SSH 1.6 -bash 124 cpaneld 1.02 ps aux All sizes are in kib, so total is about 128mb. It's not unreasonable to think that a fully configured and running OS ...



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