New answers tagged sshd
Established TCP connection is probably authentication attempt, which doesn't mean that the authentication was successful. It is probably just a noise, but of course, you should check the PIDs as proposed in the comment, if the sshd process is in [preauth] mode or [postauth] -- should be visible in normal ps.
Bratchley was on the right track. Indeed 'semanage' can change (modify) already defined ports. Here's a way that worked for myself: [root@host ~]# semanage port -l |grep ssh ssh_port_t tcp 22 [root@host ~]# semanage port -m -t ssh_port_t -p tcp 23 [root@host ~]# semanage port -l |grep ssh ssh_port_t tcp ...
I am no friend of SELinux, so this is just a wild guess: Modify /etc/services so that 23/tcp has the same entry as 22/tcp?
I edited vim /etc/hosts added the following lines 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 and my problem is fixed :)
Answer is yes. You are pointing to the correct target, but you miss few pieces: Using ChallengeResponseAuthentication, you can define more authentication methods, but to make sure they are requested from user, you need to specify the list of them in AuthenticationMethods, for example like this in sshd_config (doing pam two times is just example to try how ...
Theoretically it is possible, but using something like a Radius server for one of the two authentications. Otherwise it should draw a second database for password2. But if the intention is to avoid the automated brute force tools I believe that the best approach is that of security through obscurity, or quite simply, to change the standard port for ssh ...
You can add something like this to your /etc/ssh/sshd_config: AllowUsers mobileuser1 mobileuser2 *@10.0.0.0/8 The above assumes that the permitted remote users are named mobileuser1 and mobileuser2, and that your trusted network is 10.0.0.0 with subnet mask 255.0.0.0. This allows the two mobile users to log in from anywhere and everyone to log in from ...
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.
Am I correct that in Linux this means that sshd directly checks the /etc/passwd and /etc/shadow files if UsePAM in sshd configuration is disabled? Yes. But currently most of distributions handle login using pam, because the sessions in todays systems are getting more and more complicated. OpenSSH can communicate with shadow using <shadow.h> header ...
Top 50 recent answers are included