Connecting to a gitolite server from Windows and Eclipse - linux

So, I followed this tutorial to install a gitolite server.
But my client machine is a Windows machine, not a Linux box.
So, instead of using ssh-keygen, I used Eclipse "ssh2" utility (in windows, preferences, general, network connections, ssh2).
I generated the .pub file and used to setup gitolite (like in the tutorial).
But it doesn't seems to work, I always get a "Connection refused: connect" when I try to connect to my server from windows using this URL :
ssh://gitolite#192.168.0.193:22/gitolite-admin
I opened the .pub files generated by Eclipse and what I find funny is that there is always 2 equals signs at the end.
For example, here's one generated public key :
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQCQbDy+Nfoq+AitTrAbxy0PwRuBmgnm/vJk27KNOB3EzsZFKQ7+89I12nbxc8N+7z4Seq9fhNrYHfM7PvzgdI8F5QLxWbl2QV0UapBpjWmX+7WEE9bjEHIf7re3FpRzVdJrCAwscaUawmsIGi1rvw8ZFrbfPdS6ITiI10WcfTEdCw== RSA-1024
Is it possible to try another key pair without having to reinstall gitolite?
Can I generate the key pairs on my linux box and just upload the private key generated on my Windows machine?
Any other help on how I can diagnose the problem would be great.
UPDATE #1 :
I found out that no ssh server was running on my server. You can see that with :
sudo nmap -sS xxx.xxx.xxx.xxx -p 22
If the port's state is closed, then your SSH service is either closed or doesn't exists.
You can also try to connect with Putty (on windows) with SSH on your Linux machine, you'll see if the SSH server is working properly.
If your SSH service is not started, you can start the service with :
sudo service ssh start
If the service doesn't exists, you'll need to install an ssh server. I installed mine (on Ubuntu) like this :
sudo apt-get purge openssh-server
sudo apt-get install openssh-server
After installing openssh, everything was working fine on my box.

First, if you have msysgit installed, you perfectly can use ssh-keygen (included in this msysgit module).
The official help page for installing gitolite can also help.
Don't worry about the two == at the end of the public key. It is normal, and what follows those two == is always ignored (for instance, you can place a comment here for you to remember what that public key is for, if you want).
Now:
Is it possible to try another key pair without having to reinstall gitolite?
.
Yes. See "lost admin key/access":
Make yourself a new keypair and copy the public key to the server as 'alice.pub'.
Log on to the server, and run gitolite setup -pk alice.pub.
.
That's it; the new alice.pub file replaces whatever existed in the repo before.
Can I generate the key pairs on my linux box and just upload the private key generated on my Windows machine?
.
No, you need both private and public key on your %HOME%/.ssh folder (which means you must have HOME environment variable defined on Windows)
I would then recommend an %HOME%/.ssh/config file to use your keys.
Any other help on how I can diagnose the problem would be great.
.
The official doc has many tips.
I have a few ssh debugging tips as well.

Related

gnome-keyring GPG integration in headless Ubuntu server not working

I'm trying to use gnome-keyring to memorize my GPG passphrase in a headless Ubuntu server (22.04.1 LTS GNU/Linux 5.15.0-57-generic x86_64). The reason I'm trying to do this with gnome-keyring and not using the gpg-agent cache is that I'd like for the GPG certificate to be immediately accessible to be used by some systemd cronjobs when I reboot my server.
I've followed the Gnome/Keyring instructions but using pinentry-gnome3 doesn't seem to work:
No Gcr System Prompter available, falling back to curses
I've also tried using pinentry-gtk-2 like it is mentioned in GnuPG instructions and although I don't get any error, the passphrase is not stored.
When doing some debugging, I've found some weird behavior. Trying to store something in my keyring gives me this error:
$ secret-tool store --label='test' foo bar
secret-tool: Cannot create an item in a locked collection
Anyone can help me? I'm also willing to drop using gnome-keyring for something else, but I haven't found anything that would fit my use case.

chef kitchen not working from Windows 10 integrated bash

I am receiving the following error when trying to run any command in 'kitchen':
bash: /mnt/c/opscode/chefdk/bin/kitchen: C:/opscode/chefdk/embedded/bin/ruby.exe: bad interpreter: No such file or directory
It works from outside integrated bash when using the chefdk client, however I am trying to get this working from integrated bash.
Chef utility commands such as 'chef-client' and 'knife' seem to be working so far.
A possible solution for the SSH key permissions issue below
We REALLY need to get this working all the way through because it is SO much faster than the native ChefDK on Windows! The below will get you closer:
Stop Windows From Sharing PATH with WSL
Use Regedit.exe to create a DWORD DistributionFlags with value fffffffd under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LxssManager. Then go to Services and restart the LxssManager service.
Download and install ChefDK and Vagrant for Ubuntu in WSL
Add some windows paths to your WSL Path
export PATH="$PATH:/mnt/d/bin/Oracle/VirtualBox:/mnt/c/Windows/System32:/mnt/c/Windows/System32/WindowsPowerShell/v1.0"
Allow Vagrant Windows Access
export VAGRANT_WSL_ENABLE_WINDOWS_ACCESS='1'
Run kitchen converge and it now works
Running kitchen login still has issues. It complains about insecure vagrant private key:
/opt/chefdk/embedded/lib/ruby/gems/2.5.0/gems/test-kitchen-1.22.0/lib/kitchen/instance.rb:217: warning: Insecure world writable dir /home/dgames/.yadr/bin in PATH, mode 040777
###########################################################
# WARNING: UNPROTECTED PRIVATE KEY FILE! #
###########################################################
Permissions 0777 for '/mnt/k/20180707-mbp/repos/github/cloud/ssl_certs/.kitchen/kitchen-vagrant/all-cacerts-centos-72/.vagrant/machines/default/virtualbox/private_key' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/mnt/k/20180707-mbp/repos/ge_github/cloud/ssl_certs/.kitchen/kitchen-vagrant/all-cacerts-centos-72/.vagrant/machines/default/virtualbox/private_key": bad permissions
vagrant#127.0.0.1's password:
We haven't set things up to work with WSL as the Windows ChefDK installers are native Windows-y builds of everything. I recommend using the bash from MSYS2 if you want that as a shell.

Pass password through jenkins build step

I'm trying to add a build step in jenkins to copy files from my build server to my web application server. I've got the following command working in the command prompt
sudo scp -r /var/lib/jenkins/workspace/demoproj/publish root#0.0.0.0:/usr/temp
but when I run this command, it prompts me for a password every time. I found out about sshpass, but when I run this command...
sudo sshpass -p "passwordhere" scp -r /var/lib/jenkins/workspace/demoproj/pub root#0.0.0.0:/usr/temp
the terminal gets stuck. And never makes it through.
My main problem is if I add the first command to a build step in jenkins, it won't be able to pass the password over. How can I either supply the password in jenkins, or modify the command to pass over my credentials?
Helpful information: I'm using Putty on Windows 10 to connect to my
Ubuntu 16.04.3 LTS x64 servers from another Ubuntu 16.04.3 server.
First, sshpass needs to be installed on both the systems that is, the one running your jenkins instance as well as the one you are trying to access that is: root#0.0.0.0. You can verify it by doing 'which sshpass' or 'whereis sshpass'. If its not installed even in one of them then you need to install it first.
Also, Have you ever tried doing a ssh to the said machine: root#0.0.0.0 from the system where you have your jenkins instance? If not then there might not be an entry in the 'known-hosts' of either system. for that you can do ssh with '-o StrictHostKeyChecking=no' option to make an automatic entry in known-hosts.
Alternatively, if you dont want to enter password again and again you should work with 'keys'. Generate a unique key for both the systems and do an scp or ssh with -i option.
You should use jenkins credentials instead of using sensitive passwords directly into the scripts. Put the whole scp or ssh part inside a block which looks like: withCredentials(){}.
What's the point of having CI if you are required to be nearby to enter password every time? Install "publish over ssh" plugin, it has a step to send stuff over ssh.
https://wiki.jenkins.io/display/JENKINS/Publish+Over+SSH+Plugin
Look at "Use SSH during a build" section, you can use "send files or execute commands over SSH" build step. This shall become available after plugin installation.

connect to windows server 2003 from redhat linux client through ssh

I want to connect windows server 2003 remotely from red hat Linux client. I know that Linux has SSH but windows doesn't have. So is there any way.
sure
just install cygwin on your win machine and enable SSH (in the installer include ssh packages)
http://www.cygwin.com/
after that you can ssh to the win machine from your Linux machine.
enjoy
I've written a little reminder for myself about installing sshd on Cygwin.
Please see Cygwin install and sshd install.
First install cygwin.
See cygwin.com. Follow the installation instructions. I recommend the following options:
Install from Internet
All Users
Use IE5 Settings
Select a mirror near you (if you can find out where they are!)
Make sure to Select Packages below (among others) besides the Base packages:
cygrunsrv
openssh
You can export the Windows user list to Cygwin.
$ cp /etc/passwd /etc/passwd.old # backup for safety
$ mkpasswd > /etc/passwd
Start sshd
Next, start the Secure Shell Daemon (sshd) service on Windows
This will allow users on remote computers to log in to your box, get an interactive shell and do whatever they want. Or rather whatever you allow them to do. Remember?
There is a nice guide with a lot of troubleshooting info here.
In a nutshell. Start a Cygwin Shell window.
$ ssh-host-config -y
When prompted for “CYGWIN=”, type “tty ntsec”.
I do not allow login by password, only the public-key method. See below. So change the related line in /etc/sshd_config like this:
PubkeyAuthentication yes
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
Finally start the service:
$ cygrunsrv --start sshd
Administering users with public-key authentication
foo wants to log in remotely to your box’s bar account.
He sends you his public RSA key id_rsa.pub in any way, email, pen-drive, whatever YOU trust.
If you find foo worthy, you authorize his key, and from then he will be able to log in to your bar account via ssh without typing bar’s password:
$ cat id_rsa.pub >> /home/bar/.ssh/authorized_keys

SCP error: Bad configuration option: PermitLocalCommand

When I execute this command below:
scp -P 36000 hdfs#192.168.0.114:~/tmp.txt SOQ_log.txt
I get an error:
command-line: line 0: Bad configuration option: PermitLocalCommand
Does anyone know why?
scp runs a copy of the ssh program to create the communications channel, and it runs ssh with the options:
-oForwardAgent=no -oPermitLocalCommand=no -oClearAllForwardings=yes
So that explains where the "PermitLocalCommand" option is coming from in the first place. I'll add that sftp uses the same options to run ssh, so it'll probably display the same behavior.
"PermitLocalCommand" is normally a valid ssh configuration option. If your copy of ssh is complaining about it, then it seems that your copy of ssh isn't the normal copy of ssh that goes with your copy of scp.
This serverfault question suggests that the error could be due to someone installing a malware version of ssh (ie, a rootkit) on your system. This forum thread also suggests that the problem is due to having an altered version of ssh, which was fixed by removing and reinstalling the OpenSSH client utilities.
An alternate explanation would be that someone--maybe your Linux distro maintainer--has installed a version of ssh on your system with that option removed, and you're using it unawares. Or you have a very old version of the ssh program for some reason, which doesn't support the option.
My system is CentOs 5.9
I'm facing the same problem, I found it to be due to this configuration line in /etc/ssh/sshd_config:
# override default of no subsystems
Subsystem sftp /opt/libexec/sftp-server
But I cannot run /opt/libexec/sftp-server, it is broken for some reason
now it is solved by reinstall the remote openssh-server:
yum erase openssh-server
yum install openssh-server
now the changes to
# override default of no subsystems
Subsystem sftp /usr/libexec/openssh/sftp-server
and /usr/libexec/openssh/sftp-server is runnable
don't forget to execute:
/etc/init.d/sshd restart
Sometimes command cannot parse this kind of stuff
:~/
Id change it to the full path.

Resources