I've tried to run my first objective-c code in Xcode... Compilation process was successfully, however an error returns " invalid host string: 'localhost' ".
After some Googling, I found out and connected the points that it might had something to do with the hosts file I recently deleted.
Now I cannot recreate the /etc/hosts through terminal using:
sudo cat >/etc/hosts <
#
Host Database
#
localhost is used to configure the loopback interface
when the system is booting. Do not change this entry.
#
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
fe80::1%1o0 localhost
EOD
sudo: /private/etc/sudoers is mode 0666, should be 0440
Thanks in advance for any workaround.
You have broken your system by making inappropriate changes.
First, you need to fix the permissions on /etc/sudoers. You might try opening Disk Utility, selecting the system volume, and clicking Repair Disk Permissions. I am not sure that will change the sudoers permissions. If it does not, reboot your system and immediately press and hold the Command and S keys. This boots to single-user mode. When the command prompt appears, enter these commands:
mount -uw /
chmod 0666 /etc/sudoers
reboot
When the system boots, your sudo command might be working again, if you have not otherwise broken it. At this point, you may be able to recreate /etc/hosts. In addition to restoring its contents, you may need to set its ownership and permissions:
sudo chown root:wheel /etc/hosts
sudo chmod u=rw,go=r /etc/hosts
You could also restore /etc/hosts while in single-user mode, rather than booting normally and using the sudo command. Before the reboot command, use cat (or cp to copy from a file you prepared previously) to recreate /etc/hosts, then execute the chown and chmod commands (without sudo), then reboot.
I cannot guarantee these commands will suffice or that there are no errors; diagnosing problems such as this remotely is troublesome.
Stop tinkering with your system without making backups that you know work or taking other steps to be able to revert your changes.
Related
I'm running a bash command on mac that moves a file to private/etc/app_name/.
sudo cp my_file.cpp private/etc/app_name/
Every time the I want to run the bash file, the OS asks for my system password.
> ./run_copy.sh
Password: *******
Is there a way to by-pass this or configure in such way that I only have to enter the password once.
Apparently, on my Macbook, I see /etc directory having symlinks with the /private/etc directory which is owned by the wheel group & root is part of that group. So, you would need to use sudo to copy to that directory.
With that said on a Linux machine, you can work around this by adding your group to a new file in the /etc/sudoers.d/<group-name> path.
<grp-name> ALL=(ALL) NOPASSWD:ALL
I've just tried this on my mac, I could copy files onto /private/etc directory without entering the sudo password prompt.
Unfortunately, this comes up with some risks as users of your group get privileged access without entering any password prompt. You might accidentally delete important system files etc.,
A more niche approach could be to allow selectively like <group> ALL = (ALL) NOPASSWD: /usr/local/bin/copy-script. This way, they can't run all scripts/commands with sudo privileges.
I have not had a similar issue in Windows (10) and nothing I've searched on docs seems to indicate why, if this does not work, that that is the case
I open up terminal and edit /etc/hosts (which I've done many times on a PC and a few years back on an OSX too)
Just for grins if that doesn't work I type in sudo killall -HUP mDNSResponder
Then for more grins I reboot
This has absolutely no effect. Can anyone point me to why? Thanks.
UPDATE: The embarrassing fact of the matter is that the lines I entered in /etc/hosts were in reverse, i.e. domain first, as:
mydomain.com 192.168.33.10 #wrong
192.168.33.10 mydomain.com #what it should have been
The accepted answer, however, is well-written and appreciated.
I've seen two common problems with using /etc/hosts on macOS (/OS X):
Incorrect formatting: each entry in the /etc/hosts file must be an IP address followed by a space or tab, followed by the name, then a linefeed at the end of the line. Try printing the hosts file with cat -vet /etc/hosts to make normally invisible characters visible. Each line should look like one of these:
127.0.0.1^Iwww.example.com$
127.0.0.1 www.example.com$
(The "^I" is a tab, and the "$" is the linefeed at the end of the line.) It's also ok if the entry has multiple names listed (also separated by spaces or tabs).
If you see a "^M" (carriage return) just before the "$", you have DOS/Windows formatted text and you need to remove the carriage return(s).
Incorrect testing: Don't use the command-line tools dig, host, and nslookup, since they all test DNS directly and therefore bypass the /etc/hosts file. Browsers sometimes cache things, which can give misleading results. The "right" way to test the system's name resolution system is with the dscacheutil command:
dscacheutil -q host -a name www.example.com
...but since that's annoyingly verbose, I tend to just use ping, and see what address it says it's going to test.
I came across this thread to try and solve the same issue on macOS Catalina and was not successful. This is because macOS Catalina has another thing going; it will only make changes in the hosts file effective if you change them as the root user (this is not done with the sudo command) !!
By default there is not a root user on your system so here's a link with a step by step guide to do so:
https://support.apple.com/en-us/HT204012
then I was able to:
su
nano /etc/hosts
for more information:
https://discussions.apple.com/thread/250805304
Below steps worked for me
flushing DNS sudo killall -HUP mDNSResponder (or kill DNS in activity monitor and let it reload)
2.Changing read-write permissions of /etc/host file should be -rw-r--r-- .Use commands $ sudo chmod g+r /etc/hosts and $ sudo chmod o+r /etc/hosts
Adding entry u want to add in host file with ipxxx.xx.xx.com
moved these 2 lines in the end
255.255.255.255 broadcasthost
::1 localhost Administrators-MacBook-Pro.local
Step 1 again
I am getting a error while accessing the firefox using X11Forwarding.
[root#station2 ~]# firefox
KiTTY X11 proxy: wrong authorisation protocol attemptedKiTTY X11 proxy: wrong authorisation protocol attemptedError: cannot open display: localhost:10.0
setup the following values: /etc/ssh/sshd_config
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes
** Installed the package**
#yum install xorg-x11-xauth
#yum -y install xauth
[root#station2 .ssh]# echo $DISPLAY
localhost:10.0
#mkxauth -c
adding key for station2.example.com to /root/.Xauthority ... done
export XAUTHORITY=$HOME/.Xauthority
This fix worked for me
There is a hard, if not even impossible, to find (by search engine) scenario that may may cause that error message.
Preliminary note: The topic of this answer is not to discuss if it is a safety
risc or recommondable at all to use a graphical desktop as root on an remote, display-less, webserver.
Scenario:
A remote internet connected Linux server S has assigned the domain
name example.com to it's public IP4-address 192.0.2.1.
The /etc/hostname file on S contains the single line example.
The /etc/hosts
file on S contains the line 127.0.0.1 localhost example.com example.
The (remote) ssh access to S is by (sshd-) configuration (on S) forbidden
for root by the line DenyUsers root in /etc/ssh/sshd_config, but
allowed for a dummy user user1. From a client computer C a ssh
connection, using the ssh parameter -X or -Y, is established to S
as user user1.
Then, in a remote terminal on S owned by user1,
if any X11 related command is tried to be executed as root, may it be by
su, then trying to start the X11 desktop environment
or, as in the concrete case executing a script containing
#!/bin/bash
su --preserve-environment -c "xfce4-session &" root
the error message
X11 connection rejected because of wrong authentication.
is output and the start of any X11 related program fails.
The DISPLAY variable of root's environment contains
example.com:10.0
then.
One solution to the problem is, in this special case, to modify the line
127.0.0.1 localhost example.com example
in /etc/hosts to
127.0.0.1 localhost
Solution: run the application with the same user you are SSHing.
I have also encounter such errors while using X11.
The source of my problem was that i used SSH with my own username (which was not root).
Then, once logged in i tired running stuff with X11 while doing "su" or doing "sudo",
the problem with that is that the SSH session is configured with your own username - e.g: Raj, but then you switch to user root which is not part of the X11 session.
So what you should do is simply try to run the application (firefox in your case) with the same user you started the X11 session.
Hope this helps.
Talel.
I ran into this running gvim over ssh -t -Y and the solution that worked for me was:
xauth add $(xauth -f ~<logon_user>/.Xauthority list | tail -1) ; export NO_AT_BRIDGE=1 # gvim X11 fix for remote GUI failure after su
I do not know where I stumbled on this answer so I cannot give credit to the author.
I'd like users in staff group who do not have admin/root permissions to run the following script without being prompted for a password. This is in OSX.
Note that /usr/sbin/serveradmin requires root/sudo privileges.
I've tried adding the following to my /etc/sudoers, but it does not work. Script has permissions of 755.
%staff ALL=NOPASSWD: /usr/sbin/serveradmin stop smb,/usr/sbin/serveradmin start smb
%staff ALL=NOPASSWD: /bin/sh /opt/scripts/restart-smb
Here's the shell script:
#!/bin/bash
#
# This script simply restarts SMB (Samba)
#
echo "Stopping SMB..."
/usr/sbin/serveradmin stop smb
echo "Pausing for 30 seconds..."
/bin/sleep 30
echo "Starting SMB..."
/usr/sbin/serveradmin start smb
echo "Script complete!"
Your ideas, suggestions most appreciated!
Dan
WARNING while playing with the /etc/sudoers file managing users privilege and permissions, I CRASHED Ubuntu.
Normal login was not possible anymore. I got a parsing error coming from a simple space missing between # and % character in a line I wrongly commented #%sudo ALL=NOPASSWD: /pathtoscripts/script.sh .
I had to recover it with the install/liveCD mounting again the hardrive filesystem, put back the original file in place and dismount the volume for recording changes.
For the above reason I would NOT RECOMMEND THIS METHOD first because it modifies /etc/sudoers privileges critical file. Choose first alternatives available unless:
you have a good back up of your data outside of your PC
you are not afraid to take the risk to repair/reinstall your system
you know the RIGHT SYNTAX of the /etc/sudoers file, trials and parsing errors could cost you a lot of time and/or efforts/crashes...
Reading the other posts, I managed to get it work on my system, managing permissions through a group:
I created the group mygroup
sudo groupadd mygroup
I added the user myuser which will execute the script
sudo usermod -a -G mygroup myuser
I added at the END of /etc/sudoers the entry, otherwise the privilege are overwritten by the previous lines (be careful with syntax)
%mygroup ALL=NOPASSWD: /mypath/to/myscripts/myscript.sh
The above script myscript.sh must have execute permission
sudo ugo+x /mypath/to/myscripts/myscript.sh
This script will then be able to be launched by the user myuser directly as below wihtout prompting for password anymore
sudo /mypath/to/myscripts/myscript.sh
Alternatively, the script can be launched within another one in a same way
I found another way without creating a group, adding to /etc/sudoers file (at the END of file) the line:
%sudo ALL=NOPASSWD: /mypath/to/myscripts/myscript.sh
In case the script must only be launched by a few existing users myuser1, myuser2, it is always possible to only add to /etc/sudoers (at the END of file) the lines :
myuser1 ALL=(ALL) NOPASSWD: /mypath/to/myscripts/myscript.sh
myuser2 ALL=(ALL) NOPASSWD: /mypath/to/myscripts/myscript.sh
I was able to make this work by adding the following to my /etc/sudoers file:
%staff ALL=/opt/scripts/restart-smb
Then of course making the script executable (I had forgotten that).
Still requires a password (which is okay), but working.
I followed instructions here carefully however I haven't get this working right. Here is what I did:
Run WinSCP enter Hostname (Elastic IP of my Instance)
enter username "ec2-user"
enter public key file
chose SCP for the protocol
Under SCP/Shell settings I chose "sudo su -"
Hit Login
WinSCP asks me for passphrase key, Hit OK
Shows up this error
Error skipping startup message. Your
shell is probably incompatible with
the application (BASH is recommended).
NOTE: This works on Putty
With credit to this post and this AWS forum thread, it seems the trick is to
comment out Defaults requiretty in sudoers. My procedure now:
Log in to your EC2 instance using Putty.
Run sudo visudo, a special command to edit /etc/sudoers.
Press the Insert key to start Insert mode.
Find the line Defaults requiretty. Insert a hash symbol (#) before that line to comment it out:
#Defaults requiretty
Press the Esc key to exit Insert mode.
Type :wq to write the file and quit visudo.
In WinSCP:
Under Advanced > Environment > SCP/Shell, change the Shell to sudo su -.
Under SSH > Authentication, choose your Private key file (.ppk file).
WinSCP does not support commands that require terminal emulation or user input.
See: http://winscp.net/eng/docs/remote_command#limitations
Since sudo su - expects a password, it wouldn't work.
There is a way around it: make root logon without being prompted for a password. You can do this by editing your sudoers file usually located at /etc/sudoers and adding:
root ALL=NOPASSWD: ALL
Needless to say, this is Not a Very Good Thing To Do - for reasons which should be obvious :)
I was having the same problem and solved it using the steps in this tutorial. I would have posted it here, but I don't have enough rep for images/screens.
http://cvlive.blogspot.de/2014/03/how-to-login-in-as-ssh-root-user-from.html
The following tutorial worked for me and provides helpful screenshots. Logging in as a regular user with sudo permissions just required tweaking a few WinSCP options.
http://cvlive.blogspot.de/2014/03/how-to-login-in-as-ssh-root-user-from.html
Set Session/File protocol to: SCP, enter host/instance ip, port - usually 22, and regular username. Enter password credentials if the login requires it.
Add Advanced/SSH/Authentication/Private key file.
Unchecking Advanced/SSH/Authentication/attempt "keyboard interactive" authentication should allow Advanced/Environment/SCP Shell/Shell/Shell: sudo su - to provide sudo permissions for accessing webserver directories as a non-owner user.
Update 08/03/2017
WinSCP logging can be helpful to troubleshoot issues:
https://winscp.net/eng/docs/logging
[WinSCP] Logging can be enabled from Logging page of Preferences dialog.
Logging can also be enabled from command-line using /log and /xmllog
parameters respectively, what is particularly useful with scripting.
In .NET assembly, session logging is enabled using
Session.SessionLogPath1).
Depending on WinSCP connection errors, some server installations may need a directive added to the (Ubunto, CentOS, other-Linux-Server) /etc/sudoers file to not require TTY for a specified user. Creating a file in /etc/sudoers.d/ (using a tool such as Amazon Command Line Interface or PuTTY) may be a better option than editing /etc/sudoers. Some /etc/sudoers versions recommend it:
This file MUST be edited with the 'visudo' command as root.
Please consider adding local content in /etc/sudoers.d/ instead of
directly modifying this file.
See the man page for details on how to write a sudoers file.
When editing a sudoers file (as root) through the command-line, the 'visudo' command should be used to open the file as it will parse the file for syntax errors. /etc/sudoers.d/ files are typically owned by root and chmoded with minimal permissions. The default /etc/sudoers file may be referenced as it should automatically have recommended chmod permissions on installation. e.g.: 0440 r--r----- .
https://superuser.com/a/869145 :
visudo -f /etc/sudoers.d/somefilename
Defaults:username !requiretty
Helpful Links:
Stackoverflow: cloud-init how to add default user to sudoers.d
https://www.digitalocean.com/community/tutorials/how-to-edit-the-sudoers-file-on-ubuntu-and-centos
WinSCP Forum:
https://winscp.net/forum/viewtopic.php?t=3046
https://winscp.net/forum/viewtopic.php?t=2109
WinSCP Doc: https://winscp.net/eng/docs/faq_su
With SCP protocol, you can specify following command as custom shell
on the SCP/Shell page of Advanced Site Settings dialog:
sudo -s
[...]
Note that as WinSCP cannot implement terminal emulation, you need to
have sudoers option requiretty turned off.
Instructions in Ubuntu Apache /etc/sudoers recommend adding directives to /etc/sudoers.d rather than editing /etc/sudoers directly. Depending on the installation, adding directive to /etc/sudoers.d/cloud-init may work as well.
It may be helpful to create an SSH test user with sudo permissions by following the steps provided in instance documentation to ensure that the user has recommended instance settings and any updates to server sudoer files can be effected and removed without affecting other users.
I enabled SSH root login on Debian Linux Server:
To enable SSH login for a root user on Debian Linux system you need to first configure SSH server. Open /etc/ssh/sshd_config and change the following line:
FROM:
PermitRootLogin without-password
TO:
PermitRootLogin yes
Once you made the above change restart your SSH server:
/etc/init.d/ssh restart
Source
Then i used SCP File protocol with root user name in winscp.
Under SCP/Shell settings, instead of "sudo su -", choose /bin/bash.
It should work.