Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

problem with remote login

648 views
Skip to first unread message

Heinz Müller

unread,
Feb 12, 2013, 4:08:32 PM2/12/13
to
Hello @all,

I'm facing a problem to login to a server ( Solaris 10 ) .

Things that are fine:

a.
su - root ( even with password )

b.
ssh from another server with public key identification

Things that went wrong:

a.
ssh, telnet or ftp from another server

Example with telnet ( same with ssh and FTP ):

Feb 12 19:54:50 hds620 inetd[373]: [ID 317013 daemon.notice]
telnet[3633] from 10.253.156.65 33439
Feb 12 19:54:55 hds620 login: [ID 658745 auth.crit] REPEATED LOGIN
FAILURES ON /dev/pts/3 FROM XXXXXXXXXX, root

b
same as a. but on localserver

c.
On system console ( /dev/console ) no login is possible after I enter my
password
( Not tried in single user mode! )

Feb 12 19:54:15 hds620 login: [ID 561941 auth.crit] REPEATED LOGIN
FAILURES ON /dev/console, root
Feb 12 19:54:20 hds620 svc.startd[11]: [ID 694882 daemon.notice]
instance svc:/system/console-login:default exited with status 1


In /var/svc/log I checked some logfiles:

1. svc.startd.log

Feb 12 17:49:31/6: instance svc:/system/console-login:default exited
with status 1
Feb 12 17:49:43/6: instance svc:/system/console-login:default exited
with status 1
Feb 12 18:56:31/6: instance svc:/system/console-login:default exited
with status 1
Feb 12 19:01:42/6: instance svc:/system/console-login:default exited
with status 1


2. system-console-login:default.log

[ Feb 12 17:49:31 Stopping because all processes in service exited. ]
[ Feb 12 17:49:32 Executing start method ("/lib/svc/method/console-login") ]
[ Feb 12 17:49:43 Stopping because all processes in service exited. ]
[ Feb 12 17:49:43 Executing start method ("/lib/svc/method/console-login") ]
[ Feb 12 18:56:31 Stopping because all processes in service exited. ]
[ Feb 12 18:56:31 Executing start method ("/lib/svc/method/console-login") ]
[ Feb 12 19:01:42 Stopping because all processes in service exited. ]
[ Feb 12 19:01:42 Executing start method ("/lib/svc/method/console-login") ]

Previous history:

To realize some specifications of our Audit Department I had to change
some network parameters with ndd and some logging settings.
Don't know if that causes the problems but in the end I've turned
everything back but problem still exists. Server was also rebootet
but with no improvements. The network parameters are:

316 ndd -set /dev/ip ip_respond_to_echo_multicast 0
317 ndd -set /dev/ip ip6_respond_to_echo_multicast 0
318 ndd -set /dev/arp arp_cleanup_interval 60000
319 ndd -set /dev/ip ip_ire_arp_interval 60000
320 ndd -set /dev/ip ip_strict_dst_multihoming 1
321 ndd -set /dev/ip ip6_strict_dst_multihoming 1


Turned back to default:

453 ndd -set /dev/ip ip_respond_to_echo_multicast 1
454 ndd -set /dev/ip ip6_respond_to_echo_multicast 1
455 ndd -set /dev/arp arp_cleanup_interval 300000
456 ndd -set /dev/ip ip_ire_arp_interval 1200000
457 ndd -set /dev/ip ip_strict_dst_multihoming 0
458 ndd -set /dev/ip ip6_strict_dst_multihoming 0


Any help would be appreciated.

Regards,
Heinz

Martin Paul

unread,
Feb 13, 2013, 2:49:31 AM2/13/13
to
Am 12.02.2013 22:08, schrieb Heinz Mᅵller:
> Example with telnet ( same with ssh and FTP ):
>
> Feb 12 19:54:50 hds620 inetd[373]: [ID 317013 daemon.notice]
> telnet[3633] from 10.253.156.65 33439
> Feb 12 19:54:55 hds620 login: [ID 658745 auth.crit] REPEATED LOGIN
> FAILURES ON /dev/pts/3 FROM XXXXXXXXXX, root

Look at /etc/default/login - if CONSOLE is set, root can only login on
that device.

hth,
mp.

Heinz Müller

unread,
Feb 13, 2013, 3:05:02 AM2/13/13
to
I checked this and it's not set. I can't even log in on Console
as I described in c.

hds620 console login: root
Password:
Feb 12 19:54:15 hds620 login: REPEATED LOGIN FAILURES ON /dev/console, root

[...]
# If CONSOLE is set, root can only login on that device.
# Comment this line out to allow remote login by root.
#
#CONSOLE=/dev/console
[...]

I think there is a fundamental problem with all logins,
regardless of log in on Console, Telnet, SSH or FTP.

Fortunately there is a public key identification from a
second server without password. That works fine.

Regards,
Heinz


James Carlson

unread,
Feb 13, 2013, 7:21:36 AM2/13/13
to
On 02/13/13 03:05, Heinz Mᅵller wrote:
> I checked this and it's not set. I can't even log in on Console
> as I described in c.
>
> hds620 console login: root
> Password:
> Feb 12 19:54:15 hds620 login: REPEATED LOGIN FAILURES ON /dev/console, root

On modern Solaris systems, root is set up as a role, not a user, which
means you can't log in directly as root. It's an intentional security
feature.

To check whether root is a role:

% grep root /etc/user_attr

To change it to a normal account:

% pfexec usermod -K type=normal root

What this feature provides is accountability: the security logs will
always record a real user logging in and then assuming greater
privileges. If you allow log-ins as "Mr. Root", then that's the only
thing you'll see in the security logs, which is rather useless in terms
of attribution.

I certainly don't recommend breaking intentional security features of
the OS, but if you want to, you can do it.

As for your networking tweaks, they have nothing to do with it. By the
way, setting ip{,6}_strict_dst_multihoming will break most routed
multihoming features and certainly does nothing whatsoever to improve
security. So, if your "auditing" people recommend it, I'd recommend
finding new people. They're at best mistaken. :-/

--
James Carlson 42.703N 71.076W <carl...@workingcode.com>

Heinz Müller

unread,
Feb 13, 2013, 3:44:06 PM2/13/13
to
Am 12.02.2013 22:08, schrieb Heinz Mᅵller:
The problem was caused due to an entry in /etc/default/login
for the RETRIES parameter. It was changed to RETRIES=0
and this was the time where no user was able to log in!

We changed it to RETRIES=3 and everything went fine :-)

Regards,
Heinz

0 new messages