I hope this is the right place to post this.
I have a VM I usually connect from work. To connect from home I was given the following instructions:
Copy and paste ./ssh/id_rsa and ./ssh/id_rsa.pub from the work machine to the home machine. Also make a config file like:
# Debian VM
Host nacho4d.dev.acme.com
# IdentityFile ~/.ssh_acme/id_rsa
User nacho4d
ProxyCommand ssh ns.dev.acme.com -l nacho4d nc -w 1 %h %p
# Tunnel/springboard server
Host ns.dev.acme.com
# IdentityFile ~/.ssh_acme/id_rsa
User nacho4d
ProxyCommand ssh ts6.in.acme.com -l nacho4d nc -w 1 %h %p
So everything works good with:
$ ssh nacho4d.dev.acme.com
The problem is that I already have my own (non-work) private keys and I don't want to replace it with the work .ssh folder every time I need to use ssh. Too tedious.
How can I use a particular key, etc to connect to a specific server only?
I tried putting my files like:
~/.ssh/id_rsa → home private key
~/.ssh/id_rsa.pub → home public key
~/.ssh/config → config file like above but with IdentityFile enabled
~/.ssh_acme/id_rsa → work private key
~/.ssh_acme/id_rsa.pub → work public key
I thought that having a config file with IndentityFile should make ssh to use a particular key ( in this case pointing to ~/.ssh_acme/id_rsa) for that particular host, but I always get "Permission Denied" Connection closed by remote host.
Am I missing something? Perhaps do I need to supply the public key somewhere else too?
I checked ~./ssh/authorized_keys file in the VM and I have a ssh-rsa entry for the work-computer not the home computer (which Is I believe normal since I am using the keys provided by work.)
How come IdentityFile ~/.ssh_acme/id_rsa is not working as expected?
Do I really need to interchange my home/work keys everytime I need to connect to somewhere?
I am almost a beginner in ssh things, but something tells me there must be a clever way of doing this.
Any help is appreciated.
You don't need to specify which key works with which host, just rename the keys and add a IdentityFile line for each key:
IdentityFile ~/.ssh/id_rsa_dev_acme
IdentityFile ~/.ssh/id_rsa_in_acme
It's possible the keys in ~/.ssh_acme/id_rsa aren't being used because the permissions aren't correct on ~/.ssh_acme (0700) or ~/.ssh_acme/id_rsa (0600)
Finally, this question might be more relevant on http://unix.stackexchange.com
Related
I have a VM instance on Oracle Cloud (Ubuntu 22.04) set up with ZeroTier to act as a web server for some services that should work with my local Synology NAS.
For some of those services I also need to mount three SMB shares from my NAS with the ZeroTier tunnel, but I can't make it work.
I used mount and mount.cifs plenty of times with automounting too, this time it acts very strange:
running the mount command seems to succeed from the console, but /var/log/syslog reads
CIFS: VFS: \\XXX.XXX.XXX.XXX has not responded in 180 seconds.
Reconnecting...
if trying to access one of the shares (ls or lsof or cd or any other command), it succeeds for only one of the shares (always the same one), but only for the first time any command is given:
$ ls /temp
folder1 folder2 folder3
any other following command just "hangs" as if they system is working on something, but it stays like that indefinitely most of the times:
$ ls /temp
█
Just a few times it spits out this error
lsof: WARNING: can't stat() cifs file system /temp
Output information may be incomplete.
ls 1475 ubuntu 3r DIR 0,44 0 123207681 /temp
findmnt reads:
└─/temp //XXX.XXX.XXX.XXX/Downloads cifs rw,relatime,vers=2.0,cache=strict, username=[redacted],uid=1005,noforceuid,gid=0,noforcegid,addr=XXX.XXX.XXX.XXX,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=65536,wsize=65536,bsize=1048576,echo_interval=60,actimeo=1
for the remaining two "mounted" shares, none of them seems to respond to any command, not even the very first command, and they just hang like the one share that, at least, lets me browse for one time;
umount and umount -l take at least 2-3 minutes to successfully unmount the shares.
Same behavior when using smbclient and also with NFS shares from the same NAS.
What I have already tried:
update kernel and all packages;
remove, purge and reinstall cifs-utils, smbclient and so on...
tried mounting the same shares in another client / node within the ZeroTier network and it works just fine; also browsing from Windows and Android file manager apps with and without ZeroTier works flawlessly;
tried all SMB versions including SMBv3 and SMBv1 (CIFS);
tried different browsing or mounting methods / commands including mount, mount.cifs, autofs, smbclient;
tried to debug what happens behind the console, but didn't found anything that seems related to this in logs, htop or anything else. During the "hanging" sessions there is no spike in CPU, RAM or Network usage in either the Oracle VM or Synology NAS;
checked, reset and reconfigured all permissions on my NAS for shares, folders and files recursively and reconfigured users groups permissions.
What I haven't tried yet (I'll try as soon as possible):
reproduce this on another Oracle VM configured the same as the faulty one and another with a different base image (maybe Oracle Linux?);
It seems to me that the mount.cifs process doesn't really succeeds in mounting the share correctly, as it doesn't show as such anywhere. It also seems an issue not related to folder/file permissions, but rather something related to networking?
A note on something that may or may not be related to this: ZeroTier on my Synology NAS does not seems to work with IPv4 only - it remains OFFLINE. The node goes ONLINE only when IPv6 is enabled, but I must say that this is the only node in my ZT network that shows a IPv6 as public IP in the ZT web GUI - the other nodes show IPv4 public addresses.
If anyone has any clue on this, I'll be happy to support and reproduce any advice. Thank you!
I'm using YailScale, but I presume it will work the same.
You need to add the port 445 to /etc/iptables/rules.v4 just under the SSH setup like below:
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 445 -j ACCEPT (like this)
Then you need to edit the interfaces in /etc/samba/smb.conf to:
interfaces = lo tailscale0 100.0.0.0/24
Obviously, my interface is tailscale0, but yours will be different. Use ip link show to find yours. You may also need to change your IP range to suit ZeroTeirs, such as 100.0.0.0/24, which is what tailscale uses.
Then reboot!
I couldn't get it working without doing this.
How do I ssh ipv6 address in R ssh package
library(ssh)
# works
session <- ssh_connect("user#10.1.1.0")
# gives error
session <- ssh_connect("user#24:022f:0313:112:0::2")
Error in parse_host(host, default_port = 22) :
host string contains multiple ':' characters
Since you can't install source packages, one super hacky way to do this is to call the C function ssh_connect() calls directly:
.Call(
ssh:::C_start_session, "2405:0200:0313:112:41::42", 22, "user", NULL, ssh:::askpass, FALSE
)
That C interface is highly unlikely to change so it should be a pretty safe hack until the package eventually supports IPv6.
For those that stumble on this before the rOpenSci folks make any changes, the fork : https://github.com/hrbrmstr/ssh : also adds support for using a local SSH config file. Which means you can add a Host entry for IPv6 addresses (along with any other config options) and they'll be looked up.
i.e. if one has:
Host awickedcoolhost
User boringusername
Hostname ::1
IdentityFile ~/.ssh/id_rsa
Port 22222
in ~/.ssh/config, one can (with the fork) do:
ssh_connect("awickedcoolhost", config="~/.ssh/config")
and all the overrides in that entry should work.
We are using centos7 .If tried the below way with pem file included scp works but when pem file is removed its not working. Code was working earlier without pem file . After We moved to a different web server we are having Host key verification failed issues.
scp -i/home/centos/sshkeys/test.pem root#77.79.77.72:/usr/local//2016/Aug/31/ggea98c0-6f0f-11e6-86d9-2573a2e556aa.wav /var/www/html/tmp/ggea98c0-6f0f-11e6-86d9-2573a2e556aa.wav
Maybe your key was registered in ~/.ssh/config or it was your default key in ~/.ssh ? Check on the old server ?
Edited:
For example this is what I put in ~/.ssh/config
Host myserver
Hostname 52.100.100.100
User ubuntu
IdentityFile ~/dev/application/server-key.pem
It allow me to connect simply by ssh myserver. Maybe it was something like this that you had on your server.
I have searched several posting on this message and I am still getting the error when I attempt to do an "ldapsearch"
I have changed the slapd.conf to use a plain-text password and I am still getting the error. I have also made sure that there are no blank spaces in the file. The log file shows and iptables is turned off. I have attempted to follow the LDAP setup from
"http://www.itmanx.com/kb/centos63-openldap-phpldapadmin".
conn=1001 fd=15 ACCEPT from IP=[::1]:54486 (IP=[::]:389)
conn=1001 op=0 BIND dn="cn=Manager,dc=domain,dc=local,dc=pt" method=128
conn=1001 op=0 RESULT tag=97 err=49 text=
conn=1001 fd=15 closed (connection lost)
my server is running Centos 6.4 64.
below are the commands I am using
"ldapsearch -x -D cn=Manager,dc=domain,dc=local,dc=pt -w abc"
my slapd.conf file
database bdb
suffix "dc=domain,dc=local"
checkpoint 1024 15
rootdn "cn=Manager,dc=domain,dc=local"
rootpw abc
You need to generate your password like below -
slappasswd -h {CLEARTEXT}
enter password - abc
Do the search -
ldapsearch -x -h ipaddress(mention ip address) -D "cn=Manager,dc=domain,dc=local" -W
In the search you try to bind as:
cn=Manager,dc=domain,dc=local,dc=pt
but in the config the rootdn is:
cn=Manager,dc=domain,dc=local
This is of course "an invalid credential".
You are binding as the rootdn, which is to say the "root account" of your DIT. This account's password is, in this case, config-based. It is possible that while 'abc' is the configured password, it may not be the loaded password.
Case in point: Someone goes into the slapd.conf file and changes the rootdn password from 'xyz' to 'abc' but neglects to restart the OpenLDAP daemon. What will happen here is that 'abc' will NOT work until the process is restarted, and thus the OpenLDAP daemon will continue to honor the OLD password of 'xyz'.
I hope this helps...
Max
I need to use nmap to check if port 443 is open for a list websites. So, I saved them into a file. I need the output to tell me if the port is open or not. I used the command:
nmap -PN -p443 gnmap -oG logs/output.gnmap -iL myfolder/input.txt
The problem: the output file is giving me a different domain names. Nmap made rDNS and I found that the IP points to adifferent domain name. Please, explain. Does this means both domains are hosted in the same server ? However, I checked their certificates and found each domain has different certificate. I am concerned about port 433 in my list to check their certificates later. So, I don't want to check another domain's certificate's other than the one I entered in the file.
To solve the issue, I used the -n option. But the problem is that the output file contains IPs only. How can I produce output file that contains the result of my domains without rDNS ??
The "Grepable" output format (-oG) is deprecated because it cannot show the full output of an Nmap scan. There is no way to get the output you want with the -oG option unless you modify Nmap and recompile it.
Luckily, the XML output format (-oX) contains the information you want and more:
<hostnames>
<hostname name="bonsaiviking.com" type="user"/>
<hostname name="li34-105.members.linode.com" type="PTR"/>
</hostnames>
In this example, from scanning my domain, the hostname provided on the command line has the attribute type="user", and the hostname that was a result of the reverse lookup has type="PTR".