In order to let myself log into two different Heroku accounts I'm using .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
[branch "master"]
[remote "heroku"]
url = git#myrepo:myrepo.git
fetch = +refs/heads/*:refs/remotes/heroku/*
[remote "origin"]
url = git#github.com:peternixey/myrepo.git
fetch = +refs/heads/*:refs/remotes/origin/*
and ~/.ssh/config:
Host myrepo
HostName heroku.com
IdentityFile ~/.ssh/myrepo
IdentitiesOnly yes
GitX doesn't seem to be able to handle this
GitX doesn't seem to be picking up the correct key for the account. It keeps trying to use id_rsa.pub when the correct key is myrepo.pub. There is also a passphrase on the RSA key itself.
This is GitX(l) (as in L for Lima) and it's basically unusable in the current configuration, how can I stop the password demands?
I managed to fix this by deleting the previous keys and regenerating them. I think that somehow GitX had got caught up with the wrong key (or else I was entering the wrong password). Seemed more likely to be my fault than GitX's
Related
The problem is that the settings page cannot be accessed. I sign in successfully by using the default administrator account admin. It redirected me to the login page and clikcing on the account showed the login page again.
The version is 3.2.2. The auth.type is DEVELOPMENT_BECOME_ANY_ACCOUNT since it is configured for a test environment. The access to the gerrit-sshd is successful. Details about the gerrit-config file are given below.
[gerrit]
basePath = git
canonicalWebUrl = http://10.7.225.79:7000/
serverId = a741248c-d502-4a4d-aed8-188ca2b8be36
[container]
javaOptions = "-Dflogger.backend_factory=com.google.common.flogger.backend.log4j.Log4jBackendFactory#getInstance"
javaOptions = "-Dflogger.logging_context=com.google.gerrit.server.logging.LoggingContext#getInstance"
user = gerrit
javaHome = /usr/lib/jvm/java-8-openjdk-amd64/jre
[index]
type = lucene
[auth]
type = DEVELOPMENT_BECOME_ANY_ACCOUNT
[receive]
enableSignedPush = false
[sendemail]
smtpServer = localhost
[sshd]
listenAddress = *:29418
[httpd]
listenUrl = http://*:7000/
[cache]
directory = cache
[plugins]
allowRemoteAdmin = true
the information about version is given below:
# java
# command: java -version
openjdk version "1.8.0_252"
OpenJDK Runtime Environment (build 1.8.0_252-8u252-b09-1~16.04-b09)
OpenJDK 64-Bit Server VM (build 25.252-b09, mixed mode)
# gerrit
# command: ssh -p 29418 admin#10.7.225.79 gerrit version
gerrit version 3.2.2
I'm not sure but maybe this is the way things work when "DEVELOPMENT_BECOME_ANY_ACCOUNT" is set.
Take a look at the Gerrit documentation about this:
DEVELOPMENT_BECOME_ANY_ACCOUNT
DO NOT USE. Only for use in a development environment.
When this is the configured authentication method a hyperlink titled
Become appears in the top right corner of the page, taking the user to
a form where they can enter the username of any existing user account,
and immediately login as that account, without any authentication
taking place.
I'm getting an authentication error when trying to connect ssh host.
The goal is to connect to the host using local forwarding. The command below is an example using drop bear ssh client to connect to host with local forwarding.
dbclient -N -i /opt/private-key-rsa.dropbear -L 2002:1.2.3.4:2006 -p 2002 -l
test_user 11.22.33.44
I have this code so far which returns empty connection
ip = "11.22.33.44"
user = "test_user"
port = 2002
ssh_config = [
user_interaction: false,
silently_accept_hosts: true,
user: String.to_charlist(user),
user_dir: String.to_charlist("/opt/")
]
# returns aunthentication error
{:ok, conn} = :ssh.connect(String.to_charlist(ip), port, ssh_config)
This is the error Im seeing
Server: 'SSH-2.0-OpenSSH_5.2'
Disconnects with code = 14 [RFC4253 11.1]: Unable to connect using the available authentication methods
State = {userauth,client}
Module = ssh_connection_handler, Line = 893.
Details:
User auth failed for: "test_user"
I'm a newbie to elixir and have been reading this erlang ssh document for 2 days. I did not find any examples in the documentation which makes it difficult to understand.
You are using non-default key name, private-key-rsa.dropbear. Erlang by default looks for this set of names:
From ssh module docs:
Optional: one or more User's private key(s) in case of publickey authorization. The default files are
id_dsa and id_dsa.pub
id_rsa and id_rsa.pub
id_ecdsa and id_ecdsa.pub`
To verify this is a reason, try renaming private-key-rsa.dropbear to id_rsa. If this works, the next step would be to add a key_cb callback to the ssh_config which should return the correct key file name.
One example implementation of a similar feature is labzero/ssh_client_key_api.
The solution was to convert dropbear key to ssh key. I have used this link as reference.
Here is the command to convert dropbear key to ssh key
/usr/lib/dropbear/dropbearconvert dropbear openssh /opt/private-key-rsa.dropbear /opt/id_rsa
I am trying to connect to a MySQL server through R and it works perfect with the follwoing line:
con <- dbConnect(MySQL(), user="user", password="password",dbname="dbname", host="localhost", port=3306)
But, I would like to use a cnf file so that my user/apssword credentials donot appear in my code and tried the following:
rmysql.settingsfile<-"mydefault.cnf"
rmysql.db<-"test_db"
drv<-dbDriver("MySQL")
con<-dbConnect(drv,default.file=rmysql.settingsfile,group=rmysql.db)
And this is how my cnf file looks:
[test_db]
user=user
password=password
database=dbname
host=localhost
port=3306
It is in the same folder as in my R script which is my current working directory. But, I run into the following error:
Error in mysqlNewConnection(drv, ...) :
RS-DBI driver: (Failed to connect to database: Error: Access denied for user 'ODBC'#'localhost' (using password: NO)
)
Any suggestions, please?
Thanks so much
I had this problem very recently. RMySQL looks in the root directory for these files so you need to fully qualify the location of the file. i.e.:
rmysql.settingsfile<-"/home/MD-Tech/mydefault.cnf"
or
rmysql.settingsfile<-"c:\Users\MD-Tech\rfiles\mydefault.cnf"
Two things could be going on.
The CNF file should be encrypted, password should say password = ****. The MySQL documentation shows how to create a CNF file. Below would work for your code to create the CNF
shell> mysql_config_editor set --login-path=test_db --host=localhost --user=user --password
press enter without typing password, you will be prompted to enter it
The second thing is that user = NULL and password = NULL are missing as referenced in the src_mysql documentation
rmysql.settingsfile <- "~/.mylogin.cnf"
rmysql.db <- "test_db"
drv <- dbDriver("MySQL")
con <- dbConnect(drv, default.file = rmysql.settingsfile, group = rmysql.db, user = NULL, password = NULL)
When you add these and run the code, you should be set.
Fing something working at: https://www.r-bloggers.com/mysql-and-r/
Not in configuration file... but work.
con <- dbConnect(MySQL(),
user="me", password="nuts2u",
dbname="my_db", host="localhost")
Ya, getting this setup for the first time can be like pulling cats' teeth! Here is what I did while running R on a Droplet (Ubuntu 16.04, MySQL 5.7.16).
First, make sure you can at least login successfully to MySQL through the terminal
mysql -u kevin -p
Next, run R and verify that you can login in directly with dbConnect() using a user name and password
mydb = dbConnect(drv, user='kevin', password='ilovecats', dbname='catnapdb', host='127.0.0.1', port=3306)
Edit your mysql.cnf text file and at the bottom add a new group (exact name of this file and its location will depend on operating system and versions).
[whiskerpatrol]
user = kevin
password = ilovecats
host = 127.0.0.1
port = 3306
database = catnapdb
I'm trying to login to Roundcube only the program won't let me.
I can login to the said account from the shell and mail is setup and working correctly on my server for user 'admin'. It's RC that is the problem. If I check my logs:
/usr/local/www/roundcube/logs/errors
they show:
[21-Sep-2013 17:19:02 +0100]: IMAP Error: Login failed for admin from ip.ip.ip.ip. Could not connect to ip.ip.ip.ip:143:
Connection refused in /usr/local/www/roundcube/program/lib/Roundcube/rcube_imap.php on line 184
(POST /roundcube/?_task=login&_action=login)
which doesn't give me many clues really, just leads me to:
public function connect($host, $user, $pass, $port=143, $use_ssl=null) {}
from
rcube_imap.php
Stuff I've tried, editing:
/usr/local/www/roundcube/config/main.inc.php
with:
// IMAP AUTH type (DIGEST-MD5, CRAM-MD5, LOGIN, PLAIN or null to use
// best server supported one)
//$rcmail_config['imap_auth_type'] = LOGIN;
$rcmail_config['imap_auth_type'] = null;
// Log IMAP conversation to <log_dir>/imap or to syslog
$rcmail_config['imap_debug'] = /var/log/imap;
With a failed login attempt
/var/log/imap
doesn't even get written to, leaving me no clues. I'm using dovecot and Sendmail on a FreeBSD box with full root access. It's not an incorrect username password combination for sure.
Several Googles on the string 'Roundcube: Connection to storage server failed' are fruitless.
EDIT:
I needed an entry in
/etc/rc.conf
dovecot_enable="YES"
Schoolboy error.
I had the same problem with a letsencrypt certificate and resolve it by disabling peer authentication:
$config['imap_conn_options'] = array(
'ssl' => array('verify_peer' => true, 'verfify_peer_name' => false),
'tls' => array('verify_peer' => true, 'verfify_peer_name' => false),
);
Afterwards you can set the connection string like this (starttls):
$config['default_host'] = 'tls://your-host.tld';
$config['default_port'] = '143';
$config['smtp_server'] = 'tls://your-host.tld';
$config['smtp_port'] = '25';
Or like this (ssl approach):
$config['default_host'] = 'ssl://your-host.tld';
$config['default_port'] = '993';
$config['smtp_server'] = 'ssl://your-host.tld';
$config['smtp_port'] = '587';
Make sure you use the fully qualified hostname of the certificate in the connection string (like your-host.tld) and not an internal hostname (like localhost).
Hope that helps someone else.
Change the maildir to whatever your system uses.
Change Dovecot mail_location setting to
mail_location = maildir:~/Mail
Change Postfix home_mailbox setting to
home_mailbox = Mail/
Restart services and away you go
Taken from this fedoraforum post
If you run fail2ban, then dovecot might get banned following failed Roundcube login attempts. This has happened to me twice already...
First, check if this is indeed the case:
sudo fail2ban-client status dovecot
If you get an output similar to this:
Status for the jail: dovecot
|- Filter
| |- Currently failed: 1
| |- Total failed: 8
| `- File list: /var/log/mail.log
`- Actions
|- Currently banned: 1
|- Total banned: 2
`- Banned IP list: X.X.X.X
i.e. the Currently banned number is higher than 0, then fail2ban was a bit overeager and you have to "unban" dovecot.
Run the fail2ban client in interactive mode:
sudo fail2ban-client -i
and at the fail2ban> prompt enter the following:
set dovecot unbanip X.X.X.X
where X.X.X.X is the IP address of your Dovecot server.
Exit from the interactive client and run sudo fail2ban-client status dovecot again. The Currently banned: field now should have a value of 0. What's more important, RoundCube should work again :-)
The issue is in your mail server.
Check your ports in your mail server and reset it (if necessary):
Port 25 (and 587) must be open for SMTP
Port 143 (and 993) must be open for IMAP
Port 110 must be open for POP3
Also open those ports in your firewall settings.
sudo dovecot should solve the problem.
If not restart dovecot
sudo service dovecot restart
i really need your help. I have a Ruby on Rails Application on my local machine, a Repository at GitHub and an Ubuntu Server, which hosts the application with Nginx.
I had my repo for a lot of time public and the deployment via capistrano worked just fine. Now I converted my repo to a private one and the deployment just doesn't work. When i try to deploy it, i get the following error:
* executing `deploy'
* executing `deploy:update'
** transaction: start
* executing `deploy:update_code'
updating the cached checkout on all servers
executing locally: "git ls-remote git://github.com/GIT_USER/APPLICATION.git master"
fatal: The remote end hung up unexpectedly
*** [deploy:update_code] rolling back
* executing "rm -rf /var/www/APPLICATION/releases/DATE_OF_DEPLOY; true"
servers: ["DOMAIN"]
[DOMAIN] executing command
command finished in 424ms
So, my guess would be, that the authentication doesn't work, but it does. I copied my public key to GitHub and can even SSH there. I can SSH from the server to GitHub and it says that I am successfully authenticated. I can even see which key works. But "git ls-remote [...]" does not work and I get no info running it with trace, besides the information i already got.
So, my main problem is that i don't no where to look for the error. If you know how to solve this or can point my in any direction that would be nice.
And this is the main part of my deploy.rb:
$:.unshift(File.expand_path('./lib', ENV['rvm_path']))
require "rvm/capistrano"
require 'bundler/capistrano'
default_run_options[:pty] = true
set :user, "DEPLOY_USER"
set :domain, "DOMAIN"
set :application, "APPLICATION"
set :repository, "git#github.com:GIT_USER/APPLICATION.git"
set :deploy_to, "/var/www/#{application}"
set :deploy_via, :remote_cache
set :scm, :git
set :git_account, "GIT_USER"
set :branch, "master"
set :git_shallow_clone, 1
set :scm_verbose, true
set :use_sudo, false
set :rvm_bin_path, "/usr/local/rvm/bin"
set :rvm_ruby_string, '1.9.2'
set :rvm_type, :user # Don't use system-wide RVM
ssh_options[:port] = PORT_NUMBER
set :user, user
ssh_options[:keys] = %w(/home/DEPLOY_USER/.ssh/id_rsa)
set :ssh_options, { :forward_agent => true}
server domain, :app, :web
# Your HTTP server, Apache/etc
role :web, domain
# This may be the same as your `Web` server
role :app, domain
# This is where Rails migrations will run
role :db, domain, :primary => true
Sorry that this thing looks so cluttered, but i tried like a thousand hints, tipps and tutorials.
Thanks for every help!
And by the Way: Yes, all the things written in Capslock are just for privacy reasons and are, of course, not the real settings I use.
I seem to remember having a similar issue with deploying using a private github repo. I don't thinkg we ever quite worked out the cause of the problem but in the end I think we solved the issue using ssh-add to add the github key to ssh-agent - might be worth a try
Since this is now a non-public repo, you should be using git#... address.
I see you have this in your deploy.rb file, but ls-remote is still executed on git://...
The problem may be a cached-copy of the repository you have on a server. Check if you have correct origin address in shared/cached-copy/.git/config file. You should have git#... instead of git://... there
for private repos you have to use the https style:
set :repository, "https://github.com/git_name/repo_name.git"
.. but you have to type in your username and password twice on every deploy!
so I write a little Expect-script to do that for me
have a look at this gist
.. or as a walkthrough:
1 - make a file in your home directory ($ cat > ~/git_cap)
#!/usr/bin/expect -f
# Expect script to supply username/password to cap deploy to git private repository
# This script needs username and password as arguments to connect to git server:
# ------------------------------------------------------------------------
# ./git_cap gituser gitpwd
# -------------------------------------------------------------------------
# set Variables
set g_user [lrange $argv 0 0]
set g_pwd [lrange $argv 1 1]
set timeout -1
spawn cap deploy
match_max 100000
# Look for user prompt
expect "*?sername:*"
send -- "$g_user\r"
send -- "\r"
# Look for passwod prompt
expect "*?assword:*"
send -- "$g_pwd\r"
send -- "\r"
# Look for user prompt
expect "*?sername:*"
send -- "$g_user\r"
send -- "\r"
# Look for passwod prompt
expect "*?assword:*"
send -- "$g_pwd\r"
send -- "\r"
expect eof
2 - make it executable
$ chmod 755 ~/git_cap
$ chmod +x ~/git_cap
3 - add a alias in your .profile / .bashrc .. (optional)
alias gcap='~/git_cap gitname gitpwd'
4 - add your sudo-pwd to deploy.rb or extend the expect-script for sudo-pwd
( for that reason username & password expected 2 times, even if it where possible to use it more times .. but this way you can add a line for password with exp_continue so every next password will send the sudo-pwd and not your git-pwd)
5 - deploy with gcap
rails_root$ gcap