How to override sshd_config defaults with custom_override file inside /etc/ssh/sshd_config.d folder via puppet - ssh

I have installed the below version of openssh rpms
openssh-clients-8.0p1-13.el8.x86_64
openssh-8.0p1-13.el8.x86_64
openssh-server-8.0p1-13.el8.x86_64
In the default sshd_config file, I do not see "Include" directive mentioned in it.
grep -nr "Include" /etc/ssh/sshd_config returns nothing. Also "/etc/ssh/sshd_config.d" is not created by rpm. So what I did is created /etc/ssh/sshd_config.d directory and added this "Include /etc/ssh/sshd_config.d/*.conf" in last line of /etc/ssh/sshd_config. I am using puppet to override the default sshd_config file by setting sshd_config_path parameter in puppet ssh module to "/etc/sshd_config.d/custom_sshd_config.conf". ssh module of puppet is just take a copy of sshd_config file and replacing the lines as per puppet configurations. With this I face issues like having conflicting & duplicate values for many sshd_config configurations. One such example:
sshd_config:
HostKey /etc/ssh/ssh_host_rsa_key # duplicate
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
Subsystem sftp /usr/libexec/openssh/sftp-server
sshd_config.d/custom_sshd_config.conf:
HostKey /etc/ssh/ssh_host_rsa_key # duplicate (gets added by default puppet ssh module itself)
Subsystem sftp /usr/libexec/openssh/sftp-server # When Subsystem in defined in both the places,
# sshd service is failed to start, So I am
# manually commenting this out in one file
sshd -T output has duplicates:
...
hostkey /etc/ssh/ssh_host_rsa_key
hostkey /etc/ssh/ssh_host_ecdsa_key
hostkey /etc/ssh/ssh_host_ed25519_key
hostkey /etc/ssh/ssh_host_rsa_key
...
Adding the Include directive in the top also doesn't solve my problem. I am aware of the sshd man page note
first obtained value for each parameter is used in sshd : Order matters only when conflicting parameters exist, as the first obtained value for each parameter is used
Also directly overriding sshd_config file itself by puppet will solve this duplication/conflict issue, but my need is to maintain a separate custom_sshd_config file without overriding directly the original sshd_config file.
What I expect is "Include directive file should behave like overrides of default sshd_config". Is there any way to automate this in puppet like whenever an sshd configuration is overridden in custom_sshd_config file that needs to be commented in default sshd_config so that it will be overridden in real. It would be really helpful if someone helps me out with this issue. Thanks in advance!!

In the default sshd_config file, I do not see "Include" directive mentioned in it. grep -nr "Include" /etc/ssh/sshd_config returns nothing. Also "/etc/ssh/sshd_config.d" is not created by rpm.
I don't find that particularly surprising. The logical contents of sshd_config are order- and context-sensitive, so although there is an Include directive available, using it to provide for generic drop-in sshd configuration files doesn't work very well. I could see a more targeted approach involving drop-in files, perhaps, but not what you're actually trying to do.
Nevertheless, ...
what I did is created /etc/ssh/sshd_config.d directory and added this "Include /etc/ssh/sshd_config.d/*.conf" in last line of /etc/ssh/sshd_config.
... sure, you can do that if you want. But this ...
I am using puppet to override the default sshd_config file by setting sshd_config_path parameter in puppet ssh module to "/etc/sshd_config.d/custom_sshd_config.conf".
... seems both to misrepresent fact and to be unwise. In the first place, no, you are not overriding the default config file. That suggests that sshd would use the config file you specify instead of /etc/sshd/sshd_config, but clearly that's not happening. What you are doing is simply telling Puppet to manage a different file instead.
In the second place, doing that in the way you are doing it is downright begging for exactly the kind of problem you observe: duplicate / inconsistent configuration. You're managing etc/sshd_config.d/custom_sshd_config.conf as if it were a complete sshd configuration file (because that's what the module does), yet the only way it gets used at all is by being included by the main config file.
It's not clear how you even expect to gain anything from this, when you could simply manage the regular config file directly. You say that you can't do that, but you already are doing it, in the sense that you are placing an Include directive in it that was not provided by the RPM.
What I expect is "Include directive file should behave like overrides of default sshd_config". Is there any way to automate this in puppet like whenever an sshd configuration is overridden in custom_sshd_config file that needs to be commented in default sshd_config so that it will be overridden in real.
The module you're using (see also below) does not do this, and I don't see why it would. If you're going to modify the main config file anyway, then why would you not put the configuration directives you want there? Or if indeed you must not modify that file, then why are you proposing an approach that involves modifying it (further)?
One way to move forward would be to indeed change which file sshd uses for its main config file. You could do that on EL8 by managing sshd's systemd unit file to add an appropriate -f option to the sshd command line it uses.
Or if you're ok with modifying /etc/ssh/sshd_config after all, but you still want drop-in files, then you could consider removing everything but the Include directive from the main config file, and otherwise proceeding as you already are doing.
But if you want exactly what you describe, then you'll need to write your own module to handle it.
Speaking of modules, though, the one you linked to is a less-maintained and little used fork of the massively popular, Puppet-approved one by ghoneycutt. At this point, the two are out of sync. Unless you need something that's not in ghoneycutt's version, I would strongly suggest switching.

Related

ssh hostname suggestion(completion) feature not working

im using ssh with config files on zsh(5.8)/wsl2.
i made additional config files and included them in config file.
ssh feature works fine. but when i type the ssh command with hostname, hostname suggestion feature is working conditionally
suggestion feature works fine when i type the hostname that in config file
but not work when type the hostname that in Included config file( but ssh feature works fine.)
here's are my config file and included config files
config in ~/.ssh/
Include ~/.ssh/config_a # hosts of a
Include ~/.ssh/config_b # hosts of b
# myhost
Host my_host1
...(skip)
config_a ... additional config files in same path
# in a
Host a_host1
...(skip)
tried commands.
ssh my_ # and press `tab`, suggestion work.
ssh a_ # and press `tab`, suggestion didnt work.
ssh a_host1 # ssh work.
if merge them into one file then suggestion works around all hosts.
solved it by removing comments in Include ... lines.
Include ~/.ssh/config_a
Include ~/.ssh/config_b
# myhost
Host my_host1
...(skip)
OpenSSH supports the end of line comments. so, it has nothing to do with.
ref.
https://stackoverflow.com/a/74759246/77259637
zsh sshdconfig completion codes
additionally, i checked both bash and zsh. in bash, completion(suggestion) works fine.

Reset redis info statistics

I want to reset the statistics redis shows me in INFO command.
I read about https://redis.io/commands/config-resetstat
But for some reason it returns error:
redis> CONFIG RESETSTAT
ERR unknown command `CONFIG`, with args beginning with: `RESETSTAT`,
What am I doing wrong? I don't want to restart server, since I use digitalocean and I don't have direct SSH access, I have only access to redis-cli.
#for_stack is right, i want to expand the answer. It is not possible to use config command unless you/administrator modify the configuration file which requires a server access and restart.
How they disabled?
The CONFIG command was renamed into an unguessable name.
rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52
It is also possible to completely disable it (or any other command) by renaming it to the empty string.
rename-command CONFIG ""
You need to request your administrator(if it is possible) to remove that lines from the configuration file.

VScode remote connection error: The process tried to write to a nonexistent pipe

I use vscode with remote-ssh to connect my server, after configuring, I want to connect my host, but it failed, the dialog box display:"could not establish connection to XX, The process tried to write to a nonexistent pipe."
output:
[16:45:20.916] Log Level: 3
[16:45:20.936] remote-ssh#0.49.0
[16:45:20.936] win32 x64
[16:45:20.944] SSH Resolver called for "ssh-remote+aliyun", attempt 1
[16:45:20.945] SSH Resolver called for host: aliyun
[16:45:20.945] Setting up SSH remote "aliyun"
[16:45:21.012] Using commit id "c47d83b293181d9be64f27ff093689e8e7aed054" and quality "stable" for server
[16:45:21.014] Install and start server if needed
[16:45:21.019] Checking ssh with "ssh -V"
[16:45:21.144] > OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5
[16:45:21.214] Running script with connection command: ssh -T -D 5023 aliyun bash
[16:45:21.221] Terminal shell path: C:\WINDOWS\System32\cmd.exe
[16:45:21.504] >
>
>
> ]0;C:\WINDOWS\System32\cmd.exe
[16:45:21.505] Got some output, clearing connection timeout
[16:45:21.577] >
>
>
>
[16:45:21.592] > Bad owner or permissions on C:\\Users\\DY/.ssh/config
>
[16:45:21.689] > The process tried to write to a nonexistent pipe.
>
[16:45:22.091] "install" terminal command done
[16:45:22.092] Install terminal quit with output: The process tried to write to a nonexistent pipe.
[16:45:22.093] Received install output: The process tried to write to a nonexistent pipe.
[16:45:22.096] Resolver error: The process tried to write to a nonexistent pipe
[16:45:22.107] ------
Add the absolute file path to a custom SSH config file(C:\Users\{USERNAME}\.ssh\config), and my problem is solved.
If you format/re-install Server OS, but use same IP as before,
you may encounter fingerprint mismatched.
You may need to delete old fingerprint in this file:
C:\Users\xxx.ssh\known_host
and old IP in the file:
C:\Users\xxx.ssh\config
Then try to add host again.
What worked for me:
delete ssh config folder both in C:\Program Data\ssh and C:\<user>\.ssh
In VS Code, press F1, choose Remote-SSH: Connect to Host...
Do NOT enter anything in the prompt, but instead choose + Add New SSH Host..
Enter the full ssh command, including the key (in case of Windows,
you may want to enclose the path with double quote mark) ssh -i "C:\path\to\key" user#host. (you need to make sure the key has a limited permission. Remove all inherited permissions, and only give a full control to the owner.)
You will be asked to choose a folder in which a new config file will be created. Choose any of the two options.
There will a prompt notifying that the new config file
has been created. Click connect
At least three things may be happening:
Option 1
The location of your config file is not the absolute location, meaning you are probably using the location of the folder where the config file is.
If that is the case, access your User Settings in VSCode. Scroll to the Extensions>Remote - SSH. And add config at the end of the absolute file path of your custom SSH config file. In Windows, it can be
C:\Users\user\.ssh\config
See image below
Option 2
Authentication problems.
If that is the case, one of the things that may solve is generating new SSH keys.
In Windows, for that, I recommend using MobaXterm.
In MobaXterm, open a new terminal and write
ssh-keygen -b 4096 -t rsa
Then, in the config file, make sure that the IdentityFile points to the location of the key. MobaXterm's home directory, usually, is C:\Users\user\Documents\MobaXterm. If it makes it easy, one can copy/move the keys to C:\Users\user\.ssh and then just add, in the config file, IdentityFile ~/.ssh/KEY_rsa (where KEY_rsa is the name of the [public] key).
Note that if you use PuTTY to generate the keys, on the server OpenSSH authorized_keys file, one doesn't want the public key that one saves, but the one that appears on top (see image bellow):
Option 3
Your config file may be wrong.
The config file tends to look as follows. Double check if the fields have the information needed for the connection to be established.
Host Test # This is the name we want to give the host
User user # This is the username
Hostname blabla.com # This is the hostname
PreferredAuthentications publickey
IdentityFile ~/.ssh/KEY_rsa # This is the location of the key
IdentitiesOnly yes
Port 50 # This varies
What worked for me was to delete all of the contents of folder: C:\Users\MYNAME.ssh That meant to delete both the config file and known-hosts. The config was probably the most important one to delete.
The solution in my case was editing the json settings file for VSC as shown here: https://code.visualstudio.com/docs/remote/troubleshooting#_troubleshooting-hanging-or-failing-connections
In VSC go to File, Preferences, Setting and click on the upper right hand icon (Open Settings, JSON). Add these two lines to settings.json and retry connecting:
"remote.SSH.showLoginTerminal": true,
"remote.SSH.useLocalServer": false
In my case I had another setup:
Git bash in Windows was configured and I am using the ssh.exe provided by this tool
In the "Remote SSH" extension in VSCode, I specified the full path of this ssh.exe
I am using multiple servers (with ProxyJump)
The error message is the same as the OP but in the logs it was written that the ssh config file was not found, where all the folder names was concatenated (because it did not recognize the windows path separator)
Problem: the ssh.exe is using a different path convention thant VSCode. ssh.exe is using the "/c/Users/..." pattern and VSCode is using the "C:\Users..." pattern.
Solution:
Make sure the SSH config is at a standard place (C:\Users\LOGIN\.ssh\config)
Remove the absolute path of the config file in the "Remote SSH" settings in VSCode
VSCode will still be able to access the settings using the standard path, and the ssh.exe configuration will still look at the same standard path so the connexion is working.
Note:
I have the error only when connecting with multiple ssh servers (using ProxyJump). When connecting only to the first server, the solution of #pszrux and this one are both working for me.
This is probably something everyone has tried before looking here, but it worked for me. The server I was trying to ssh into was not responding, leading to the nonexistant pipe error. I rebooted the server and everything worked fine.
OS: windows 10
In my case there were permission issues. Repeatedly changing inheritance in windows did not solve the issue. Finally this worked
change the folder in which the config file is stored.
From C:/users/usr/.ssh/config to D:/config
and changed the config path in vscode remote ssh settings.
This worked for me.
This seems to be a problem with varied causes and corresponding remedies. In my case the problem had to do with the version of ssh I was using. In my Windows path there were two places were an instance of ssh.exe resided:
C:\Program Files (x86)\OpenSSH\bin
C:\WINDOWS\System32\OpenSSH\
After using both paths to set the "Remote.SSH: Path" parameter (which is in "Remote.SSH: Settings" [see here]), i.e. first C:\Program Files (x86)\OpenSSH\bin\ssh.exe and then C:\WINDOWS\System32\OpenSSH\ssh.exe, the problem still persisted.
Then I looked at this and tried the git-provided ssh.exe, which I already had on my system (otherwise, just install git, it's good stuff anyway :) )
Setting the SSH path parameter with that version did the trick for me, i.e. setting path to:
C:\Program Files\Git\usr\bin\ssh.exe
In my case, I did what dalilander said, but instead of deleting the entire '.ssh' folder, I just needed to delete the file 'known_hosts' and then it worked. So the servers I had saved were not deleted.
The path of that folder is C:\Users\yourUsername\.ssh
For Windows:
Adding the escape character before the private key file name & using quotes around the path solved my issue.
//config file
Host 12.12.12.12
HostName 12.12.12.12
IdentityFile "C:\Users\USERNAME/\PRIVATEKEY" <----Note /\
User username
Trying to add the full path in "IdentityFile" made the trick
" IdentityFile C:\Users\xxx.ssh\xxx"
The solution below may be the last resort but it perfectly solved the issue for me in a Windows 10 local machine. I simply delete the known_hosts file under the directory C:\Users\[your-username]\.ssh, relaunch VS Code and reconnect the remote server through Remote Explorer. Everything works normally afterward.
This seems to be a general error when the ssh connection fails for one of a multitude of reasons.
Adding what my issue was, and what helped, because I don't see it in the other answers in here: I had re-installed the box I was connecting to, and with it, reset the key it was using to authenticate. The ssh process tried to connect and failed with the usual "someone might be MITMing you this very moment, the identification changed" error, visible in the VSCode terminal. Solution was to go to my authorized_keys file and remove the offending key.
Obviously only know that if you know for sure why the identification changed, and that it's harmless. Don't actually get MITMed.
I had this problem once.
All you need to do is,
Go to /Users/XXX/.ssh
if you are on the windows, use command : "del /f known_hosts" to delete the known_hosts on the command prompt.
3.Then go to C:\Users\XXX.ssh\config on the vs code( config file )
4.Delete the host and the user if the host that you are trying to connect to is already there.
5.Then try to connect to the new host as usual.This will work.
The problem here could the mismatch of the finger prints once you reinstall the OS o n your host machine.
So to solve this problem by deleting the host that was saved.
once the config file on the vs code is edited it should look like..below picture is to show how the config file should look(after deleting the host saved)
If you're using WSL and might think that you should update ~/.ssh/config, that might not be the case.
Copy the content from ~/.ssh/config
Append it to C:\User\xxx\.ssh\config windows file
Make sure the public/private key is on C:\User\xxx\.ssh\ and is listed in config
Reconnect
Had an existing(working) configuration and had the same error when I added a new one. What worked for me is instead of just adding a new host configuration, I also commented out the first working config. Didn't know what happened but it worked.
In my case this was an offending key in my known_hosts in Windows (vscode on windows, remote developing via ssh on linux).
The error that comes back in vscode is not explaining in any way.
In my case, the path to key file was wrong.
For me, (windows) the permissions on the .pem file were the Critical issue. I had Administrator group only on the pem file and it was not working. I had to explicitly add the Admin user as well (even though admin is of course in administrator group).
In my case, I had no internet connection.
I was connecting to the server via VPN but the remote configuration was incorrect and I couldn't access the server. (DNS related issues) The connection indicator was showing no errors, so I didn't think of that at first.
Oops :)
I really didn't want to delete my C:Users\valo\.ssh\config, so I played a little with the various entries. It turned out that for me the option IdentitiesOnly yes was the problem. I also disabled security inheritance on all key files in the .ssh folder and left only myself, with Full Rights. Here is what my C:Users\valo\.ssh\config looks like now:
CanonicalizeHostname yes
Host aws.r3
HostName 3.31.45.216
ForwardAgent yes
User ubuntu
IdentityFile C:Users\valo\.ssh\u1-client-20210203-090555.pem
# IdentitiesOnly yes # VSCode Remote doesn't like this flag...?
Host github
HostName github.com
User git
IdentityFile ~/.ssh/id_val_ed25519
Host github.vm
HostName github.com
User git
IdentityFile ~/.ssh/id_valo_ed25519
Host *
ForwardAgent yes
AddKeysToAgent yes
LogLevel FATAL
ChallengeResponseAuthentication no
Now I can connect to aws.r3 with VSCode Remote.
A possible solution:
First run cat $HOME/.ssh/id_rsa.pub on your computer. That will get you a key. Save this key somewhere.
Then open this file by running vim $HOME/.ssh/authorized_keys on the computer that you're are ssh'ing to. Then copy the key in a new line of this file and close it by typing :wq.
You are all set.
In my case it was because the name I gave the host in config was myuser#myhostname. So if your config file looks like this:
Host myuser#myhostname
HostName 12.64.88.234
User myuser
Port 22
Try changing it to this:
Host myuser
HostName 12.64.88.234
User myuser
Port 22
Mine was solved by adding ".pem" extension while specifying the private key.
Here's the sample config text for reference.
Host ec2-3-234-8-176.compute-1.amazonaws.com
HostName ec2-3-234-8-176.compute-1.amazonaws.com
IdentityFile ~/.ssh/privatekey.pem
User username
There can be several reasons that have nothing to do with the accepted answer. For me:
Ubuntu 14.04.1 LTS didn't seem to work
Issues with EC2 auth, see pem file config and pem file permissions
And for yet another seeming cause/solution:
Adding the config path explicitly to settings only caused an EISDIR error.
Removing the listing from known_hosts made it need to confirm the fingerprint, but it didn't provide a way to do that. I could see it trying in the terminal output.
The solution a coworker recommended was to delete the vscode-server files from the server. That was the key step in my case. But...
Connecting to the server using another client, I attempted to rm -rf ~/.vscode-server. I could not delete many of the files because "device or resource busy".
That eventually required doing the following:
fuser ~/.vscode-server/[one of the child files ...]. But, you can probably skip this, because mainly I needed to know what to search for. Plus, fuser and lsof were finicky about returning results -- they often just sit waiting for something, I don't know what.
ps -e | grep node since node is the running process using vscode-server files.
For each PID in the list of node processes from step 2, run ps -o user= -p PID, substituting PID with each process PID in turn. This creates a formatted list of the process's associated user.
This is to determine which node processes you own, so you're not even trying to kill anybody else's.
Starting with the lowest node PID I own, run kill -9 PID. You won't need to run this for all PIDs, because killing a lower PID killed a child PID after a few seconds. So keep checking which node processes still exist after killing one: ps -e | grep node
Finally, once all mine are killed, I can rm -rf ~/.vscode-server
Then, I was able to connect via ssh in VS Code again. And, since I left the fingerprint removed from known_hosts, it even asked to confirm the connection to the server (up top, in the command prompt).
Also, for reference, I left the remote-ssh: settings config file entry, mentioned in other solutions, blank.
For reference or further explanation of certain steps above (I don't intend to elaborate more than I did):
rm: cannot remove ‘.vscode-server/bin/xxxxxx/.nfs000000000xxxxxxxxxxxx’: Device or resource busy
How find out which process is using a file in Linux?
https://unix.stackexchange.com/questions/284934/return-owner-of-process-given-pid/284938
In my case it worked when I added the port in my expression, eg ssh user#host-or-ip -p 22. With '22' the default port number, but you can check which port the ssh system is listening on with the sudo service ssh status command.
WSL Related
In my case, the issue was that my keys were set up on Ubuntu on WSL and VS Code was looking for them in Windows. I copied the keys over from the WSL side to Windows and voila! Worked like a charm!
Steps that I took.
Navigated to the /home//.ssh folder in WSL and then entered explorer.exe .
From there, I copied the id_rsa and id_rsa.pub files and pasted them in the windows side, under C:\Users<username>.ssh
Then I tried connecting again from VS Code and it worked perfectly.

Alternate SSH connection on GitLab.com Config File

Going through this article to overcome the blocked port 22.
They require you to edit the config file in the .ssh directory, but for the life of me I cannot find a config file inside the .ssh directory
C:\users\myuser\.ssh Only has my generated ssh keys in there. No config file.
Literally the only place I could find any resemblance of a ssh_config file is shown below, and tried updating that config but to no avail.
Does any one know where on earth do you find that config file?
C:\users\myuser.ssh is the right place.
If the config file isn't there simply create it. the Following command in the .ssh folder for example.
touch config
And then put your config inside
Thanks to #user43968 to putting me on the right track
So I got it to work
Create the file and add the connection settings in there.
Then, I used Sourcetree and updated the settings as follow
For the username and password, add the username and password to the proxy server. That was the main issue stopping me from cloning anything.

How to change the Admin port on Glassfish inside a script

Got a weird Glassfish issue here. Here's how to reproduce it:
(1) Install Glassfish v3
(2) Start your default domain:
$GLASSFISH_HOME/bin/asadmin start-domain domain1
(3) Change the admin port (you'll need to enter admin uid & password, in our script we use the -u & -W parameters):
$GLASSFISH_HOME/bin/asadmin set configs.config.server-config.network-config.network-listeners.network-listener.admin-listener.port=34848
(4) Shut down the domain:
$GLASSFISH_HOME/bin/asadmin stop-domain domain1
You'll see this doesn't work. You get:
CLI306 Warning - server is not running.
Command stop-domain executed successfully.
But your Glassfish process is still running. Worse, when you attempt to start the process you'll get a warning that some of your ports are already in use. Of course they are, the old process has still got 'em! Your only way out is killall -9 java
While some of the config changes are dynamic it seems this one isn't but the domain stop assumes it is dynamic and uses the new port to try and execute the command.
Possible solutions are:
(1) Use sed on domain.xml - would prefer not to as it's complicated & risky grepping through XML code. I've seen Glassfish change the order of attributes in this file so we can't just sed for port="4848"
(2) Use the scripted installer rather than the zip file and feed the parameters to the setup program as an answer file - this is problematic for our install scripts which are required to be idem potent.
(3) Use a custom crafted zip of the Glassfish install archive with domain.xml already changed - not an option as the port we are setting may change in the future.
This is almost the definition of a corner case but one we need to solve. For now we're going to sed domain.xml but it would be nice to know if there was a way that's possible via the CLI.
You might want to do the following instead...
install v3 by unzipping
delete domain1
create a new domain1 using the ports that you prefer.
The man page for the create-domain subcommand will have all the details
start this new domain...
No extra start or stop necessary (and you can skip step 2 if you are willing to remember to say 'asadmin start-domain mydomain' instead of 'asadmin start-domain'
Sed wasn't as bad as I thought it might be, here's what I did:
cd $GLASSFISH_HOME
sed -i.bak '/<network-listener[^>]*name="admin-listener"/s/port="4848"/port="34848"/g' glassfish/domains/domain1/config/domain.xml
It's still a bug that asadmin thinks the port change is dynamic when it isn't but I can live with this hack.