I have a new box that was set up for me and I want to allow telnet to the box as root. I know that it's not secure but due to the nature of what I test I need an easy and reliable way back in if I've messed up the other connection methods(SSH). This is in a protected lab environment. Eventually I'll get sudo setup but I'm not ready for that now.
I can telnet as a regular user and then su to root just fine.
I cannot "telnet remote_server" as root user.
I cannot "telnet localhost" as root user.
I did not have an /etc/securetty file. I tried creating one with "console" in it to see if I could then get in via localhost but it didn't help.
I tried "/usr/lbin/modprpw -k root" and got the message "System is not trusted".
hosts.allow and hosts.deny are both commented out.
Most of the search results I get are about how to disable telnet for root but I have the opposite problem. Where else can I look or what can I do?
Actually, I don't know for sure. I don't think so but even if it did, if you were thinking about using that as a method of access I wouldn't be able to do it. The machine sits in the lab but I don't. Thanks for your idea though.
You should have a lanconsole option... it may need to be configured though (preferably on another lan like an administration lan... ask your network team for a VLAN...). Remove the hosts.allow hosts.deny files (or mv them elsewhere ) while configuring they are maybe the culprits...
I need to be able to connect via telnet from a remote workstation and login as root. Period. Moving /etc/hosts.allow and /etc/hosts.deny unfortunately didn't help.
When inetd accepts a connection from a remote system, it checks the
address of the host requesting the service against the list of hosts
to be allowed or denied access to the specific service (see
inetd(1M)).
which lead me to /etc/inetd.conf and this line which I had looked at previously. I had assumed it is correct but am including for another set of eyes to look at.
I am getting closer. The problem is that the root password contains the "@" character. When I use a password without "@" I can get in. I think it has something to do with eol being set to ^@.
For the heck of it I tried adding this to /etc/profile
EOL="^-"
export EOL
stty eol $EOL
but it didn't help. I suppose because /etc/profile is read after the login.
In the end I just ended up changing the password to something simpler because a screw up of the tty settings for the root account could mean a reinstall and it's not worth it.
Ah I should have asked that ( but who would think of something to do with the password? to start with...)
@ is the "erase line " or set line to blank in HP world.
I did not think of this because it is stated by all HP admins to never enter special char in root password (for the day you are to solve issues and have for the first time to connect using the console (HP terminal...))
You can try: type your name @ your name again at the prompt login!
This is important when you got the bad login set for it is the ONLY way to cancel or erase (empty buffer...)
..
Until you are logged in, then in profile or .profile you have a stty getting set...
This goes also when you connect via network on remote systems... remember to backslash before the @
I too saw warnings about using the special character "@" but I thought the warning only applied if "@" was used for kill. My stty -a output isn't, so I moved on in my troubleshooting process.
About your suggestion. Like this?
login: root@root
Password:
Login incorrect
That does not work for me. Or do I misunderstand your suggestion?
Telnet TERMINAL-SPEED option ON
HP-UX ran B.11.11 U 9000/800 (tb)
login: vbe@vbe
Password:
Please wait...checking for disk quotas
(c)Copyright 1983-2000 Hewlett-Packard Co., All Rights Reserved.
(c)Copyright 1979, 1980, 1983, 1985-1993 The Regents of the Univ. of California
(c)Copyright 1980, 1984, 1986 Novell, Inc.
(c)Copyright 1986-1992 Sun Microsystems, Inc.
(c)Copyright 1985, 1986, 1988 Massachusetts Institute of Technology
(c)Copyright 1989-1993 The Open Software Foundation, Inc.
(c)Copyright 1986 Digital Equipment Corp.
...
In other words your stty was already set... try a fresh connection with telnet from another box...