Matt B's questions

Setting up firewallD on Centos 7 servers. They use LDAP for authentication over SSH login. Do I need to explicitly allow port 389 LDAP on the default zone on FirewallD or because iv allowed SSH and the server will connect outbound to LDAP initially, will this not be required for the return inbound connection?

Im not very familiar with LDAP. I suppose it would be possible that the server connecting to LDAP server will only need to read the LDAP directory and the LDAP server wont need to send over any data on port 389?

I have a script that works fine on Centos because useradd doesnt require a password to be set there and then, but the same script doesnt work on ubuntu servers as it requires this info.

I ideally want to force no password set on my script for the ubuntu servers or add a line where it sets the password during the useradd command.

If I just add sudo passwd user to my script this will only take effect after the useradd command which is too late.

Any ideas?

I wrote this script which now works perfectly on systems without SElinux installed.

echo Enter server IP:
read server
scp /home/Zenoss/.ssh/authorized_keys random@$server:/home/random
sshpass -p randompassword  ssh -t  random@$server sudo -i 'useradd zenoss; sudo mkdir /home/zenoss/.ssh; sudo mv /home/random/authorized_keys /home/zenoss/.ssh/;
sudo chmod 700 /home/zenoss/.ssh;
sudo chmod 600 /home/zenoss/.ssh/authorized_keys;
sudo chown -R zenoss /home/zenoss/.ssh;
sudo chgrp -R zenoss /home/zenoss/.ssh;
exit'

So on servers without SElinux the script works and then Zenoss can log in to the remote server via SSH and start to monitor. However on systems with SELinux enabled, the script works, but Zenoss cannot SSH onto the remote server, the debug information shows that its not seeing the authorized_keys file that was successfully set up.

OpenSSH_6.6.1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 56: Applying options for *
debug1: Connecting to ***** port 22.
debug1: Connection established.
debug1: identity file /home/zenoss/.ssh/id_rsa type 1
debug1: identity file /home/zenoss/.ssh/id_rsa-cert type -1
debug1: identity file /home/zenoss/.ssh/id_dsa type 2
debug1: identity file /home/zenoss/.ssh/id_dsa-cert type -1
debug1: identity file /home/zenoss/.ssh/id_ecdsa type -1
debug1: identity file /home/zenoss/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/zenoss/.ssh/id_ed25519 type -1
debug1: identity file /home/zenoss/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr [email protected] none
debug1: kex: client->server aes128-ctr [email protected] none
debug1: kex: [email protected] need=16 dh_need=16
debug1: kex: [email protected] need=16 dh_need=16
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA ***************
The authenticity of host '******' can't be established.
ECDSA key fingerprint is **************************
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '*******' (ECDSA) to the list of known hosts.
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/zenoss/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering DSA public key: /home/zenoss/.ssh/id_dsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/zenoss/.ssh/id_ecdsa
debug1: Trying private key: /home/zenoss/.ssh/id_ed25519
debug1: Next authentication method: password
zenoss@****s password: 

Does anyone know what causes this and how I can work around it, disabling SELinux isnt an option.

KR

I am a new sys admin who is learning the role as I go. I have a bash script here that I cant get to work. This is just a test script as its my first one so I know setting authorized_keys to 777 is unwise but I am just doing it to check if my script works for now.

I am using LDAP with passwords so SSH onto a remote device with keys isnt ideal so I am using ssh pass.

This code works up to useradd, then it doesnt mkdir .ssh, doesnt touch/create authorized_keys, and doesnt change the file permissions.

Why?

#!/bin/bash -x


username="test"


echo Enter server IP:
read server
sshpass -p randompassword ssh myusername@$server sudo -i 'useradd test1;
echo $username user added, press any key to continue;
read;
sudo -i;
mkdir /home/test1/.ssh;
cd /home/test1/.ssh;
touch authorized_keys;
chmod 777 authorized_keys'

Im probably not understanding something about bash scripting correctly but all these commands need to run on the remote machine.