I want to install Pseudo-Distributed HBase environment on my Mac OS Sierra (10.12.4), and it requires ssh installed and can log with ssh localhost without password. But sometimes I came across with error when I use ssh to log in. Above all are question background, and the actual question is where can I find debug logs of sshd so I could know why logging is failed in further?
As I know, Mac OS already have sshd installed and use launchd to manage it, and I know one way to output debug logs by sshd -E /var/log/sshd.log, but when I reviewed /etc/ssh/sshd_config configuration and there are two lines:
#SyslogFacility AUTH
#LogLevel INFO
I guess these two lines are used to config debug mode, then I removed # before them and set LogLevel to DEBUG3 and then restarted sshd:
$ launchctl unload -w /System/Library/LaunchDaemons/ssh.plist
$ launchctl load -w /System/Library/LaunchDaemons/ssh.plist
And then I set log path in /etc/syslog.conf:
auth.*<tab>/var/log/sshd.log
<tab> means tab character here, and reloaded the config:
$ killall -HUP syslogd
But sshd.log file can not be found in /var/log folder when I executed ssh localhost. I also tried config the /etc/asl.log:
> /var/log/sshd.log format=raw
? [= Facility auth] file sshd.log
And the result was the same, can someone help me?
Apple, as usual, decided to re-invent the wheel.
In super-user window
# log config --mode "level:debug" --subsystem com.openssh.sshd
# log stream --level debug 2>&1 | tee /tmp/logs.out
In another window
$ ssh localhost
$ exit
Back in Super-user window
^C (interrupt)
# grep sshd /tmp/logs.out
2019-01-11 08:53:38.991639-0500 0x17faa85 Debug 0x0 37284 sshd: (libsystem_network.dylib) sa_dst_compare_internal <private>#0 < <private>#0
2019-01-11 08:53:38.992451-0500 0xb47b5b Debug 0x0 57066 socketfilterfw: (Security) [com.apple.securityd:unixio] open(/usr/sbin/sshd,0x0,0x1b6) = 12
...
...
In super-user window, restore default sshd logging
# log config --mode "level:default" --subsystem com.openssh.sshd
You can find it in /var/log/system.log. Better if you filter by "sshd":
cat /var/log/system.log | grep sshd
Try this
cp /System/Library/LaunchDaemons/ssh.plist /Library/LaunchDaemons/ssh.plist
Then
vi /Library/LaunchDaemons/ssh.plist
And add your -E as shown below
<array>
<string>/usr/sbin/sshd</string>
<string>-i</string>
<string>-E</string>
<string>/var/log/system.log</string>
</array>
And lastly restart sshd now you will see sshd logs in /var/log/system.log
launchctl unload /System/Library/LaunchDaemons/ssh.plist && launchctl load -w /Library/LaunchDaemons/ssh.plist
I also had an ssh issue that I wanted to debug further and was not able to figure out how to get the sshd debug logs to appear in any of the usual places. I resorted to editing the /System/Library/LaunchDaemons/ssh.plist file to add a -E <log file location> parameter (/tmp/sshd.log, for example). I also edited /etc/ssh/sshd_config to change the LogLevel. With these changes, I was able to view the more verbose logs in the specified log file.
I don't have much experience with MacOS so I'm sure there is a more correct way to configure this, but for lack of a better approach this got the logs I was looking for.
According to Apple's developer website, logging behavior has changed in macOS 10.12 and up:
Important:
Unified logging is available in iOS 10.0 and later, macOS 10.12 and later, tvOS 10.0 and later, and watchOS 3.0 and later, and supersedes ASL (Apple System Logger) and the Syslog APIs. Historically, log messages were written to specific locations on disk, such as /etc/system.log. The unified logging system stores messages in memory and in a data store, rather than writing to text-based log files.
Unfortunately, unless someone comes up with a pretty clever way to extract the log entries from memory or this mysterious "data store", I think we're SOL :/
There is some sshd log in
/var/log/system.log
for example
Apr 26 19:00:11 mac-de-mamie com.apple.xpc.launchd[1] (com.openssh.sshd.7AAF2A76-3475-4D2A-9EEC-B9624143F2C2[535]): Service exited with abnormal code: 1
Not very instructive. I doubt if more can be obtained. LogLevel VERBOSE and LogLevel DEBUG3 in sshd_config do not help.
According to man sshd_config :
"Logging with a DEBUG level violates the privacy of users and is not recommended."
By the way, I relaunched sshd not with launchctl but with System preference Sharing, ticking Remote login.
There, I noticed the option : Allow access for ...
I suspect this settings to be OUTSIDE /etc/ssh/sshd_config
(easy to check but I have no time).
Beware that Mac OS X is not Unix : Apple developpers can do many strange things behind the scene without any care for us command line users.
Related
I've been trying to figure this out for quite some time and I don't seem to be able to find any information on this issue.
diving into the issue:
I am running an application on Ubuntu 14.04 using Monit V5.6
The deployment of the application and Monit is done by using Chef scripts with AWS Opsworks which works excellent.
The problem is that once done, Monit starts the application using the following syntax:
start program = "/bin/sh -c 'ulimit -n 150000; <some more commands here which are not intersting>'" as uid <user> and gid <user_group>
This indeed starts the application using the correct user but the problem is that max open files for the process is showing 4096 instead of the number set in limits.conf
Just to be clear, I have set the following in /etc/security/limits.conf
root hard nofile 150000
root soft nofile 150000
* hard nofile 150000
* soft nofile 150000
Further more, if I stop the application then do a service monit restart and then start the application, the max open files values is received correctly and I am seeing 150000.
If I then redeploy the application without rebooting the instance then this happens again and I have to manually restart monit again.
Also if I run the application using the following syntax in order to mimic Monit:
sudo -H -u <user> /bin/sh -c 'ulimit -n 150000; <more commands here>'
Then everything is working and the process is receiving the correct value of max open files.
I try to script this manual service monit restart with stopping and starting the application via Chef scripts then this also fails and I receive 4096 as the max open files value thus my only option is to manually do this each time I deploy which is not very convenient.
Any help on this or thoughts would be greatly appreciated.
Thanks!
P.S. I also reviewed the following articles:
https://serverfault.com/questions/797650/centos-monit-ulimit-not-working
https://lists.nongnu.org/archive/html/monit-general/2010-04/msg00018.html
but as manually restarting Monit causes this to work then I am looking for a solution without changing init scripts.
After upgrading to MacOS Sierra (10.12), my sudo command seems to be acting differently. See the following test case:
# Run in terminal pane #1: (should prompt for password)
sudo -v
# Run in terminal pane #2: (should NOT prompt for password)
sudo -v
The above works as expected on earlier versions of OS X. However, on Sierra, the second command prompts for the password again. It does not prompt for the password within the same terminal pane. This seems to only happen for the root user; the following works as expected on all OS versions including Sierra:
# Run in terminal pane #1: (prompts for password)
sudo -v -u "$USER"
# Run in terminal pane #2: (does not prompt for password)
sudo -v -u "$USER"
Looking at /ect/sudoers, the timestamp_timeout value is not set to 0. I've briefly looked over the changelog for 1.7 to 1.8 but could not come up with anything significant other than there being a mention of a policy plugin for Sierra when running sudo -V.
Can anybody help me figure out what has changed? I have a script that relies on the sudo timeout value for a keepalive and on Sierra it is prompting for the password constantly since it seems to no longer use a timestamp for the root user.
After a ton of searching and comparing the sudo configuration on older OS versions to Sierra's (sudo su; sudo -V), it seems that Sierra enables tty_tickets by default now, causing the issues mentioned above. As far as I can tell, this was an undocumented change. To fix, the following needs to be added to the /etc/sudoers file via running sudo visudo,
Defaults !tty_tickets
TLDR; BAD IDEA. This old behavior, while an option to sudo, is used as a default by NO OTHER UNIX-y OS that I have ever encountered. The reason being that it's trivial to exploit, and when exploited, the malignant code doing so will have full control of your system.
Original very long rant-y post, correctly pointed out to be blahdiblah:
LOL, this is funny. I came here from googling because I couldn't remember how I would change the old behavior to this new, correct one (used by every other UNIX-y OS out there). Hadn't even noticed my new Sierra Mac now behaved properly.
I wrote on the Mac forums earlier about this previous behavior which is a gaping security hole. I even supplied a three-line proof-of-concept script that would simply sit around (as a regular user) waiting for a sudo event to appear anywhere, then instantly gain root access to the system. I was booed out of the thread by the fanboys, then got banned from it from calling out lies. Seems Apple were listening, though. Good job, for once, Cupertino. Bad, BAD idea to try to get the old behavior back.
For reference, here's the three-liner. It doesn't do anything malignant, just adds a dummy file to the root of the filesystem once gaining sudo. Run it in a script (or just paste it somewhere which doesn't already have sudo), then either do a sudo in another terminal app/window or app which uses sudo (e.g. TrueCrypt/VeraCrypt or similar), then watch it work.
tail -f -n 0 /var/log/system.log | grep -m 1 -E 'sudo\[[0-9]+\]:\s+'$USER
echo "Gonna play around with root privs ..."
sudo touch /kilroy-was-here
I am trying to connect to a server via ssh. Once connected, terminal should be cleared.
Due to generated keys, I can connect to the server via ssh usr#svr without being prompted a password. This works.
In order to get rid off
The programs included with the Debian GNU/Linux system are free
software; the exact distribution terms for each program are described
in the individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
I would usually just type clear. However, I would prefer not to type this every time but automate the procedure instead.
ssh usr#svr "clear" --> "TERM environment variable not set.". I googled several solutions about unset environment variables, but without success.
So instead, I tried ssh -t usr#vr "clear"; this successfully clears the terminal, but also closes the connection right away ("Connection to IP closed."). Computer connects to server, clears the screen, closes the connection.
Next attempt was to create a bash script on the server to be run after connecting to it.
#/bin/bash
clear
## cl.sh, chmod +x
ssh usr#svr ./cl.sh --> "TERM environment variable not set.".
Another attempt was to create a bash script connecting to the server and clearing the terminal via ENDSSH.
#/bin/bash
ssh usr#svr <<'ENDSSH'
clear
ENDSSH
## sc.sh, chmod +x
Running this results in:
> ./sc.sh
Pseudo-terminal will not be allocated because stdin is not a terminal.
Linux raspberrypi 3.18.7-v7+ #755 SMP PREEMPT Thu Feb 12 17:20:48 GMT 2015 armv7l
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
TERM environment variable not set.
I am a beginner at this, so please be patient if I have made a very obvious mistake. I tried to be as detailed as possible and researched this before posting, but could not find an answer to my question. For example, commands other than "clear" work (ssh usr#svr ls), but that does not help me.
I have found another easy solution
ssh -t usr#svr 'clear;bash'
The text your question refers to is part of the message-of-the-day (MOTD).
If you can become root on the server, you can just modify that message in /etc/motd. Note that depending on the server's distribution, this file will usually be generated somehow (overwriting any changes), e.g. on Debian it is generated from /etc/motd.tail at boot, so you might have to change that file instead.
See manpage motd(5).
To prevent that message from being printed you can create a file named .hushlogin in your home directory (on the server). SSH to the server and run the command touch ~/.hushlogin. If that file exists then the login shell will no longer print the motd (message of the day) which is what you are seeing.
All startup messages are defined in motd file (/etc/motd).
However if you'd like to having your console cleared to increase privacy, add the following code:
[ -x /usr/bin/clear_console ] && /usr/bin/clear_console -q
Either to your .bash_profile or .bash_logout (on logout). Or by using clear command.
Clearing screen on logout is the default behaviour on Debian Linux distribution.
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.
Anyone knows how to start Syslogd server on Mac to accept remote logging messages?
I started Syslogd, but seems it doesn't accept remote messages.
If I do a netstat -an it looks like udp port 514 is listening. However, if I scan the server from my laptop using nmap then I don't see udp 514. It's likely the port is being blocked somewhere. I have checked ipfw but it does not look like any rules defined.
I've seen lots of articles say that have to specify -r option. Is this the same on Mac?
How to do that on Mac?
Syslogd should already be running on your system; what you need to do is enable its UDP listening option. This is controlled by a section near the end of /System/Library/LaunchDaemons/com.apple.syslogd.plist; remove the comment markers so that it looks like this:
<!--
Un-comment the following lines to enable the network syslog protocol listener.
-->
<key>NetworkListener</key>
<dict>
<key>SockServiceName</key>
<string>syslog</string>
<key>SockType</key>
<string>dgram</string>
</dict>
</dict>
</dict>
</plist>
And then reload the syslogd daemon either by rebooting, or by running:
sudo launchctl unload /System/Library/LaunchDaemons/com.apple.syslogd.plist
sudo launchctl load /System/Library/LaunchDaemons/com.apple.syslogd.plist
UPDATE: Starting in OS X v10.7, Apple switched com.apple.syslogd.plist to a binary plist format, which doesn't include the relevant comment, and isn't editable as plain text. With the new format, PlistBuddy seems to be the easiest way to add the listener:
cd /System/Library/LaunchDaemons
sudo /usr/libexec/PlistBuddy -c "add :Sockets:NetworkListener dict" com.apple.syslogd.plist
sudo /usr/libexec/PlistBuddy -c "add :Sockets:NetworkListener:SockServiceName string syslog" com.apple.syslogd.plist
sudo /usr/libexec/PlistBuddy -c "add :Sockets:NetworkListener:SockType string dgram" com.apple.syslogd.plist
sudo launchctl unload com.apple.syslogd.plist
sudo launchctl load com.apple.syslogd.plist
A bit old, but I did have to do this today and whilst searching around for a simple piece of software to do this for me I came across this question.
All I really wanted to do was watch some syslog entries for a short period of time and see what was coming from the server so what I ended up doing was:
sudo tcpdump -lns 0 -w - udp and port 514 | strings
This will simply print out any message that is sent to your machine on the output so you can display it.
Anyway if you do this and it outputs messages that are being transmitted to your server you can be sure it's not being blocked by your firewall or any other hardware in the middle.