IT - BLOG - ADMIN
MySQL Create index alter table statement
This is my loose oneliner that i put here directly from console. I use it to move index definition manually between databases. Of course it is crapy and need to be reviewed and check false positives captured by GREP command.
mysqldump -u root --no-data --no-create-db --triggers -S /var/run/mysqld/mysqld.sock --databases DB1,DB2 | grep -v "^DROP" | sed 's/CREATE TABLE/ALTER TABLE/' | grep -e KEY -e ALTER -e USE | grep -v PRIMARY | sed s/\(\//g | sed 's/KEY/ADD KEY/g' | sed 's/)$/;/g'
Last time I was wondering how passwords are passed between PAM modules. Generally, I wanted the user to be asked for an OTP (verified in vault using app vault-ssh-helper) and a local password (usually checked in /etc/shadow) when logging to the server via ssh.
The PAM configuration should look something like this.
auth required pam_unix.so auth required pam_exec.so debug expose_authtok log = /var/log/vault-ssh.log /usr/local/sbin/vault-ssh-helper -dev -config=/etc/vault-ssh-helper.d/config.hcl
and sshd_config should also include:
ChallengeResponseAuthentication yes PermitEmptyPasswords no
vault-ssh-helper is an application written in GO, not a PAM library. Therefore, it must be run with
pam_exec.so. This is where the problem lies.
The combination of PAM and SSH works in such a way that the password entered by the user goes to both the pam_unix and pam_exec modules as input.
But I want a different behavior. I want pam_unix to ask the user for a password (checked in /etc/shadow) and pam_exec to ask the user for a password (checked in vault with vault-ssh-helper).
The first module - pam_unix, can ask a user for input. But pam_exec cannot. It can only read from stdin, which is the same password user typed and checked before using pam_unix.
Logging in will look (in short version) like that:
- User generate OTP in vault - example
vault write ssh/creds/otp_key_role ip=SERVER_IP
- User run the
- User is prompted for a password
- User enters the correct password
- This password is checked with
- The same password next is checked with
pam_exec.so /usr/local/sbin/vault-ssh-helper- for obvious reasons such operation will
- User is prohibited to log in.
As can be seen, there is no place here for the introduction of the OTP generated before.The only way out of this situation is the following configuration:
auth sufficient pam_unix.so auth sufficient pam_exec.so debug expose_authtok log = /var/log/vault-ssh.log /usr/local/sbin/vault-ssh-helper -dev -config=/etc/vault-ssh-helper.d/config.hcl
But unfortunately it will not meet my goal. In the example above, the user must provide a password or (not and) an OTP. One of these factors causes logging into the system.
Building ISO - bootable from pendrive + UEFI
If you are facing the problem of ISO content modification. You have unpacked everything, changed the content and you can't build a damn working image again with xorriso - I have one pro-tip. You can check the structure of the original ISO and generate commands to build a new one using the command:
xorriso -indev ./kali.iso -report_system_area plain -report_el_torito cmd
Output should look like this:
xorriso 1.5.2 : RockRidge filesystem manipulator, libburnia project. xorriso : NOTE : ISO image bears MBR with -boot_image any partition_offset=16 xorriso : NOTE : Loading ISO image tree from LBA 0 xorriso : UPDATE : 1305 nodes read in 1 seconds xorriso : NOTE : Detected El-Torito boot information which currently is set to be discarded Drive current: -indev './kali.iso' Media current: stdio file, overwriteable Media status : is written , is appendable Boot record : El Torito , MBR isohybrid cyl-align-on Media summary: 1 session, 443744 data blocks, 867m data, 26.7g free Volume id : 'Kali Live' System area options: 0x00000102 System area summary: MBR isohybrid cyl-align-on ISO image size/512 : 1774976 Partition offset : 16 MBR heads per cyl : 64 MBR secs per head : 32 MBR partition table: N Status Type Start Blocks MBR partition : 1 0x80 0x17 64 1773504 MBR partition : 2 0x00 0x01 1773568 1408 -volid 'Kali Live' -volume_date uuid '2018101617103600' -boot_image isolinux system_area=--interval:imported_iso:0s-15s:zero_mbrpt:'./kali.iso' -boot_image any partition_cyl_align=on -boot_image any partition_offset=16 -boot_image any partition_hd_cyl=64 -boot_image any partition_sec_hd=32 -boot_image any mbr_force_bootable=on -append_partition 2 0x1 --interval:imported_iso:1773568d-1774975d::'./kali.iso' -boot_image any iso_mbr_part_type=0x17 -boot_image any cat_path='/isolinux/boot.cat' -boot_image isolinux bin_path='/isolinux/isolinux.bin' -boot_image any platform_id=0x00 -boot_image any emul_type=no_emulation -boot_image any load_size=2048 -boot_image any boot_info_table=on -boot_image any next -boot_image any efi_path='/boot/grub/efi.img' -boot_image any platform_id=0xef -boot_image any emul_type=no_emulation -boot_image any load_size=720896
Final command to build new iso based on above:
xorriso -outdev ./kali_new.iso -indev ../kali.iso -map CONTENT_OF_ISO / \ -volid 'Kali Live' \ -volume_date uuid '2018101617103600' \ -boot_image isolinux system_area=--interval:imported_iso:0s-15s:zero_mbrpt:'../kali.iso' \ -boot_image any partition_cyl_align=on \ -boot_image any partition_offset=16 \ -boot_image any partition_hd_cyl=64 \ -boot_image any partition_sec_hd=32 \ -boot_image any mbr_force_bootable=on \ -append_partition 2 0x1 --interval:imported_iso:1773568d-1774975d::'../kali.iso' \ -boot_image any iso_mbr_part_type=0x17 \ -boot_image any cat_path='/isolinux/boot.cat' \ -boot_image isolinux bin_path='/isolinux/isolinux.bin' \ -boot_image any platform_id=0x00 \ -boot_image any emul_type=no_emulation \ -boot_image any load_size=2048 \ -boot_image any boot_info_table=on \ -boot_image any next \ -boot_image any efi_path='/boot/grub/efi.img' \ -boot_image any platform_id=0xef \ -boot_image any emul_type=no_emulation \ -boot_image any load_size=720896
As you can see, most of the extracted parameters can apply for a new build image.
A little tuning with
map parameters and that's all.