I configured cygwin's SSHD service on two windows sever(2008) with USER1
I can successfully connect/SSH from/to each server with USER1.
What changes i need to make if i want to connect/SSH to server with other account say USER2?
Is it possible at all like in my case i have set up SSHD with USER1?
Related
I have several actions that need to be performed on a network of servers.
for these actions i have two options:
manually, this will take a lot of effort and potentially i will need to do it over and over again on different networks.
automatically, with scripts or ansible that do not allow password prompt when connecting with ssh.
some of these actions require root access. for example, the
useradd and groupadd commands need to be used.
also, i will need to change several files in etc and in var folder.
in terms of security, is it safe and acceptable to require passwordless root ssh access so that ansible or others will be able to do it?
if not, is it possible to add an official reference? preferably redhat site or other.
notice that using a sudoer user is not permitted.
I would say no, "passwordless root ssh access" is not secure. However, you can use key based authentication via ssh as root. In other words you can do what you want to do, just not exactly how you described it.
Adding users and groups is a very typical config mgmt task, and a perfect job for ansible. I would suggest creating an ansible playbook that uses the user and group modules rather than running the raw useradd and groupadd commands (See example below). However, this will require setting up the necessary ssh key based authentication.
Ansible can help with that task as well, but you'll have to authenticate with a password in order to setup the key based auth.
https://docs.ansible.com/ansible/latest/modules/user_module.html
https://docs.ansible.com/ansible/latest/modules/group_module.html
- name: Add the user 'johnd' with a specific uid and a primary group of 'admin'
user:
name: johnd
comment: John Doe
uid: 1040
group: admin
First of all, I am aware that this question has been posted several times in stack overflow here, here, here, as well as in some other places.
However, I decided to open a new thread (and taking the risk of being downvoted) because I don't think there is an actual issue with my machine, but with PUTTY.
Environment description
In a nutshell, I have a windows machine running a virtual machine (VMWare).
Host machine: Windows 7 (64 bit)
Guest machine: CentOS 6 with graphic windows environment.
Network connection perfectly setup, so no problems with firewall. Both machines are pingeable from each other, and I can surf the internet from both
Selinux disabled on guest machine
Putty is properly configured (or so I think). The reasons to back up the statement is that I can SSH the guest machine from the host machine with the encrypted SSH keys that I created for that matter. However, I think there is still some configuration missing. Keep reading.
I have configured GITOLITE on the guest machine, and it is up and running.
Although not relevant for this issue, I have a Samba share configured on the guest machine, were I have all my repos. The share is accessible from the host machine, and I can edit the files with no problem whatsoever.
VM Player 7
Guest machine recently restarted and no additional commands have been issued.
PUTTY installed in the host machine
Case scenario #1 (it works)
This case scenario describes the behaviour I expect to achieve. Basically, this procedure is being done within the VM itself. That means, by operating the machine through the VM Player.
Open a terminal as root
service sshd status yields openssh-daemon (pid 1557) is running...
ssh-add -l yields 2048 1b:31 [...] b8:de Git Admin (RSA), 2048 d2:58 [...] f6:2b pando (RSA) and (2048) be:9b [...] dc:e9 web (RSA). These are the three users I have configured in my virtual machine. The SSH keys have been automatically loaded and added to the list of identities of the SSH service.
Log out as root from the CLI. I am now an standard user (the pando user).
Edit one file in one of the repos
git commit -a -m "My message" is successful because the Git Admin key is in the identity list of the SSH agent
git push origin master is also successful, for the same reasons
Case scenario #2 (it does not work)
This case scenario describes the same procedure, but from the Putty terminal. I added to the Pageant the same SSH keys as described in Case Scenario #1, point 3. It looks like everything is Ok with Putty, because I can successfully SSH my virtual machine
Open the Putty Terminal. I am logged in as user pando (which is one of the identities mentioned in Case Scenario 1).
su
service sshd status yields openssh-daemon (pid 1557) is running... (notice that it is the same result as we got in point #2 of the first case scenario)
ssh-add -l yields Could not open a connection to your authentication agent
Because the previous step failed, I have all the issues described in the hyperlinked threads at the beginning of this post.
Now, I am familiar with that procedure of eval $(ssh-agent) and then to manually add the SSH keys on my SSH folder. In fact, I do that every time I SSH the virtual machine. But I actually prefer not to do it.
I am also familiar with adding some script to the .bashsrc file, but the last time I did it, I got a colateral effect with Puppet.
So the basic question is: What's the difference betwen both case scenarios, even though I am using the same SSH keys? Is it that Pageant is not forwarding the keys? If so, why am I able to SSH my machine? Why should I change the .bashrc file of my pando user in the second case scenario, when I can achieve exactly the same thing without it in the first case scenario? I guess I am missing a fundamental piece of information here
Hope that makes sense.
Regards.
openssh-daemon and authentication-daemon are not the same thing. You are interested in the authentication one aka ssh-agent, which is your personal key-store. The openssh-deamon aka sshd is server that is running system-wide and which is accepting connections to your computer.
Desktop environments usually start authentication agents (ssh-agent, seahorse, gnome-keyring) by default so the ssh-add works for you. But the connection is stored in environment variables, which are dropped in transition from your user to superuser (su).
You can allow connection persistence using -m switch to su. This will preserve environment variables and so your connection to authentication agent.
What's the difference between both case scenarios, even though I am using the same SSH keys?
There should be no difference, except the su part dropping environment variables and not executing .bashrc and similar scripts when changing user (you can force su to behave the same way as a login shell using su -l, but it is not the problem). The problem is that the connection to authentication agent is preserved as environment variable and UNIX domain socket, which gets lost during su. You can use su -m it should work for you.
Is it that Pageant is not forwarding the keys?
Forwarding needs to be allowed in PuTTY:
I two CentOS 6.5 servers and I have a very complex shell script connecting this two servers and make some backups with root user without password. There is some rsa keys for this.
For security purpes I disabled root login on both servers and I tried to change the script to use a user insted of root but it's doesen't work. I have changed the user rights from /etc/sudoers to user ALL=(ALL) ALL.
If I generate another ssh key with ssh-keygen -t rsa it say me that I don't have permisson and if I use sudo ssh-keygen -t rsa he create me a key for root#server.
I think the problem will be solve if I can change the user rights to run sudo comands without "sudo", like root but I don't know if this it's possible.
Thanks!
To maintain security, yet to accomplish this certain work, you need to do the followings:
Create a new user account, for this certain work only.
Give this user an ssh-key to automatically login without password.
The login shell should not be /bin/bash, for obvious security
reason. You can setup SSH connection to run certain program/command
for this specific user. I don't want to explain the details here.
Please search the web for the answer for this.
Since this program needs root permission, and this user is not the
root, you need to setup an effective executable permission as
root (i.e. setuid). To make it only executable by this certain user (and root),
you need to create a new group, set this user to join this group,
and set the program to be executable by this group (chmod 4770, 4
for setuid, 770 to be executable by the group, and the owner). The
program must be owned by root (so that it setuid to root), with the group assigned
to that certain group. The program can be a binary-executable, or a script.
That does not matter.
Caution: Your setuid program/script must be very careful not to
contain exploitable security weaknesses.
I have a need to restart a CentOS service remotely via ssh during an automated, unattended process (executing a build on some software from a build server), but am unsure how to best implement security. Help is needed! ;-)
Environment:
Running an ssh login on a remote box, I want to execute on my server something like:
/sbin/service jetty restart.
The ssh call is being made during a maven build process (probably doesn't affect anything, really).
I want the ssh session to login with a user that has practically zero permissions on the server except to execute the above.
I can set up shared key access for the ssh session.
Thanks!
Good idea to use an ssh key. You can then use a 'forced command' for that particular key, so it won't be able to run any other commands. See http://www.eng.cam.ac.uk/help/jpmg/ssh/authorized_keys_howto.html
I use rsync to mirror a remote server. It is said that using a root password with rsync is dangerous, so I created a special rsync user. It seems to work fine, but cannot copy some files because of file permissions. I want to mirror whole directories for backup, and I guess this cannot be done without using root password, I mean if root does not give permissions on a specific files, no other account can read them. Is there other solutions and why shouldn't I use root account in rsync (I only do one way copying, that does not effect source).
If you want the whole server, then yes, you need root. However, instead of "pulling" (where you have a cron on your local server that does "rsync remote local"), can you possibly do it by "push" (where you have a cron on the remote server that does "rsync local remote"?) In this case, you won't need to configure the remote server to accept inbound root connections.
One option is to use an ssh login as root, but using ssh pubkey authentication instead of a password. In general, pubkeys are the wya to go, if you want to automate this later.
You'll want to look into the PermitRootLogin sshd_config setting, in particular the without-password setting or, if you want to get even more sophisticated and (probably) secure, the forced-commands-only setting.
Some useful links:
http://troy.jdmz.net/rsync/index.html
http://www.debian-administration.org/articles/209