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.


7

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


7

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

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


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

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

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

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


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


4

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


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


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

Ok, I've already known, how to do that. Just write in Match User something like this: Match User OnlyPassword AuthenticationMethods keyboard-interactive:pam and in default values only: AuthenticationMethods publickey,keyboard-interactive:pam


3

Ubuntu does not have ssh-keygen in init scripts. Ubuntu generates keys using dpkg-reconfigure triggers. It is not an automatic action. dpkg-reconfigure openssh-server The quoted line refers to Fedora/RHEL/CentOS, which is using sshd-keygen service. It creates keys before running the sshd service itself and is triggered by AUTOCREATE_SERVER_KEYS variable ...


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

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

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

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

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

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

I am reading this tutorial, and trying to create a new user with root privileges and then block root access via ssh in a CentOS 7 server. The problem is that the new user is blocked from doing root actions like nano /etc/sudoers. Also, I seem unable to remove the block of root login. So my pre-existing open root session is the only access I have to root ...


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

A better way to see the last part of the log is: journalctl -u sshd -n 100 Using tail on the output of journalctl can be very slow. It took 5 minutes on a machine where I tried it, while the above command returns instantly.


2

Root cause of 98% similar problems is UseDNS parameter in /etc/ssh/sshd_config. Switch its value to no and try again


2

sshd is the daemon. You'd want to use the -q flag with the client (ssh). When connecting to your home machines, include the -q flag in the ssh command (i.e. ssh -q user@host). Alternatively, if that doesn't work, you could try redirecting stderr to /dev/null by connecting to your home machines like ssh user@host 2> /dev/null.


2

How were these brute force attackers allowed to even input a username? You write username on command-line (or the current is used by default). You always need to input username. You didn't block connection by this (there is firewalld or iptables for that), but only password authentication. For people more eager in details, there is RFC4252, section 5, ...


2

The public key authentication is per user. You need an username, and your key. In fact, you can actually log in to two different users on the same server using the same key. If you're trying to ssh invaliduser@your.server.hostname (with or without a valid key), you'll also get "Permission denied", plus the error shows up in the server's log. So, this ...


2

There are two things that you want to achieve: Disallow the authentication using ~/.ssh/authorized_keys As proposed set AuthorizedKeysFile to some different place. If there is the discussed requirement, it will not be evaluated (otherwise there is nothing more to solve). Set AuthorizedKeysCommand The command will return you the authorized keys from your ...



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